Skip to content

Latest commit

 

History

History
40 lines (16 loc) · 2.41 KB

rocketmq-transaction.md

File metadata and controls

40 lines (16 loc) · 2.41 KB

类似TCC事务的落地的一些东西,技术选型,业务场景需要分布式事务,结合我个人亲身经历的一个创业公司APP的一个事故,给大家介绍了一下,对于系统核心链路,为什么必须要上分布式事务

seata,github上,都会提供sample,跟dubbo,官方的同学是定义为double,spring cloud,seata都提供了sample,知道如何把分布式事务框架整合到框架里去了

核心交易链路 核心交易链路,分布式事务框架

有些服务之间的调用是走异步的,下成功了订单之后,你会通知一个wms服务去发货,这个过程可以是异步的,可以是走一个MQ的,发送一个消息到MQ里去,由wms服务去从MQ里消费消息

MQ,消息中间件,面试突击第一季,刚开头我就讲过消息中间件的面试连环炮

可靠消息最终一致性方案,参考面试突击第一季

落地,RocketMQ来实现可靠消息最终一致性事务方案

Producer向RocketMQ发送一个half message

RocketMQ返回一个half message success的响应给Producer,这个时候就形成了一个half message了,此时这个message是不能被消费的

注意,这个步骤可能会因为网络等原因失败,可能你没收到RocketMQ返回的响应,那么就需要重试发送half message,直到一个half message成功建立为止

接着Producer本地执行数据库操作

Producer根据本地数据库操作的结果发送commit/rollback给RocketMQ,如果本地数据库执行成功,那么就发送一个commit给RocketMQ,让他把消息变为可以被消费的;如果本地数据库执行失败,那么就发送一个rollback给RocketMQ,废弃之前的message

注意,这个步骤可能失败,就是Producer可能因为网络原因没成功发送commit/rollback给RocketMQ,此时RocketMQ自己过一段时间发现一直没收到message的commit/rollback,就回调你服务提供的一个接口

此时在这个接口里,你需要自己去检查之前执行的本地数据库操作是否成功了,然后返回commit/rollback给RocketMQ

只要message被commit了,此时下游的服务就可以消费到这个消息,此时还需要结合ack机制,下游消费必须是消费成功了返回ack给RocketMQ,才可以认为是成功了,否则一旦失败没有ack,则必须让RocketMQ重新投递message给其他consumer