消息顺序和消息事务 - RocketMQ及分布式消息系统的原理以及重要问题解读

看到一篇好文章，记录一下：http://www.jianshu.com/p/453c6e7ff81c

先总结下他的解决方案：

把消息顺序放到 业务层去实现，同时解决消息重复的问题（因为其 最终目标是要集群的高容错性和高吞吐量，因为为了保证顺序，mq server必定要与每一个消费端进行多次沟通，一个消息消费完，才发送另一个消息，这样并行性能注定低下）

解决消息重复2 个方案，1. 消息幂等，2 消息日志（记录消息应用状态）

本文把消息事务（分布式消息一般要考虑 消息顺序和消息重复的处理）、分布式事务，说的很透彻，值得一读。

消息事务的拆解： 分布式消息事务涉及到的producer, broker之间的事务确认和重要交互

消息没有按时到broker，则broker记录并回查自己这边的事务状态，如果是需要询问的状态（Prepared）则询问producer的事务接口，两边进行事务状态的通讯，broker问producer：你是发起方，你那边是否ok，producer根据事务策略来进行决策，最后通知broker更新消息的最终状态。

原文流程：如果endTransaction方法执行失败，数据没有发送到broker，导致事务消息的 状态更新失败，broker会有回查线程定时（默认1分钟）扫描每个存储事务状态的表格文件，如果是已经提交或者回滚的消息直接跳过，如果是prepared状态则会向Producer发起CheckTransaction请求，Producer会调用DefaultMQProducerImpl.checkTransactionState()方法来处理broker的定时回调请求，而checkTransactionState会调用我们的事务设置的决断方法来决定是回滚事务还是继续执行，最后调用endTransactionOneway让broker来更新消息的最终状态。

执行流程：第一阶段 先Prepare（拿到消息地址）,第二阶段 保证本地事务成功，再发送消息，第三阶段 根据Prepare消息地址，修改消息状态，最后确认消息已发送。如果确认消息确认失败，“ 消息集群扫描Prepare消息地址，这时候发现了Prepared消息，它会向消息发送者确认，如果本地事务成功（扣款成功），消息发送失败，是回滚还是继续发送确认消息呢？ RocketMQ会根据发送端设置的策略来决定是回滚还是继续发送确认消息。这样就保证了消息发送与本地事务同时成功或同时失败。”

如果消息发送成功，但是消费失败，一般不考虑在分布式系统中去实现整个过程的回滚，可以通过提醒、监控协助“人工回滚”

最重要的是：我觉得这篇文章提供了一个思路，如果一个问题一定会出现，那就去让这个问题出现，然后想办法去处理出现之后的结果。