标签：实战 领导者 跟随者 算法 一致性 提案 数据 节点 分布式
一致哈希算法：太简单，看图，使用了一致哈希算法后，扩容或缩容的时候，都只需要重定位环空间中的一小部分数据。也就是说，一致哈希算法具有较好的容错性和可扩展性，虚拟节点解决冷热不均的问题
二阶段提交协议和 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
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。