Distributed_事务_共识(原子提交问题)

1.共识问题

1. 共识问题的定义: 让多个节点就某件事达成一致。很多重要的场景需要集群节点达成某种一致。

2. 共识问题的场景: 主节点选举(对于主从复制的数据库，所有节点需要就谁来充当主节点达成一致)、原子事务提交(对于支持跨节点或跨分区事务的数据库，会面临这样的问题:事务(可以理解为一个大事务拆分成若干个小事务在节点上执行)在某些节点可能在一些节点上执行成功,但在其他节点上却不幸发生了失败，但为了维护事务的原子性，所有节点必须对事务的结果达成一致。)

   区分:原子提交和共识的形式化描述还稍有不同:原子事务只有在所有参与者都投票赞成的情况下才能完成最终提交，如果有任何参与者中止，则必须中止。共识则可以就任何一位参与者的提议进行表决，达到多数即可通过。原子提交与共识可以相互转化。

2.原子提交问题2PC

1. Problem:当向所有节点简单地发送一个提交请求，然后各个节点独立执行事务提交是绝对不够的。这样做很容易发生部分节点提交成功，而其他一些节点发生失败，从而违反了原子性保证(注意点是事务提交不可撤销的，但可以通过补偿性事务抵消效果(用一笔新的事务来抵消已提交事务的效果)

2. 解决方案2PC:

2PC引入了单节点事务所没有的一个新组件:协调者(也称为事务管理器)。协调者通常实现为共享库。

过程:当应用程序准备提交事务时，协调者开始阶段1

1. Phase1:发送一个准备请求到所有节点，询问他们是否可以提交。

2. Phase2:协调者然后跟踪参与者的回应：

   1. 如果所有参与者都回答 “是”，表示它们已经准备好提交，那么协调者在阶段 2 发出 提交（commit） 请求，然后提交真正发生。

   2. 如果任意一个参与者回复了 “否”，则协调者在阶段 2 中向所有节点发送 中止（abort） 请求。

      参与者回答“是”则对系统承诺:

      1. 确保在任何情况下都可以提交事务，包括安全地将事务数据写入磁盘(不能以任何借口稍后拒绝提交，包括系统崩溃，电源故障或磁盘空间不足等，但不要求提交的时间)，
      2. 检查是否存在冲突或约束违规等。

      所有节点不允许有任何反悔:开弓没有回头箭，一旦做了决定，就必须贯彻执行，即使需要很多次尝试。而如果有参与者在此期间出现故障，在其恢复之后，也必须继续执行

      协调者事务的决策则对系统承诺:

      ​ 协调者做出了提交(或者放弃)的决定，这个决定是不可以撤销的。

      =>这两个承诺保证了2PC的原子性。

3.2PC中节点出现故障:

1. 当参与者发生故障:1.在第一个阶段，任何一个准备请求发生失败或者超时(任意一个参与者发生故障)，那么协调者就会决定中止交易 2. 第二阶段中发生提交(或中止)请求失败，则协调者会无限期重试。

2. 当协调者发生故障:在第二个阶段时，协调者发生故障导致参与者不知道是中止交易还是提交交易，解决方法:

   1. 理论上，参与者之间可以互相通信，通过了解每个参与者的投票情况并最终达成一致。
   2. 等候协调者恢复，协调者会根据事务日志中未决的事务状态，向参与者发送决策。

3. 实践中的分布式事务:

   分布式事务，尤其是那些通过两阶段提交所实现的事务，声誉混杂。一方面,它们被看作是提供了一个其他方案难以企及的重要的安全保证；另一方面，他们由于操作上的缺陷、性能问题，承诺不可靠等问题而遭受诟病。

本文是根据《数据密集型应用系统设计》和查阅相关论文而写成的。