RMQ/Kafka事务原理

[luky116]

Kafka/RocketMQ事务消息对比_「违规用户」的博客-CSDN博客

RocketMQ事务原理

来看个例子：
用户A发起订单，支付100块钱操作完成后，能得到100积分，账户服务和会员服务是两个独立的微服务模块，有各自的数据库，按照上文提及的问题可能性，将会出现这些情况：

• 如果先扣款，再发消息，可能钱刚扣完，宕机了，消息没发出去，结果积分没增加。
• 如果先发消息，再扣款，可能积分增加了，但钱没扣掉，白送了100积分给人家。
• 钱正常扣了，消息也发送成功了，但会员服务实例消费消息出现问题，结果积分没增加。

上面例子引出了RMQ的事务一致性问题，在RMQ中是这样解决的：解决本地事务执行与消息发送的原子性问题。RMQ会先发送prepare消息到Broker端，如果消息发送成功，再执行本地事务。至于消费端是否能消费到消息，是由RMQ的重试机制来保证的，这里不做别的处理。
具体流程如下：
如如果应用模块的事务中断，不能主给broker报告commit或rollback结果，RocketMQ当做UNKNOW处理，RocketMQ事务消息还提供了一个补救方案：定时查询事务消息的数据库事务状态

Kafka事务原理

幂等性发送：保证每条消息只会发送一次

Producer在初始化的时候，Broker会分配一个PID。对于每个PID，该Producer发送数据的每个<Topic, Partition>都对应一个从0开始单调递增的Sequence Number。
Broker端也会为每个<PID, Topic, Partition>维护一个序号，并且每次Commit一条消息时将其对应序号递增。对于接收的每条消息，如果其序号比Broker维护的序号（即最后一次Commit的消息的序号）大1，则Broker会接受它，否则将其丢弃：

• 如果消息序号比Broker维护的序号大一以上，说明中间有数据尚未写入，也即乱序，此时Broker拒绝该消息，Producer抛出InvalidSequenceNumber
• 如果消息序号小于等于Broker维护的序号，说明该消息已被保存，即为重复消息，Broker直接丢弃该消息，Producer抛出DuplicateSequenceNumber

上述设计解决了0.11.0.0之前版本中的两个问题：

• Broker保存消息后，发送ACK前宕机，Producer认为消息未发送成功并重试，造成数据重复
• 前一条消息发送失败，后一条消息发送成功，前一条消息重试后成功，造成数据乱序

[git-longbo]

The picture is greate!