在系统服务化的过程中，我们不得不面临的一个问题是多个子系统间业务数据的一致性如何保证，解决这个问题有多种方式。
XA
可能很多人首先会想到XA规范中定义的分布式事务，下图是XA规范中定义的DTP(Distributed Transaction Processing)模型：
但该模式并不适用于如今的互联网应用，主要有以下几点问题：
- XA采用2PC，并不能完全保证一致性；
- 2PC有同步阻塞问题，并且增加了2次RTTs(round trip times)，性能低下；
- 服务化架构天然与DTP模型相悖，服务化架构显然是面向服务的，为了解决数据一致性，直接向对方暴露数据库，这还是服务化吗？
本地消息表+MQ
既然分布式事务不行，我们自然想到了本地事务，可以利用本地事务的ACID特性来保证一致性，数据存储之后，再想办法将数据传输给其它系统，做之后的业务处理，如果处理失败，还可以重试。这个过程实现起来并不难，并且有多种实现方式，但每个系统自己去搞成本还是很高的，所以我们追求的是一种通用且相对优雅的方式。目前业界多数都采用本地消息表+MQ的方式，本地消息表设计成一种通用的结构，与业务模型无关，将其放到业务库同实例上，这样就可以保证业务操作和存储消息在同一个事物内，其它线程读取消息表数据，发送到MQ Server(broker)，发送成功则删除数据，失败则保留数据，后续会不断重试，直至成功。随后MQ Server进行广播通知其它系统，做后续处理，如果处理失败，MQ Server负责重试。
上面的流程看起来对业务侵入也比较大，但我们可以通过一些手段来屏蔽这些细节：
- 首先，我们要搭建一个公共的MQ Server；
- 其次，我们要预先在业务库去建立一个消息表，可以通过运维的手段解决；
- 最后，我们要提供一个拆箱即用的Message Producer API，屏蔽发送消息的细节，Message Consumer API直接用MQ原生的即可。
@Transactional
public void doSth(Object obj) {
xxxDao.insert(obj);// 1.biz operation
Message msg = buildMessage(obj);
messageProducer.sendMessage(msg);// 2.store msg
}
这套机制从0搭建起来还是需要较大成本的，但搭建完之后将一劳永逸，算是先苦后甜吧。
RocketMQ
那有没有现成的解决方案呢？答案是有的，那就是今年风头很盛的RocketMQ（已成为Apache顶级项目），RocketMQ在其商业版中提供了事物型消息，所谓事物型消息就是保证了业务操作和发送消息满足一致性（业务操作成功，消息一定发送成功，业务操作失败，消息一定未发送，反之也成立），上面描述的方式（本地消息表+MQ）就可以看作是事物型消息，下面引用一下阿里中间件团队博客中的描述。
这里的事务消息指的其实是数据发送者事务消息，简单而言就是在真正地做业务逻辑之前会发送一条半消息到服务端，接下来发送者会执行本地的事务，在完成本地事务之后，如果成功就会向服务端发送一条确认信息，这时候服务端会将之前的半消息事务状态进行变更；如果失败了，服务端就会不断地回调客户端，来保证发送端的事务一致性。
http://jm.taobao.org/2017/03/09/20170309/
这里的关键点是第三步如果失败，要依靠第四步broker回调客户端来保证一致性，这里猜测一下其大概实现，客户端发送消息前，会添加一个事物检查的实现，并开通一个端口，broker回调时会携带着topic、message等信息，客户端依据message信息和自己的业务数据判定是提交或者回滚，可能有些业务场景依据这两个信息无法判定，那客户端依然要建立本地消息表。
其它方案
其它方案大多缺失普适性，比如TCC(Try/Confirm/Cancel)，适用于金融领域。
版权声明
本博客所有的原创文章，作者皆保留版权。转载必须包含本声明，保持本文完整，并以超链接形式注明作者高爽和本文原始地址：http://www.jianshu.com/p/8a1c14500ade。
