分布式事务
分布式事务，常见的两个处理办法就是两段式提交和补偿。
两段式提交典型的就是XA，有个事务协调器，告诉大家，来都准备好提交，大家回复，都准备好了，然后协调器告诉大家，一起提交，大家都提交了。
补偿比较好理解，先处理业务，然后定时或者回调里，检查状态是不是一致的，如果不一致采用某个策略，强制状态到某个结束状态（一般是失败状态），然后就世界太平了。典型的就是冲正操作。
比如对数据库来说，有redo日志的。如果某个数据库这时候宕机了，那么它重启的时候，先执行检查，也会把上一次的这些操作都提交掉的。所以各个点的数据都是一致的。
使用消息队列来避免分布式事务
如果仔细观察生活的话，生活的很多场景已经给了我们提示。
比如在北京很有名的姚记炒肝点了炒肝并付了钱后，他们并不会直接把你点的炒肝给你，而是给你一张小票，然后让你拿着小票到出货区排队去取。为什么他们要将付钱和取货两个动作分开呢？原因很多，其中一个很重要的原因是为了使他们接待能力增强（并发量更高）。
还是回到我们的问题，只要这张小票在，你最终是能拿到炒肝的。同理转账服务也是如此，当支付宝账户扣除1万后，我们只要生成一个凭证（消息）即可， 这个凭证（消息）上写着“让余额宝账户增加 1万”，只要这个凭证（消息）能可靠保存，我们最终是可以拿着这个凭证（消息）让余额宝账户增加1万的，即我们能依靠这个凭证（消息）完成最终一致性。
《大规模SOA系统中分布式事务处理》
分布式事务，常见的两个处理办法就是两段式提交和补偿。
两段式提交典型的就是XA，有个事务协调器，告诉大家，来都准备好提交，大家回复，都准备好了，然后协调器告诉大家，一起提交，大家都提交了。
补偿比较好理解，先处理业务，然后定时或者回调里，检查状态是不是一致的，如果不一致采用某个策略，强制状态到某个结束状态（一般是失败状态），然后就世界太平了。典型的就是冲正操作。
比如对数据库来说，有redo日志的。如果某个数据库这时候宕机了，那么它重启的时候，先执行检查，也会把上一次的这些操作都提交掉的。所以各个点的数据都是一致的。
使用消息队列来避免分布式事务
如果仔细观察生活的话，生活的很多场景已经给了我们提示。
比如在北京很有名的姚记炒肝点了炒肝并付了钱后，他们并不会直接把你点的炒肝给你，而是给你一张小票，然后让你拿着小票到出货区排队去取。为什么他们要将付钱和取货两个动作分开呢？原因很多，其中一个很重要的原因是为了使他们接待能力增强（并发量更高）。
还是回到我们的问题，只要这张小票在，你最终是能拿到炒肝的。同理转账服务也是如此，当支付宝账户扣除1万后，我们只要生成一个凭证（消息）即可， 这个凭证（消息）上写着“让余额宝账户增加 1万”，只要这个凭证（消息）能可靠保存，我们最终是可以拿着这个凭证（消息）让余额宝账户增加1万的，即我们能依靠这个凭证（消息）完成最终一致性。
《大规模SOA系统中分布式事务处理》