新特性 RocketMQ 分布式事务消息架构 ​

什么是分布式事务 ​

• 来源：单体应用 —> 拆分为分布式应用
• 一个接口需要调用多个服务，且操作不同的数据库，数据—致性难保障

常见解决方案 ​

• 2PC : 两阶段提交， 基于XA协议
• TCC : Try 、Confirm 、Cancel
• 事务消息最终—致性
• seata
• 更多...

框架 ​

• GTS -> 开源 Fescar
  地址: https://github.com/alibaba/fescar
• LCN
  地址: https://github.com/codingapi/tx-lcn
• seata
  地址:https://seata.apache.org/

讲解 RocketMQ 分布式事务消息的总体架构 ​

RocketMQ事务消息
​

RocketMQ 提供分布事务功能，通过 RocketMQ 事务消息能达到分布式事务的最终一致

半消息Half Message
​

暂不能投递的消息(暂不能消费) ，Producer已经将消息成功发送到了Broker端，但是服务端未 收到生产者对该消息的二次确认，此时该消息被标记成“暂不能投递”状态，处于该种状态下 的消息即半消息

消息回查
​

由于网络闪断、生产者应用重启等原因，导致某条事务消息的二次确认丢失，消息队列 RocketMQ 服务端通过扫描发现某条消息长期处于“半消息” 时，需要主动向消息生产者询问该消息的最终状态(Commit 或是 Rollback)，该过程即消息回查。

整体交互流程
​

• Producer 向 broker 端发送消息。
  
• 服务端将消息持久化成功之后，向发送方 ACK 确认消息已经发送成功，此时消息为半消息。发送方开始执行本地事务逻辑。
  
• 发送方根据本地事务执行结果向服务端提交二次确认 (Commit 或是 Rollback)，服务端收 到 Commit 状态则将半消息标记为可投递，订阅方最终将收到该消息;服务端收到 Rollback 状态则删除半消息，订阅方将不会接受该消息
  
• 在断网或者是应用重启的特殊情况下，上述步骤 4 提交的二次确认最终未到达服务端，经过 固定时间后服务端将对该消息发起消息回查
  
• 发送方收到消息回查后，需要检查对应消息的本地事务执行的最终结果
  
• 发送方根据检查得到的本地事务的最终状态再次提交二次确认，服务端仍按照步骤 4 对半消 息进行操作
  

RocketMQ 事务消息的状态 ​

• COMMIT_MESSAGE：提交事务消息，消费者可以消费此消息
• ROLLBACK_MESSAGE：回滚事务消息，消息会在 broker 中删除，消费者不能消费
• UNKNOW：Broker 需要回查确认消息的状态关于事务消息的消费
• 事务消息consumer端的消费方式和普通消息是—样的，RocketMQ 能保证消息能被 consumer 收到(消息重试等机制，最后也存在 consumer 消费失败的情况，这种情况出现的概率极低)。