分布式事务

基本概念

本地事务

事务由资源管理器（如DBMS）本地管理

优点：严格的ACID

缺点：不具备分布事务处理能力

全局事务（DTP模型）

TX协议：应用或应用服务器与事务管理器的接口

XA协议：全局事务管理器与资源管理器的接口

优点：严格的ACID

缺点：效率非常低

两阶段提交

优点

准备后，仍可提交或回滚

准备时，一致性检查必须OK

准备后，事务结果仍然只在事务内可见

准备后，事务结果已经持久化

缺点：

潜在故障点多带来的脆弱性

准备后，提交前的故障引发一系列隔离与恢复难题

http://book.51cto.com/art/201309/410608.htm

跨域的全局事务（DTP模型）

缺点

更高的协议成本

脆弱，故障点多

故障影响大，恢复困难

复杂，更多架构与平台约束

java企业平台中的分布式事务实现

JTA

面向应用、应用服务器与资源管理器的高层事务接口

JTS

JTA事务管理器的实现标准，向上支持JTA，向下通过CORBA OTS实现跨事务域的互操作性

EJB

优点

简单一致的编程模型

跨域分布处理的ACID保证

局限

DTP模型本身的局限

缺少充分公开的大规模、高可用、密集事务应用的成功案例

JMS与分布式事务：http://techv5.com/topic/1371/

其它资源

ws-transaction标准

jbossTransaction系统

Paxos算法

原则

真正重要的是满足业务需求，而不是追求抽象、绝对的系统特性

帽子戏法

酸碱（ACID-BASE Balance）

模式

服务模式

可查询操作

幂等操作

TCC操作

可补偿操作

复合模式

定期校对

可靠消息

TCC

补偿

CAP定理

http://zh.wikipedia.org/wiki/CAP%E5%AE%9A%E7%90%86

对于共享数据系统，只能同时拥有以下三项中的两个：

Consistency(一致性): 所有 用户看到一致的数据

Availability(可用性): 对数据更新具备高可用性

Tolerance to Network Partition(分区容忍性): 以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择

理解

允许至少一个节点更新状态会导致数据不一致，即丧失了C性质。

如果是多个节点，然后多个节点都是高可用的，此时肯定有个先后顺序，这时肯定没法保证一致性。

如果为了保证数据一致性，将分区一侧的节点设置为不可用，那么又丧失了A性质。

比如mysql主备节点，一般是主机统一对事务进行控制；备机只用来读。这样就尚失了A性质。

除非两个节点可以互相通信，才能既保证C又保证A，这又会导致丧失P性质。

如果要求同时达到一致性和可用性，那就没法分区了，因为一旦分区肯定会有时间窗口导致上面C或A的不满足。

酸碱平衡 （BASE）

BA(Basic Availability)

基本可用性

S（soft state）

柔性状态

E(Eventuall consistency)

最终一致性

eBay的BASE最佳实践

ebay没有使用任何的分布式事务客户端或系统

他们使用其它技术来保证最终一致性 - careful ordering of database operations - asynchronous recovery events - reconciliation or settlement batches

分布式事务方案一：定期校对

服务模式1：可查询操作

服务操作的可标识性

服务操作具有全局唯一标识

复合模式1：定期校对

需保证在事务提交后才能发送

分布式事务方案二：基于MQ

服务模式2：幂等操作

通过业务操作本身实现幂等性

服务模式2：可靠消息

实现：

业务活动的主动方，在完成业务处理的同一个本地事务中，记录消息数据

业务处理事务提交后、通过实时消息通知业务被动方，实时通知成功后删除消息数据

消息恢复系统定期找到未成功发送的消息，交给实时消息服务补发送

约束：

被动方的处理结果不影响主动方的处理

被动方的消息处理操作是幂等操作

成本：

可靠消息系统建设成本

消息数据CRUD成本

适用范围

对最终一致性时间敏感度较高

降低业务被方实现成本

可靠消息的另一种实现

实现

业务处理在业务事务提交前，向实时消息服务请求发送消息，实时消息服务只记录消息数据，而不真正发送

业务处理服务在业务事务提交后，向实时消息服务确认发送。只有在得到确认发送指令后，实时消息服务才真正发送消息

业务处理在业务事务回滚后，向实时消息服务取消发送

消息状态确认系统定期找到未确认发送或回溯的消息，向业务处理服务询问消息状态，业务处理服务根据消息ID或消息内容确定该消息是否有效。

成本

一次消息发送需要两次请求

业务处理服务需实现消息状态回查接口

优点：

消息数据独立存储、独立伸缩

降低业务系统与消息系统间的耦合

分布式事务方案三：基于TCC

服务模式3：TCC操作

Try: 尝试执行业务

完成所有业务检查（一致性）

预留必须业务资源（准隔离性）

Confirm: 确认执行业务

真正执行业务

不作任何业务检查

只使用Try阶段预留的业务资源

Confirm操作满足幂等性

Cancel: 取消执行业务

释放Try阶段预留的业务资源

Cancel操作满足幂等生

与2PC协议比较

位于业务服务层而非资源层

没有单独的准备阶段，Try操作兼备资源操作与准备能力

Try操作可以灵活选择业务资源的锁定粒度

较高开发成本

复合模式3：TCC模式

适用范围 - 强隔离性、严格一致性要求的业务活动 - 适用于执行时间较短的业务

分布式事务方案四：基于补偿（百度钱包方案）

适用范围 - 弱隔离性、弱一致性要求的业务活动 - 特别适用于执行时间较长的业务,如工作流

一般适合于金融系统，例如加钱减钱

基础设施

服务框架

业务系统jar包

消息系统

mq

数据存储

业务活动日志管理

分布式任务调度

业务活动恢复任务

消息恢复任务

定期校对任务

服务注册中心

提供服务元数据集中注册、查询与管理能力，支持事务相关属性的描述

参考

大规模SOA系统中的分布事务处事_程立.pdf

用消息队列和消息应用状态表来消除分布式事务 http://techv5.com/topic/1380/

用消息队列来解决数据一致性问题 http://rfwiki.diandian.com/post/2013-01-08/40047419557

用Spring和RabbitMQ技术应对消息传送挑战 http://www.infoq.com/cn/presentations/Spring-RabbitMQ-technology

Base: An Acid Alternative In partitioned databases, trading some consistency for availability can lead to dramatic improvements in scalability. http://queue.acm.org/detail.cfm?id=1394128

案例分析：基于消息的分布式架构 http://www.infoq.com/cn/articles/message-based-distributed-architecture

中间件技术及双十一实践·消息中间件篇 http://jm-blog.aliapp.com/?p=3483