第七章 分布式系统事务一致性解决方案大对比.pdfVIP

分布式系统事务一致性解决方案大对比 在分布式系统中 ，同时满足 “一致性”、 “可用性”和 “分区容错性”三者是不 可能的。分布式系统的事务一致性是一个技术难题 ，各种解决方案孰优孰劣 ？ 在 OLTP系统领域 ，我们在很多业务场景下都会面临事务一致性方面的需求 ，例如最经 典的 Bob给 Smith转账的案例。传统的企业开发 ，系统往往是以单体应用形式存在的 ，也 没有横跨多个数据库。 我们通常只需借助开发平台中特有数据访问技术和框架 （例如 Spring、JDBC、 ADO.NET ），结合关系型数据库自带的事务管理机制来实现事务性的需求。关系型数据库 通常具有 ACID特性 ：原子性（Atomicity ）、一致性（Consistency ）、隔离性（Isolation ）、 持久性 （Durability ）。 而大型互联网平台往往是由一系列分布式系统构成的 ，开发语言平台和技术栈也相对比 较杂 ，尤其是在 SOA 和微服务架构盛行的今天 ，一个看起来简单的功能 ，内部可能需要调 用多个 “服务”并操作多个数据库或分片来实现 ，情况往往会复杂很多。单一的技术手段和 解决方案 ，已经无法应对和满足这些复杂的场景了。 分布式系统的特性 对分布式系统有过研究的读者 ，可能听说过 “CAP定律”、 “Base理论”等 ，非常巧 的是 ，化学理论中ACID是酸、Base恰好是碱。这里笔者不对这些概念做过多的解释 ，有 兴趣的读者可以查看相关参考资料。CAP定律如下图 ： 在分布式系统中 ，同时满足 “CAP定律”中的 “一致性”、 “可用性”和 “分区容错 性”三者是不可能的 ，这比现实中找对象需同时满足 “高、富、帅”或 “白、富、美”更加 困难。在互联网领域的绝大多数的场景 ，都需要牺牲强一致性来换取系统的高可用性 ，系统 往往只需要保证 “最终一致性” ，只要这个最终时间是在用户可以接受的范围内即可。 分布式事务 提到分布式系统 ，必然要提到分布式事务。要想理解分布式事务 ，不得不先介绍一下两 阶段提交协议。先举个简单但不精准的例子来说明 ： 第一阶段 ，张老师作为 “协调者” ，给小强和小明 （参与者、节点 ）发微信 ，组织他们 俩明天 8点在学校门口集合 ，一起去爬山 ，然后开始等待小强和小明答复。 第二阶段 ，如果小强和小明都回答没问题 ，那么大家如约而至。如果小强或者小明其中 一人回答说 “明天没空 ，不行” ，那么张老师会立即通知小强和小明 “爬山活动取消”。 细心的读者会发现 ，这个过程中可能有很多问题的。如果小强没看手机 ，那么张老师会 一直等着答复 ，小明可能在家里把爬山装备都准备好了却一直等着张老师确认信息。更严重 的是 ，如果到明天 8点小强还没有答复 ，那么就算 “超时”了 ，那小明到底去还是不去集 合爬山呢 ？ 这就是两阶段提交协议的弊病 ，所以后来业界又引入了三阶段提交协议来解决该类问 题。 两阶段提交协议在主流开发语言平台 ，数据库产品中都有广泛应用和实现的 ，下面来介 绍一下 XOpen组织提供的 DTP模型图 ： XA 协议指的是 TM （事务管理器 ）和 RM （资源管理器 ）之间的接口。目前主流的关 系型数据库产品都是实现了XA 接口的。JTA(Java TransactionAPI)是符合 X/Open DTP 模型的 ，事务管理器和资源管理器之间也使用了XA 协议。 本质上也是借助两阶段提交协 议来实现分布式事务的 ，下面分别来看看XA 事务成功和失败的模型图 ： 在 JavaEE平台下 ，WebLogic、Webshare等主流商用的应用服务器提供了JTA 的实 现和支持。而在 Tomcat 下是没有实现的 （其实笔者并不认为 Tomcat 能算是 JavaEE应用 服务器 ），这就需要借助第三方的框架 Jotm、Automikos等来实现 ，两者均支持 spring 事务整合。 而在 Windows.NET 平台中 ，则可以借助 ado.net 中的TransactionScopAPI来编程 实现 ，还必须配置和借助 Windows操作系统中的 MSDTC服务。如果你的数据库使用的 mysql ，并且 mysql是部署在 Linux 平台上的 ，那么是无法支持分布式事务的。 由于篇幅 关系 ，这里不展开 ，感兴趣的读者可以自行查阅相关资料并实践。 总结 ：这种方式实现难度不算太高 ，比较适合传统的单体应用 ，在同一