根据每个节点自己知道自己能够是否成功的特性，我们将其分为协调者与事务参与者。通过协调者去来统一掌控所有参与者的操作结果并最终指示这些节点是否要把操作结果进行真正的提交(比如将更新后的数据写入磁盘等等)。因此，二阶段提交的算法思路可以概括为：参与者将操作成败通知协调者，再由协调者根据所有参与者的反馈情报决定各参与者是否要提交操作还是中止操作。

(1) 请求阶段

1）协调者节点向所有参与者节点询问是否可以执行提交操作(vote)，并开始等待各参与者节点的响应。
2）参与者节点执行询问发起为止的所有事务操作，并将Undo信息和Redo信息写入日志。（注意：若成功这里其实每个参与者已经执行了事务操作）
3）各参与者节点响应协调者节点发起的询问。如果参与者节点的事务操作实际执行成功，则它返回一个”同意”消息；如果参与者节点的事务操作实际执行失败，则它返回一个”中止”消息。

(2) 提交阶段

如果协调者收到了参与者的失败消息或者超时，直接给每个参与者发送回滚(Rollback)消息；否则，发送正式提交(Commit)消息；参与者根据协调者的指令执行提交或者回滚操作，释放所有事务处理过程中使用的锁资源。(注意:必须在最后阶段释放锁资源)

很明显，2PC会存在明显的问题：

1、同步阻塞问题。执行过程中，所有参与节点都是事务阻塞型的。当参与者占有公共资源时，其他第三方节点访问公共资源不得不处于阻塞状态。
2、单点故障。由于协调者的重要性，一旦协调者发生故障。参与者会一直阻塞下去。尤其在第二阶段，协调者发生故障，那么所有的参与者还都处于锁定事务资源的状态中，而无法继续完成事务操作。（如果是协调者挂掉，可以重新选举一个协调者，但是无法解决因为协调者宕机导致的参与者处于阻塞状态的问题）
3、数据不一致。在提交阶段，协调者发出一部分请求后出现了问题就会产生数据不一致的问题。
4、二阶段无法解决的问题：协调者再发出commit消息之后宕机，而唯一接收到这条消息的参与者同时也宕机了。那么即使协调者通过选举协议产生了新的协调者，这条事务的状态也是不确定的，没人知道事务是否被已经提交。

为了解决这些问题，出现了3PC，但是很多分布式系统都会采取放弃对分布式事务的支持。

分布式一致性

简单来讲就是保证主本与副本，以及副本之间的数据一致的问题。

一致性协议：Paxos

如果主节点发生故障，那么备节点就会提议自己成为主节点。因为会存在网络分区的缘故，所以就会有多个备节点提议自己成为主节点并且提议的时间可能也是不相同的，会存在先后顺序。那么 Paxos 协议就用来保证，有多个提交协议的时候且顺序不同时，如何选举出唯一的主节点。

最简单的：只有一个提议者。

(1) 提议者发送请求给接受者，接受者可选择接受或拒绝。
(2) 如果超过一半以上的接受者接受，说明提议已经生效，提议者发送通知消息通知所有的接受者提议生效。

来个复杂的：存在多个提议者。

整个算法的大致过程为：

第一阶段：因为存在多个“提议者”，如果都提意见，那么“接受者”接受谁的不接受谁的？太混乱了。所以，要先明确哪个“提议者”是意见领袖有权提出提议，未来，“接受者”们就主要处理这个“提议者”的提议了（这样，也可以在提出提议时就尽量让意见统一，谋求尽早形成多数派）。

第二阶段：由上阶段选出的意见领袖提出提议，“接受者”反馈意见。如果多数“接受者”接受了一个提议，那么提议就通过了。

有个跟选举常识不一样的地方，就是每个“提议者”不会执着于让自己的提议通过，而是每个“提议者”会执着于让提议尽快达成一致意见。

所以，为了这个目标，如果“提议者”在贿选的时候，发现“接受者”已经接受过前面意见领袖的提议了，即便“提议者”贿选成功，也会默默的把自己的提议改为前面意见领袖的提议。所以一旦贿赂成功，胜出的“提议者”再提出提议，提议内容也是前面意见领袖的提议（这样，在谋求尽早形成多数派的路上，又前进了一步）。

例子参考：https://www.zhihu.com/question/19787937 （最好是多看看这个例子）

这里有点搞不懂他为啥不直接在接受者记录各个提议，等待收集完全时，决策选出主节点呐？？

Raft 协议

Raft 算法是近几年很火的一个分布式一致性算法，旨在提供分布式一致性的前提下，提高算法的可读性，降低实现的难度。它提供了和Paxos算法相同的功能和性能，但是它的算法结构和 Paxos不同，使得 Raft算法更加容易理解并且更容易构建实际的系统。为了提升可理解性，Raft将一致性算法分解成了几个关键模块，例如领导人选举、日志复制和安全性。

Raft集群服务器的状态有三种：

领导人 (Leader)：领导人处理所有的客户端请求（如果一个客户端和跟随者联系，那么跟随者会把请求重定向给领导人）
候选人(Candidate)：
跟随者(Follower)：跟随者都是被动的，他们不会发送任何请求，只是简单的响应来自领导者或者候选人的请求。

当跟随者长时间没接收到领导人的心跳包或候选人的请求投票RPC时（超时），便会成为候选人发起投票，直到成为领导人或收到新领导人的心跳包。

Raft 通过选举一个领导人，然后全权交给它来管理复制日志来实现一致性。领导人从客户端接收日志条目，把日志条目复制到其他服务器上，并且当保证安全性的时候告诉其他的服务器应用日志条目到他们的状态机中。拥有一个领导人大大简化了对复制日志的管理。

在这里只说一下领导人选举的整个大致流程：

当Follower（服务器程序启动时，都是Follower）长时间未接受到有效的Leader或者Candidate的RPCs时，发生超时则会增加自身任期号，成为Candidate，然后并行的向集群中的其他服务器节点发送请求投票的RPCs，候选人会继续保持着当前状态直到以下三件事情之一发生：

(a) 获得大多数投票成为Leader
(b) 其他的服务器成为Leader

每一次选举都是一个任期（term），任期由整数表示，单调递增。每次选举都会分配一段随机的超时时间选举超时时间（eg:150~300ms）,若这段时间内未完成选举，则任期加1，开启新一轮的选举。

详情戳：Raft 协议中文翻译
 Raft 协议形象动画演示

具体的实例：咱们等到开始学习 Redis 的 Sentinel 时再来述说！！！

分布式容错

当然，副本肯定是容错技术的唯一手段。那么总控机如何检测工作机是否正常呐，主要有如下的两种协议方法

保活协议：心跳包协议，租约协议

心跳包协议

可以在心跳包上加上其他信息。问题是如果收不到心跳回应，你如何确定机器是不是发生了故障还是因为网络错误呐？？如何解决：租约协议

租约协议（Lease Protocol）

什么是租约协议，就是主控给B一个工牌，这个工牌是有期限的，当期限到了时候，B需要来找主控，主控根据B的工作情况，再次下发一个工牌给B，如果超过工牌使用期限，B就无法工作，这个工牌就是租约了。

考虑他是如何解决上面提到的那个问题的：

如果网络不好或者发生故障，就会超时。停止服务

这和心跳包+ 超时，难道不是一样的吗？真有意思~~

为了减轻主控服务器的压力吗？

文章目录

分布式事务

分布式事务协议： 两阶段提交协议