基本概念
本地事务
事务由资源管理器(如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
转自:http://www.cnblogs.com/duanxz/p/5194544.html