转载

关于分布式系统的思考（二）

对于数据库来说，可能关心的最多的就是数据的 一致性 了，由此衍生出了不同场景下的算法和策略。

在上一篇末尾提及了两种集群结构： 中心化 和 去中心化 。

中心化

一种是中心化的，由中心节点去存储集群信息并管理集群状态，其它节点只需响应数据请求，而无需知道集群中其它节点的情况。

这种模式的核心便是选举或者指定一个节点作为集群的管理者，由管理者去协调跨节点的操作、备份数据和处理故障等。

关于分布式系统的思考（二）

一般的，对于跨节点的操作，为了保证事务的原子性，提出了两步提交协议或三步提交协议，下面分别介绍。

两步提交协议，顾名思义，就是将数据的提交分为两步：投票和决策。

关于分布式系统的思考（二）

首先，在第一阶段，

然后，在第二阶段，协调者根据所有参与者的投票结果，如果是都同意则通知所有参与者提交事务，否则回滚事务。

收到所有参与者回应后，完成事务。

接着，我们考虑下两步提交过程中如果发生异常，会出现什么样的情况，会不会影响结果的一致性，并尝试解决。

在第一阶段时，有节点宕机
1. 有参与者宕机，此时协调者接收到错误响应，可认为是失败，将中断事务。
2. 协调者宕机，此时参与者等待协调者的操作通知，事务会阻塞直到协调者恢复。
  对于此种情况，解决的办法是可以设置多个协调者，一主多从，宕机后指定一台从作为新的主。
  参与者也需要记录事务的投票状态，以便新的协调者重新找回事务状态。
3. 参与者和协调者都宕机了，如上一条，新的协调者将会获取不到参与者的事务状态（该参与者的状态只有自己和原协调者知道），会一直阻塞地等待所有参与者恢复。
  其它参与者也会处于两阶段之间，直到宕机的参与者恢复。
在第二阶段，有节点宕机
1. 有参与者宕机，此时未宕机的参与者会正常地提交／回滚事务，而由于并不知道宕机的时机，所以可能会导致数据的不一致。
2. 协调者宕机，若是在发送通知前，那么参与者将阻塞地等待协调者恢复。可通过设置协调者的备份来解决，要求参与者记录事务状态。若是在发送通知后，不影响可忽略。
3. 参与者与协调者都宕机了，如上两条，可能会导致数据的不一致或阻塞。

可以看出，2pc的优点是简单直接，缺点是：

针对这些缺陷，出现了3pc。

三步提交协议，改进了2pc的一些缺陷，它增加了一个询问是否可提交阶段。如图所示：

关于分布式系统的思考（二）

第一阶段时，协调者询问各参与者是否可以执行事务提交，包含事务内容，并等待参与者的响应。

参与者收到请求后，如果认为可以成功执行事务，则返回同意，否则中止事务。

第二阶段时，协调者根据第一阶段参与者的返回消息，决定是准备提交或是中止事务。如果都是同意，那么发送预提交请求。

参与者收到请求后，会执行事务操作，并记录undo/redo log, 最后返回提交／中止事务。

第三阶段时，协调者根据第二阶段的响应，决定通知参与者提交／回滚事务，收到响应后完成事务。

3pc相比于2pc的优点在于：

在协调者和参与者端都添加了超时机制，其中：参与者超时未应答均认为是失败；协调者在第二阶段超时未发送请求视为失败，而第三阶段超时未发送请求视为成功，参与者在经过了指定超时时间后提交事务。这样便具备了一定的容错性。
不仅如此，这样还可以有效减少阻塞时间。
提供了协调者的主备方案，避免了单点问题。

缺点：

第二阶段时，参与者在接收到预提交请求后发生网络分区，此参与者在超时后提交事务，而协调者在超时后认为事务失败并通知其它参与者回滚事务，最终导致数据不一致。若发生此情况，只能通过上层去协调解决这个问题，如上一篇提到的两种解决方案。（2pc也有类似缺陷）
比2pc多了一个阶段，意味着同等情况下，耗时要多一点。