rocketmq事物

自己记录下rocketmq事物，每次面试都要回头翻阅，这里自己再次总结下

 ps：这里是网上的一张图，其实还是很不全的，broker存储还是挺重要的，没标出来

1. 发送消息到broker
2. broker保存消息成功，返回给client端。消息已经成功保存了
3. client端执行本地事物
4. 再次发送消息给broker，client端事物处理的结果。broker根据client发来的结果进行消息的处理
5. 未收到client端的消息，broker这边有一个线程，会定时去捞取待处理的消息，进行回查
6. 确认client事物的结果状态
7. 把client端事物结果发送给broker，borker进行处理

 

这里我把 2，4扩展下

broker如何保存消息，以致于 consumer 端没有发现消息呢

这里就在于 发送事物消息的时候，client端把topic给换掉了，换成half消息的topic。这样consumer没查询到自己定于的topic的消息，自然不会去消费

还有一点，我觉得挺重要的。消息都是写入到commit log里（消息是不会进行修改的，rocketmq是顺序写入的不会去做修改操作），那如果去commit log里去查询消息呢，消息到了broker会生成 一个 ConsumeQueue 

简单介绍下ConsumeQueue

Consumequeue类对应的是每个topic和queuId下面的所有文件。Consumequeue类文件的存储路径默认为$HOME/store/consumequeue/{topic}/{queueId}/{fileName}，每个文件由30W条数据组成，每条数据的结构如下所示：

commitLog offset （8）

Size（4）

Message Tag HashCode(8)

消息的起始物理偏移量physical offset(long 8字节)+消息大小size(int 4字节)+tagsCode(long 8字节)，每条数据的大小为20个字节，从而每个文件的默认大小为600万个字节。

就是通过偏移量和字节大小 在 commit log里面寻找到那条记录。

 

第二点的扩展

1. 事物消息在clinet端把消息的topic更换为RMQ_SYS_TRANS_HALF_TOPIC，把原来的topic的名字存在msg的属性当中
2. 事物在broker存储msg，并生成 topic为RMQ_SYS_TRANS_HALF_TOPIC的Consumequeue，用于寻找 commit log 里面生成的半消息
3. 

第四点的扩展

1. client处理完事物，再次发送给broker的
2. broker 根据Consumequeue 查找出那条 half消息
3. 根据处理结果，成功 就在commitlog里面生成一条原先topic的消息，并生成相应的 Consumequeue，再生成一条 topic为 RMQ_SYS_TRANS_OP_HALF_TOPIC的op消息和 op消息的 Consumequeue。失败了就只生成 op消息。(ps:为什么需要op消息呢，因为消息需要一个状态来表示是否处理成功)
4. 注意这里是生成消息，不是在原来的消息体上进行修改

 

1. 发送消息
2. 发送消息成功返回producer
3. producer把本地执行的结果commit/rollback给broker。
4. broker收到producer的消息，成功则生成nomal和op。失败则只生成op
5. half消息会有一个timer，定时去producer去获取事物的状态。

以上是RocketMQ事务消息实现的示意图：

• 通过写Half消息的方式来实现一阶段消息对用户不可见
• 通过Op消息来标记事务消息的状态
• 通过读取Half消息来生成一条新的Normal消息来完成二阶段Commit之后消息对Consumer可见
• 通过Half消息来执行回查