乐趣区

关于分布式:分布式下我想要一致性

jiezi

每一个程序员架构梦的实现之路上，总是绕不开分布式系统 CAP 这个实践的学习。如果你还没有理解过，能够翻看之前的文章，置信我，如果你想成为架构师，这个实践无论是在工作中还是面试中吹水，你始终都是须要的

艰涩难懂的 CAP

CAP 实践作为分布式的重要实践根底，指出了在分布式环境下，其实只有 AP 和 CP 两种模型去抉择。BASE 实践作为 CAP 实践的一个延长，主张就义一致性去换取可用性。反之，一个分布式系统也能够去就义可用性去换取一致性。

分布式事务

说到一致性就不能不提事务，事务这个词当初常常用于数据库，然而有一点要留神，站在肯定的角度，事务并非只实用于数据库。如果站在数据库角度非要下一个定义的话：

事务（Transaction），个别是指要做的或所做的事件。在计算机术语中是指拜访并可能更新数据库中各种数据项的一个程序执行单元 (unit)。事务通常由高级数据库操纵语言或编程语言（如 SQL，C++ 或 Java）书写的用户程序的执行所引起，并用形如 begin transaction 和 end transaction 语句（或函数调用）来界定。事务由事务开始(begin transaction) 和事务完结 (end transaction) 之间执行的整体操作组成。

为了更好的意识并实现事务，形象出了 ACID 实践, 换句话说，如果一个零碎能实现 ACID 个性，那么就实现了事务个性。

  • Atomic 原子性: 一个事务的所有系列操作步骤被看成是一个动作，所有的步骤要么全副实现要么一个也不会实现。
  • Consistent 一致性: 事物实现时, 必须所有数据保持一致状态
  • Isolated 隔离性: 次要用于实现并发管制, 隔离可能确保并发执行的事务可能程序一个接一个执行，通过隔离，一个未实现事务不会影响另外一个未实现事务。
  • Durable 持久性: 持久性是指一个事务一旦被提交，它对数据库中数据的扭转就是永久性的，接下来即便数据库产生故障也不应该对其有任何影响

在单机上实现 ACID 并不艰难，通常能够利用锁、工夫序列或者程序日志等机制来保障。这里多说一句，一般而言，隔离性能够利用锁机制来实现，而原子性、一致性和持久性都能够利用日志来实现，一致性算法 Raft 也是通过日志模式来保障一致性的。

然而在分布式环境下，网络环境却比单机要简单的多，起因在于网络通信的不可靠性，处于不同网络的多个节点要想保障一致性，网络提早、网络故障等因素都须要思考。

二阶段提交协定

二阶段（2PC）提交协定是依据业界首个分布式事务标准规范 X /OpenDTP 提出的，顾名思义，它通过两个阶段来协商一个提交操作。

X/OpenDTP 设计了一个模型来形容分布式事务的各个角色以及标准：

  1. AP：用户程序，负责触发分布式事务，在这个过程中采纳了非凡的事务指令(XA 指令)，这些指令由 TM 接管并发送给相干的 RM 去执行
  2. RM：资源管理器，个别指数据库，每个 RM 只执行本人相干的指令。映射到程序级别如：ODBC，ADO.Net,JDBC 等。
  3. TM：事务管理器或者说是事务协调者，它负责接管 AP 发动的指令，调度和协调参加事务的所有 RM，确保事务失常实现或者回滚。

二阶段提交协定最早用来实现数据库的分布式事务，当初大部分数据库的分布式事务都采纳了 XA 协定。在二阶段提交协定中，一个事务的提交过程被分为两个过程：

  1. 告诉阶段。在这个阶段会告诉所有参加事务的资源管理器（RM）进行资源的预留和其余筹备工作，其中包含了长久化日志文件和资源的锁定。所以这个阶段在整个事务过程中占据了大部分工夫，筹备实现并把后果返回给事务管理器（TM）。
  2. 提交阶段。在该阶段，事务管理器（TM）会依据上一步的后果来决定是提交还是回滚操作。仅当全副资源管理器（RM）都批准提交的时候，事务管理器（TM）才告诉所有的资源管理器（RM）正式提交事务，否则 TM 将会告诉所有的 RM 勾销事务。

二阶段协定的精华在于，它通过两个阶段来把不牢靠事务提交失败的几率升高到了最小，在一个真正的二阶段提交事务的过程中，第一阶段其实占据了整个事务的大部分工夫，而真正提交事务的第二阶段简直是霎时实现的，所以这正是二阶段的奇妙之处。

然而事实中咱们很少应用二阶段提交协定来保障事务性，为什么呢？

  1. 在事实场景中，很少有强一致性的业务，最罕用的是基于 BASE 实践的最终一致性
  2. 二阶段提交协定须要锁定资源，在性能上会有肯定损失，这在高并发的场景中是不适宜的。
  3. 二阶段提交协定引入了事务管理器（TM），减少了零碎的复杂性，而且少数开发人员并不精通 TM 以及 RM 的技能。

TCC

因为二阶段提交协定的一系列缺点，TCC 被引入分布式事务。TCC 是 Try（预留）、Confirm（确认）、Cancel（撤销）3 个操作的简称，它蕴含了预留、确认或撤销这 2 个阶段。TCC 针对分布式事务大体过程是这样的：

  1. 预留阶段：事务发起者别离向所有参加事务的业务方发动申请，要求预留业务资源，业务方并给予回复。
  2. 提交阶段：事务发起者收到每个参加事务的业务方的回复，如果都是 ok，则告诉每个业务方提交事务操作，如果至多有一个业务方返回后果非 ok，则告诉所有的业务方撤销事务操作。

TCC 实质上是弥补事务，从操作上就可以看进去，每个业务方针对以后事务须要注册三个操作：预留操作，确认操作，勾销操作。这三个操作是须要参加事务的每个业务来编码实现的。对应到编码层面，每个业务方都须要提供三个操作的接口，为了一致性，确认操作和勾销操作必须是幂等的，因为这两个操作可能会系统性的重试或者人为干涉的重试。

写在最初

TCC 在操作上更像是一种编程模型，它次要针对业务层面，所以它在性能上要比次要针对数据库层面的二阶段提交要高很多。目前二阶段提交协定次要的利用场景还是在数据库上，所以它实质上应用的是数据库的锁机制，这也是在高并发的互联网利用中很少应用二阶段提交协定的重要起因之一。

说了那么多，在实在的业务场景中，如果能用单机数据库的事务来代替分布式事务，那就首选单机数据库事务。如果业务容许放弃强一致性，那就采纳最终一致性准则来保障一致性，而最终一致性最罕用的解决方案是利用牢靠的 MQ 音讯，这个有工夫咱们详聊。

更多精彩文章

  • 分布式大并发系列
  • 架构设计系列
  • 趣学算法和数据结构系列
  • 设计模式系列

退出移动版