自己记录下rocketmq事物，每次面试都要回头翻阅，这里自己再次总结下
ps：这里是网上的一张图，其实还是很不全的，broker存储还是挺重要的，没标出来
- 发送消息到broker
- broker保存消息成功，返回给client端。消息已经成功保存了
- client端执行本地事物
- 再次发送消息给broker，client端事物处理的结果。broker根据client发来的结果进行消息的处理
- 未收到client端的消息，broker这边有一个线程，会定时去捞取待处理的消息，进行回查
- 确认client事物的结果状态
- 把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里面寻找到那条记录。
第二点的扩展
- 事物消息在clinet端把消息的topic更换为RMQ_SYS_TRANS_HALF_TOPIC，把原来的topic的名字存在msg的属性当中
- 事物在broker存储msg，并生成 topic为RMQ_SYS_TRANS_HALF_TOPIC的Consumequeue，用于寻找 commit log 里面生成的半消息
-
rocketmq事物
第四点的扩展
- client处理完事物，再次发送给broker的
- broker 根据Consumequeue 查找出那条 half消息
- 根据处理结果，成功 就在commitlog里面生成一条原先topic的消息，并生成相应的 Consumequeue，再生成一条 topic为 RMQ_SYS_TRANS_OP_HALF_TOPIC的op消息和 op消息的 Consumequeue。失败了就只生成 op消息。(ps:为什么需要op消息呢，因为消息需要一个状态来表示是否处理成功)
- 注意这里是生成消息，不是在原来的消息体上进行修改
- 发送消息
- 发送消息成功返回producer
- producer把本地执行的结果commit/rollback给broker。
- broker收到producer的消息，成功则生成nomal和op。失败则只生成op
- half消息会有一个timer，定时去producer去获取事物的状态。
以上是RocketMQ事务消息实现的示意图：
- 通过写Half消息的方式来实现一阶段消息对用户不可见
- 通过Op消息来标记事务消息的状态
- 通过读取Half消息来生成一条新的Normal消息来完成二阶段Commit之后消息对Consumer可见
- 通过Half消息来执行回查