学习分布式协议与算法实战 ~ 4

一致哈希算法：太简单，看图，使用了一致哈希算法后，扩容或缩容的时候，都只需要重定位环空间中的一小部分数据。也就是说，一致哈希算法具有较好的容错性和可扩展性，虚拟节点解决冷热不均的问题

二阶段提交协议和 Raft 算法都需要全部节点或者大多数节点正常运行，才能稳定运行，如果需要高可用，一台也行，那么就要选择其他算法了

Gossip：就像流言蜚语一样，利用一种随机、带有传染性的方式，将信息传播到整个网络中，并在一定时间内，使得系统内的所有节点数据一致

直接邮寄：就是直接发送更新数据，当数据发送失败时，将数据缓存下来，然后重传，但可能会因为缓存队列满了而丢数据。也就是说，只采用直接邮寄是无法实现最终一致性的

反熵：本质上，反熵是一种通过异步修复（推、拉和推拉三种方式）实现最终一致性的方法，集群中的节点，每隔段时间就随机选择某个其他节点，然后通过互相交换自己的所有数据来消除两者之间的差异，实现数据的最终一致性，因为反熵需要节点两两交换和比对自己所有的数据，执行反熵时通讯成本会很高，所以我不建议你在实际场景中频繁执行反熵，并且可以通过引入校验和（Checksum）等机制，降低需要对比的数据量和通讯消息等

反熵中的熵是指混乱程度，反熵就是指消除不同节点中数据的差异，提升节点间数据的相似度，降低熵值

InfluxDB 的反熵：按照一定顺序来修复节点的数据差异，先随机选择一个节点，然后循环修复，每个节点生成自己节点有、下一个节点没有的差异数据，发送给下一个节点，进行修复，设计了一个闭环的流程，一次修复所有节点的副本数据不一致

强一致性能保证写操作完成后，任何后续访问都能读到更新后的值；最终一致性只能保证如果对某个对象没有新的写操作了，最终所有后续访问都能读到相同的最近更新的值。也就是说，写操作完成后，后续访问可能会读到旧数据

Quorum NWR，你可以自定义一致性级别，通过临时调整写入或者查询的方式，当 W + R > N 时，就可以实现强一致性了

N 表示副本数/W，又称写一致性级别（Write Consistency Level），表示成功完成 W 个副本更新，才完成写操作/R，又称读一致性级别（Read Consistency Level），表示读取一个数据对象时需要读 R 个副本，取最新值

当 W + R > N 的时候，对于客户端来讲，整个系统能保证强一致性，一定能返回更新后的那份数据。当 W + R <= N 的时候，对于客户端来讲，整个系统只能保证最终一致性，可能会返回旧数据。

Quorum NWR 是非常实用的一个算法，能有效弥补 AP 型系统缺乏强一致性的痛点，给业务提供了按需选择一致性级别的灵活度，建议你的开发实现 AP 型系统时，也实现 Quorum NWR

PBFT 算法非常实用，是一种能在实际场景中落地的拜占庭容错算法，它在区块链中应用广泛，通过签名（或消息认证码 MAC）约束恶意节点的行为，采用三阶段协议，基于大多数原则达成共识的。另外，与口信消息型拜占庭问题之解（以及签名消息型拜占庭问题之解）不同的是，PBFT 算法实现的是一系列值的共识，而不是单值的共识

PoW工作量证明 (Proof Of Work，简称 PoW)，区块链是通过执行哈希运算，然后通过运算后的结果值，证明自己做过了相关工作。

Multi-Paxos，虽然能保证达成共识后的值不再改变，但它不关心达成共识的值是什么，也无法保证各值（也就是操作）的顺序性， zab(能保证操作顺序性的，基于主备模式的原子广播协议。) 操作的顺序性、领导者选举、故障恢复、处理读写请求

操作的顺序性: 在 ZAB 中，写操作必须在主节点（比如节点 A）上执行。如果客户端访问的节点是备份节点（比如节点 B），它会将写请求转发给主节点，当主节点接收到写请求后，它会基于写请求中的指令（也就是 X，Y），来创建一个提案（Proposal），并使用一个唯一的 ID 来标识这个提案，事务标识符是 64 位的 long 型变量，有任期编号 epoch 和计数器 counter 两部分组成，任期编号，就是创建提案时领导者的任期编号，需要你注意的是，当新领导者当选时，任期编号递增，计数器被设置为零。计数器，就是具体标识提案的整数，需要你注意的是，每次领导者创建新的提案时，计数器将递增。在创建完提案之后，主节点会基于 TCP 协议，并按照顺序将提案广播到其他节点，主节点提交提案是有顺序性的。主节点根据事务标识符大小，按照顺序提交提案，如果前一个提案未提交，此时主节点是不会提交后一个提案的，

领导者选举：

ZAB 支持 3 种成员身份（领导者、跟随者、观察者），四种状态：LOOKING：选举状态，该状态下的节点认为当前集群中没有领导者，会发起领导者选举。FOLLOWING ：跟随者状态，意味着当前节点是跟随者。LEADING ：领导者状态，意味着当前节点是领导者。OBSERVING： 观察者状态，意味着当前节点是观察者。

所有的写请求都必须在领导者节点上执行，跟随者可以直接处理并响应来自客户端的读请求，但对于写请求，跟随者需要将它转发给领导者处理

<proposedLeader(领导者的集群 ID), proposedEpoch(领导者的任期编号), proposedLastZxid(领导者的事务标识符最大值)，node(投票的节点)>

当跟随者检测到连接领导者节点的读操作等待超时了，跟随者会变更节点状态，将自己的节点状态变更成 LOOKING，然后发起领导者选举，每个节点会创建一张选票，这张选票是投给自己的，一般而言，节点会先接收到自己发送给自己的选票，优先检查任期编号（Epoch），任期编号大的节点作为领导者；如果任期编号相同，比较事务标识符的最大值，值大的节点作为领导者；如果事务标识符的最大值相同，比较集群 ID，集群 ID 大的节点作为领导者，如果选票提议的领导者，比自己提议的领导者，更适合作为领导者，那么节点将调整选票内容，推荐选票提议的领导者作为领导者

领导者选举的目标，是从大多数节点中选举出数据最完整的节点，也就是大多数节点中，事务标识符值最大的节点。另外，ZAB 本质上是通过“见贤思齐，相互推荐”的方式来选举领导者的。也就说，根据领导者 PK，节点会重新推荐更合适的领导者，最终选举出了大多数节点中数据最完整的节点

ZAB 定义了 4 种状态，来标识节点的运行状态。ELECTION（选举状态）：表明节点在进行领导者选举；DISCOVERY（成员发现状态）：表明节点在协商沟通领导者的合法性；SYNCHRONIZATION（数据同步状态）：表明集群的各节点以领导者的数据为准，修复数据副本的一致性；BROADCAST（广播状态）：表明集群各节点在正常处理写请求

在 ZAB 中，选举出了新的领导者后，该领导者不能立即处理写请求，还需要通过成员发现、数据同步 2 个阶段进行故障恢复

在 ZooKeeper 中，写请求是必须在领导者上处理，如果跟随者接收到了写请求，它需要将写请求转发给领导者，当写请求对应的提案被复制到大多数节点上时，领导者会提交提案，并通知跟随者提交提案。而读请求可以在任何节点上处理，也就是说，ZooKeeper 实现的是最终一致性

标签：实战,领导者,跟随者,算法,一致性,提案,数据,节点,分布式
来源： https://www.cnblogs.com/it-worker365/p/14554086.html