RocketMQ源码系列(2)

·  阅读 110

无论走到哪里,都应该记住,过去都是假的,回忆是一条没有尽头的路,一切以往的春天都不复存在,就连那最坚韧而又狂乱的爱情归根结底也不过是一种转瞬即逝的现实! —《百年孤独》

东坡肉 的图像结果

百无聊赖的周末,学习了如何Kali嗅探欺骗入门,去听了德云社的相声,又去店里吃了东坡肉,味道还不错,但是还是不能忘了正事呀。所以晚上来到办公室继续学习RocketMQ源码系列文章,但是感觉逼格好像不太够,所以在文章的开头加上了百年孤独的经典语录。

如何保证生成者发送到Broker的数据不丢失

在这之前先了解一下RocketMQ的事务消息机制的底层实现原理:

image.png

image.png

上面两张图是我从网上找的,因为感觉事务这一块讲解起来是挺抽象的,我们程序平常本来接触得也比较少,第一张图片主要是从业务角度理解的,第二张图是官网设计的图。对比起来看,理解的更加深刻。

首先是订单系统作为生产者发送一条half MsgRocketMQ Server里面去,MQServer 响应发送一条ok消息告诉生成者我没有故障,放心吧。接着订单系统更新本地的数据库,然后订单系统再根据本地执行的结果决定发送Commit或者RollBack消息。此时又要考虑网络的波动,MQServer如果很长时间没有收到Commit/Rollback的事务消息,就发送一次消息进行回查,默认的回查次数是15次,接着还是走刚才的流程。

这里再分情况讨论,上述几个过程出现丢失消息的情况:

如果发送half消息的时候没发出去,这时候需要通知其他系统进行回滚操作,这样才能保证一致性;

如果发送half消息成功,但是一直没有收到响应,RocketMQ这里有一个补偿流程,他会去扫描自己处于half状态的消息,如果我们一直没有对这个消息执行commit/rollback操作,超过了一定的时间,他就会回调你的接口;

如果本地执行执行失败,发送一个rollback请求给MQ把之前发half消息给删除掉;

通过理解上面的几个流程可以知道,MQ一定可以保证只要订单系统执行成功更新操作,一定会发送消息到MQ中,保证生产者的消息不丢失。

分类:
后端
标签: