分布式场景下的核心问题

分布式场景下困扰我们的3个核心问题（CAP）：一致性、可用性、分区容错性。
1、一致性（Consistency）：无论服务如何拆分，所有实例节点同一时间看到是相同的数据。
2、可用性（Availability）：不管是否成功，确保每一个请求都能接收到响应。
3、分区容错性（Partition Tolerance）：系统任意分区后，在网络故障时，仍能操作。

我们最为关注的是如何在高并发下保障 Data Consistency（数据一致性），因为在很多核心金融业务场景（如 支付、下单、跨行转账）中，为了避免资金问题，是需要强一致性结果的。
而分布式一致性算法就是保障 Data Consistency的强大利刃，它的目标是确保分布式系统中多个节点在读取或修改同一份数据时，产生相同结果的关键机制。这些算法对于保证分布式系统的一致性和可靠性至关重要。

常用的分布式算法
1、Paxos算法。
2、Raft算法。
3、ZAB（ZooKeeper Atomic Broadcast）算法

Paxos算法

Paxos算法是一种用于分布式系统中保障一致性的算法，由Leslie Lamport于1990年提出，被广泛应用于分布式系统中的一致性问题，如分布式数据库、分布式存储系统等。
该算法的主要目标是在一个由多个节点组成的分布式系统中，协调某个数据值并达成一致性，典型的少数服从多数的案例。

基本概念
1、提案： 由提案号（id）和提案内容（value）组成，其中id主要用于实现Paxos算法，而value对应在实际的分布式系统中为所需要修改数据的命令 或者 log信息。
2、角色： Paxos算法中抽象出来的概念，对应着实际分布式环境中的不同分工。主要角色包括提议者（Proposer）、附议者（Acceptor）和学习者（Learner）。

• 提议者负责提出值的提案。
• 附议者负责接受提案并投票。
• 学习者负责学习已经达成一致的值。
  

Proposer 提案者
提案者负责提出提案 (Proposal)，Proposal信息包括提案编号 (Proposal ID) 和提议的值 (Value)。提案的value，可以是任何行为或者操作，比如传统转账场景，将用户的账号余额从0改为100，Paxos 协议统一抽象为value。 Proposer可以有多个，不同的Proposer可以提出不同的甚至互斥的value，比如提案者A消费（将变量Money-100），提案者B也消费（将变量Money-200），但对同一轮Paxose而言，最多只有一个value可以被批准，否则就乱套了。
Acceptor 附议者
Acceptor 从含义上来说就是除了当前Proposer以外的其他机器，他们之间完全平等和独立，Proposer需要争取超过半数（N/2+1）的 Acceptor 批准后，其提案才能通过，它倡导的“value”操作才能被所有机器（包括Proposer、Acceptor、Learner）所接受。
Learner 学习者
Learner 不参与选举，而是学习被批准的 value，在Paxos中，Learner主要参与相关的状态机同步流程。这里Leaner的流程就参考了Quorum议会机制，某个value需要获得超过半数的Acceptor 批准，才能真正被Learner学习到。

算法流程
1、准备阶段（Prepare阶段）：提议者（Proposer）向所有Acceptor节点发起Prepare请求，携带全局唯一且递增的提案编号N，要求它们告诉提议者已经接受的最高提议号。如果接受者接受了轮次小于当前轮次的提案，那么它会更新自己的状态，拒绝当前轮次的提案。
2、承诺阶段（Promise阶段） ：Acceptor节点接收到prepare请求后，会检查该请求的提议号是否比它已经接受的提议号更高。如果是，那么节点会更新自己的状态，承诺不再接受轮次小于当前轮次的提案。
Acceptor收到Prepare请求后，有两种情况：

• 如果Acceptor首次接收Prepare请求, 设置MaxN=N， 同时响应ok。
• 如果Acceptor不是首次接收Prepare请求，则：
  • 若请求过来的提案编号N小于等于上次持久化的提案编号ResN，则不响应或者响应error。
  • 若请求过来的提案编号N大于上次持久化的提案编号MaxN, 则更新MaxN=N，同时给出正确的响应。

3、承诺响应阶段（Acknowledge阶段） ：在这个阶段，接受者会检查自己是否接受了当前提案。如果是，那么接受者会返回一个承诺响应，告诉提议者当前提案已经被接受。
4、提议的接受与决策 ：当Acceptor节点接收到一个提议请求时，它会检查该提议的值是否比它已经接受的值更高。如果是，那么它会接受该提议，并向其他节点发送接受消息。当一个提议被大多数节点接受后，该提议就成为了决策，并被所有节点执行。
Proposer 获得 Accept 回复的信息之后，做如下判断：

• 回复数量 > Acceptor 数量的1/2时，代表提交 value 成功，发送广播给所有的 Proposer、Learner，通知它们已提交的 value。
• 回复数量 <= Acceptor 数量的1/2时，则重新开始，更新生成更大的提案号，跳转到准备阶段执行。
• 收到响应error时，同样更新生成更大的提案号，转到准备阶段执行。

5、学习阶段（Learn阶段） ：学习者会向所有接受者发送一个学习请求，接受者会返回已经接受的最大提案，使学习者能够学习到已经达成一致的值。

算法应用
Paxos算法具有高度容错特性，可以在某个节点宕机、网络异常、消息延迟等问题的情况下，快速且正确地在集群内部对某个数据达成一致。所以在很多业务场景中得到应用。比如：
1、Zookeeper使用一个类Multi-Paxos的共识算法作为底层存储协同的机制。
2、Google公司在其分布式锁中应用了Multi-Paxos算法。

Raft算法

基本概念
Raft 算法是一致性算的一种，用来解决分布式一致性问题。它提供了一种在计算系统集群中分布状态机的通用方法，确保集群中的每个节点都同意一系列相同的状态转换。
其主要目标是解决分布式系统中的领导者选举、日志复制和安全性等关键问题。

领导者选举与超时机制
在Raft算法中，服务器可以处于三种状态：领导者（leader）、跟随者（follower）和候选者（candidate）。正常情况下，集群中只包含一个 leader ，其余服务器都是 follower 。
跟随者通过投票选出领导者，只有得到“大多数”跟随者投票的服务器能成为领导者；领导者负责将命令同步给跟随者，只有被“大多数”跟随者确认的命令才能提交。
1、跟随者(Follower)
Fllower是所有节点的初始状态，内部都会有一个随机超时时间。这个超时时间，规定了在倒计时结束后仍然收不到Leader的心跳，Follower就会转变为Candidate。
2、候选者(candidate)
Follower在转变为Candidate后，超时时间重置，倒计时结束时就会向其他节点提名自己的实，拉取选票。
如果能获得半数以上（1/2以上,包含自己投给自己的）的选票，则当选为Leader，这个过程就叫做Leader选举。
所以节点最好是单数，避免极端情况下出现一个集群选举出两个Leader的脑裂问题。
3、领导者(leader)
Raft集群通过Leader与客户端进行交互，Leader不断处理写请求与发送心跳给Follower，Follower在收到Leader的心跳后，其超时时间会重置，即重新开始倒计时。
正常工作期间只有 Leader 和 Follower，且Leader至多只能有一个。

ZAB（ZooKeeper Atomic Broadcast）算法

基本概念
ZAB（Zookeeper Atomic Broadcast）是Zookeeper原子消息广播协议，是Zookeeper保证数据一致性的核心算法。该算法借鉴了Paxos算法，但又不像Paxos那样是一种通用的分布式一致性算法，而是特别为Zookeeper设计的支持崩溃恢复的原子广播协议。
在Zookeeper中，主要依赖ZAB协议来实现数据一致性。基于该协议，Zookeeper实现了一种主备模型（即Leader和Follower模型）的系统架构，保证集群中各个副本之间数据的一致性。通过一台主进程（Leader）负责处理外部的写事务请求，然后将数据同步到其他Follower节点，如果超过半数成功ACK，则主进程执行 Commit操作。

广播流程
ZAB 协议的消息广播过程使用的是一个原子广播协议，类似一个 二阶段(2PC) 提交过程。对于客户端发送的写请求，全部由 Leader 接收，Leader 将请求封装成一个事务 Proposal，将其发送给所有 Follwer ，然后，根据所有 Follwer 的反馈，如果超过半数成功响应，则执行 Commit 操作（先提交自己，再发送 Commit 给所有 Follwer）。

Gossip协议（八卦算法）

基本概念
Gossip协议，也被称为流言协议或八卦协议，是一种在分布式系统中用于节点之间通信和数据同步的算法。其设计灵感来源于人类社交中的流言传播机制，即一个人将消息告诉几个人，这些人再各自将消息传播给其他人，最终使大多数人得知该消息。Gossip协议因其简单、鲁棒、可扩展等特性而被广泛应用于解决大规模分布式系统中的一致性和可靠性问题。
最终一致性：Gossip协议实现的是一种最终一致性，即虽然不能保证在某个特定时刻所有节点都收到消息，但理论上最终所有节点都会收到消息。
两种类型：
Anti-Entropy（反熵）：以固定的概率传播所有的数据，确保系统中节点之间数据的一致性。
Rumor-Mongering（谣言传播）：仅传播新到达的数据，系统有一定的概率会不一致，但开销较小。

流程
Gossip协议的流程通常包括以下几个步骤：
1、消息产生：当一个节点（称为种子节点）有状态需要更新到网络中的其他节点时，该过程开始。
2、随机选择节点：种子节点随机选择其周围的几个节点作为消息的初始传播对象。
3、消息传播：

• Push-based（推模式）：节点向其选中的节点传输数据（可能包括key、value、version等），接收到的节点更新本地数据，并重复该过程。
• Pull-based（拉模式）：节点请求其他节点的数据，接收到请求的节点将本地较新的数据推送给请求节点，请求节点更新本地数据。
  消息扩散：随着消息的传播，越来越多的节点会接收到消息，并继续向其他节点传播，直到最终所有节点都收到消息。