09 | Raft算法（三）：如何解决成员变更的问题？
该思维导图由 AI 生成，仅供参考
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
本文深入介绍了Raft算法中的成员变更问题以及解决方法。在集群中进行成员变更时，可能出现两个领导者的情况，违背了Raft集群的领导者唯一性原则，影响了集群的稳定运行。为了解决这个问题，文章提出了单节点变更的方法，通过一次变更一个节点的方式，完成成员变更，保证集群中始终只有一个领导者，并且集群能够稳定运行。此外，文章还提到了在分区错误、节点故障等情况下可能出现的问题，并给出了解决办法。文章还介绍了Raft算法的特点和应用场景，以及在实际工程中的应用案例。总的来说，本文通过深入讲解成员变更的问题和单节点变更的原理，帮助读者更好地理解Raft算法，并掌握解决成员变更问题的方法。文章内容丰富，涵盖了Raft算法的原理、应用和实际场景中的应用案例，对于想要深入了解共识算法的读者具有很高的参考价值。
《分布式协议与算法实战》，新⼈⾸单¥59
全部留言(57)
- 最新
- 精选
每天晒白牙可以参考Kafka的分区和ES的主分片副本分片这种机制，虽然写入只能通过leader写，但每个leader可以负责不同的片区，来提高写入的性能作者回复: 加一颗星:)
2020-03-02557
XHH1、leader可以合并请求 2、leader提交日志和日志复制RPC两个步骤可以并行和批量处理 3、leader可以并发和异步对所有follower 并发日志复制，同时可以利用pipeline的方式提高效率 4、每个节点启动多个raft实例，对请求进行hash或者range后，让每个raft实例负责部分请求作者回复: 加一颗星:)
2020-03-02233
竹马彦四郎的好朋友影法師韩老师您好~ (A,B,C) 三个旧配置A是leader，然后加入D，然后网络分区为(A,B)和(C,D), 那么A依旧赢得大多数选票而是leader. C因为分区，所以也开始发起选举，赢得了C、D的选票，注意哦~ ，C也是旧配置哦~ 那么C不也就成为leader了么? 所以不就出现了2个leader了么? 也就是D作为新配置固然无法成为leader，但是C作为旧配置还是可以成为leader的呀~ 希望您能指点一下. 但是我说一下我的看法，我的看法是——您一开始在"成员变更的问题"中举的例子貌似有点问题——应该是C、D、E中的D或者E会成为新配置中的leader而不是C节点会成为新配置中的leader，因为C的（旧）配置中原本就没有D、E，它即便获取到D、E的选票也不能认为自己得票过半，这样就能解释的通了。作者回复: 加一颗星:)，C如果属于旧配置，它无法得到D的投票，因为旧配置不包括D，所以C不会成为leader。
2020-05-04227
kylexy_0817韩老师，有个问题，其实在实际生产环境中，是不是应该尽量避免网络分区才是重点，例如把某个集群的机器，尽量放在同一个内网中。举个我想到的例子，ABC三个节点，A在网络1，BC在网络2，初始化时，A成为了领导者，后来在网络2的单节点D加入集群，此时正好出现网络分区，BCD重新重新选举，得到B是领导者，后面网络通讯恢复了，这样即使采用单节点变更的方式，不也同样会出现了脑裂了吗？不知道我的理解正不正确，求解答。作者回复: 加一颗星:)，问题1：集群一般放在同一个机房中的，公网存在网络抖动、消息丢失等问题，网络分区，更准确的说，是指任意数量的消息丢失或者高延迟，这在同一个机房内，也是无法避免，比如进程崩溃了、机器高负载等。问题2：不会，旧领导者A会退位，在leader lease（比如Hashicorp raft的默认值是500ms）到期后，而且即使在leader lease期间，旧领导者也无法执行领导者的功能，因为他无法联系上大多数节点，所以，这时，准确来说，只有一个领导者，B，也就是，不存在脑裂问题的。
2020-04-1918
黄海峰老师，这种共识算法只是用于p2p的分布式系统吧，像hadoop/spark这些大数据分布式系统都是主从模式，部署就决定了谁是master，根本就不用这些共识算法了。。。相对比主从模式更可靠更可控啊，因为没有这些这么复杂的选举逻辑。。除了区块链，其他系统用p2p是不是有什么不可取代的必要性呢？作者回复: 加一颗星:)，如果主节点是静态配置的，宕机了怎么办呢？选择哪个节点作为从节点呢？副本数据不一致，怎么处理呢？共识算法，实现的是强一致性和分区容错能力。场景决定了系统形态。
2020-03-03214
朱东旭一致性算法与共识算法的区别是啥，raft以领导者的日志为准，不就是保证了数据的最终一致吗。作者回复: 在中文中，很多资料将Consensus翻译成了一致性，和Consistency同义，其实应该翻译成共识，共识算法是实现一系列值的共识的。可以这么理解，但基于Raft，能实现强一致性，也就是线性一致性。后续规划了一篇，会具体说说这些内容。
2020-03-0329
约书亚一般而言，在实际工程中，Consul 的 consistent 就够用了，可以不用线性一致性， 这句话是不是笔误了？作者回复: 关于Raft的一些高级特性，比如客户端协议、uncommited log丢失、指令重复执行等，在加餐篇，规划了一讲，统一补充，所以这里关于线性一致性没有展开聊。 需要客户端协议的配合，才能实现“exactly once”，实现线性一致性，但很多时候，只要指令重复执行，对最终的结果没有影响，就够用了。更多细节，我会在加餐篇，具体说说。
2020-03-0259- static老师好，想请教一个困扰我很久的关于Raft算法的一个问题。 在分布式锁场景下（使用Raft算法），A客户端向leader申请获取锁（set lock），此时leader应用lock信息日志，并RPC复制日志信息给follower节点，此时follower节点还没应用到状态机，leader收到大部分follower成功信息，自己应用了状态机并返回客户端说set lock成功，但此时leader宕机了，其中一个follower变为leader，此时客户端B来获取锁，发现leader没有lock信息（因为follower将lock信息应用到状态机靠leader心跳传递，但刚刚leader宕机了没来得及传递），客户端B此时获取锁也成功了，这不就破坏了锁的同步性吗？Raft算法是如何保证这种场景下的强一致性（线性一致性）？
作者回复: 加一颗星:)，我后面会做个补充:)
2020-03-2158 
Kvicii.YNO_OP这个空日志项该怎么理解呢，为了防止出现多个领导者？怎么防止的呢作者回复: 加一颗星:)，一次单节点变更完成后，再执行下一次单节点变更，是能保证只有一个领导者的正确性的，而引入NO_OP 日志项，是为了确保可能的在执行的单节点变更，已执行完成。
2020-06-2127
ξ！老师，在配置单节点加入的时候，是怎么发现当前集群的呢，难道是在配置的时候就将集群的节点信息写入了么，即便这样的话，当前节点是怎么发现当前集群的领导者呢，在新节点加入的时候他是怎么知道当前集群的领导者的呢，这个发现领导者的过程是新节点主动发起的rpc还是领导者的心跳发现的呢作者回复: 加一颗星:)，1. 向领导者“申请”，由领导者完成节点添加。2. 如何发现领导者，与实现有关，一般来说，可以采用这么两种实现：a. 若非领导者节点接收到“添加节点”请求时，返回领导者信息给新节点，然后新节点重新发送请求；b. 若非领导者节点接收到“添加节点”请求时，将该请求转发给领导者。具体实现，可参考19、20讲的代码。
2020-11-176
