http://blog.csdn.net/bluishglc/article/details/7612811
作者：谢照东
链接：http://www.zhihu.com/question/29483490/answer/107142534
来源：知乎
比如事务补偿机制：即在事务链中的任何一个正向事务操作，都必须存在一个完全符合回滚规则的可逆事务。
或者两阶段提交、三阶段提交：分布式事务服务(DTS) 支付宝的DTS实现！最近也看见一个tcc方案GitHub - changmingxie/tcc-transaction: tcc-transaction是TCC型事务java实现 还没有线上试过
或者利用消息系统（转载自高可用架构公众号）
经典方案 - eBay 模式
此方案的核心是将需要分布式处理的任务通过消息日志的方式来异步执行。消息日志可以存储到本地文本、数据库或消息队列，再通过业务规则自动或人工发起重试。人工重试更多的是应用于支付场景，通过对账系统对事后问题的处理。
消息日志方案的核心是保证服务接口的幂等性。
考虑到网络通讯失败、数据丢包等原因，如果接口不能保证幂等性，数据的唯一性将很难保证。
eBay 方式的主要思路如下。
Base：一种 Acid 的替代方案
此方案是 eBay 的架构师 Dan Pritchett 在 2008 年发表给 ACM 的文章，是一篇解释 BASE 原则，或者说最终一致性的经典文章。文中讨论了 BASE 与 ACID 原则在保证数据一致性的基本差异。
如果 ACID 为分区的数据库提供一致性的选择，那么如何实现可用性呢？答案是
BASE (basically available, soft state, eventually consistent)
BASE 的可用性是通过支持局部故障而不是系统全局故障来实现的。下面是一个简单的例子：如果将用户分区在 5 个数据库服务器上，BASE 设计鼓励类似的处理方式，一个用户数据库的故障只影响这台特定主机那 20% 的用户。这里不涉及任何魔法，不过它确实可以带来更高的可感知的系统可用性。
文章中描述了一个最常见的场景，如果产生了一笔交易，需要在交易表增加记录，同时还要修改用户表的金额。这两个表属于不同的远程服务，所以就涉及到分布式事务一致性的问题。
文中提出了一个经典的解决方法，将主要修改操作以及更新用户表的消息放在一个本地事务来完成。同时为了避免重复消费用户表消息带来的问题，达到多次重试的幂等性，增加一个更新记录表 updates_applied 来记录已经处理过的消息。
系统的执行伪代码如下
基于以上方法，在第一阶段，通过本地的数据库的事务保障，增加了 transaction 表及消息队列 。
在第二阶段，分别读出消息队列（但不删除），通过判断更新记录表 updates_applied 来检测相关记录是否被执行，未被执行的记录会修改 user 表，然后增加一条操作记录到 updates_applied，事务执行成功之后再删除队列。
通过以上方法，达到了分布式系统的最终一致性。进一步了解 eBay 的方案可以参考文末链接。
或者在业务层面整合，整合成本地事务的方式。
Dubbo分布式事务
http://javatar.iteye.com/blog/981787
http://www.javaworld.com/article/2077963/open-source-tools/distributed-transactions-in-spring--with-and-without-xa.html