【杂谈】主备结构与选主方式

为什么需要主备结构？

为了确保服务的高可用性，系统不能因为某一个节点的故障而完全不可用。因此，我们需要通过主备结构来确保在主节点发生故障时，备份节点能够迅速接管，继续提供服务。

为什么不直接通过多个节点共同提供服务？

因为这种节点提供的是数据维护和存储服务，为了确保数据的连续性和一致性，就只能由一个节点集中处理。如果多个节点同时处理数据，可能会导致数据的不一致或混乱。

比如：Mysql主从复制，Kafka的分区副本，Redis的主从复制。

主备结构是如何运作的？

主备结构通常由两个角色组成：Leader（主节点）和Follower（备份节点）。在这个结构中，Leader节点负责处理所有的客户端请求，维护数据。而Follower节点则定期从Leader节点同步数据。当Leader节点发生故障或不可用时，系统就需要进行选主操作。选主的目的是从现有的Follower节点中选出一个新的Leader，以确保系统的正常运行。

选主的核心工作是什么？

选主的核心任务可以总结为以下几点：

1. 监控Leader节点的状态：持续检测Leader节点的健康状况。
2. 选举新的Leader：当Leader节点挂掉时，从Follower节点中选举出一个新的Leader。
3. 通知其他Follower节点：新Leader选出后，需要通知其他Follower节点，让它们切换到新Leader同步数据。

谁来负责选主？

选主操作通常由两种方式来处理：

1. 第三方协调者：通过引入一个独立的第三方系统来协调选主，比如Zookeeper、etcd等。这些工具能够监控节点状态并负责选主。

2. 同级节点：在没有第三方协调者的情况下，主备结构的节点会通过彼此的协调进行选主，通常是由Follower节点通过一定的算法（如Paxos或Raft）选出新的Leader。

第三方协调者，Zookeeper如何选主？

Zookeeper通过心跳机制（会话超时检测）来检测每个服务节点的运行状态。启动时，多个服务节点会在Zookeeper上按顺序生成临时顺序节点，序号最小的成为Leader节点。每个节点会监听前一个节点的状态，如果前一个节点挂掉（即它的临时节点被删除），当前节点就会变成Leader节点，并通知其他Follower节点进行同步。

这种选举方案并没有传统意义上的“投票”过程，只是通过顺序节点的编号自动接替，最小编号的节点成为Leader。

//官网描述
//https://zookeeper.apache.org/doc/current/recipes.html

Leader Election
A simple way of doing leader election with ZooKeeper is to use the SEQUENCE|EPHEMERAL flags when creating znodes that represent "proposals" of clients. The idea is to have a znode, say "/election", such that each znode creates a child znode "/election/guid-n_" with both flags SEQUENCE|EPHEMERAL. With the sequence flag, ZooKeeper automatically appends a sequence number that is greater than anyone previously appended to a child of "/election". The process that created the znode with the smallest appended sequence number is the leader.

That's not all, though. It is important to watch for failures of the leader, so that a new client arises as the new leader in the case the current leader fails. A trivial solution is to have all application processes watching upon the current smallest znode, and checking if they are the new leader when the smallest znode goes away (note that the smallest znode will go away if the leader fails because the node is ephemeral). But this causes a herd effect: upon a failure of the current leader, all other processes receive a notification, and execute getChildren on "/election" to obtain the current list of children of "/election". If the number of clients is large, it causes a spike on the number of operations that ZooKeeper servers have to process. To avoid the herd effect, it is sufficient to watch for the next znode down on the sequence of znodes. If a client receives a notification that the znode it is watching is gone, then it becomes the new leader in the case that there is no smaller znode. Note that this avoids the herd effect by not having all clients watching the same znode.

问题就是，接替上来的Follower节点，其数据未必是最新的

一种变体：利用Zookeeper选出控制器

Kafka利用Zookeeper选出控制器（Controller），然后由Controller来控制分区首领的选举。它可以进一步判断分区副本的同步偏移量，来选出数据最新的副本作为分区首领。

基于第三方协调者的实现虽然简单，但存在单点故障问题。zookeeper如何挂掉，就无法及时选出主节点。

同级节点：Raft协议如何选主？

Raft 协议的选主过程不依赖第三方协调者，而是由服务节点之间通过互相通信来进行决策。Raft 选主的过程涉及几个关键问题：

1. Follower节点如何确定Leader节点是否正常？

Raft 协议通过 心跳机制（通常是 AppendEntries RPC）来保持 Leader 节点的存活状态。Leader 节点定期向 Follower 节点发送心跳信号。如果 Follower 节点在一定时间内没有收到 Leader 的心跳信号，它会认为 Leader 节点可能已挂掉，进而发起选举。

2. Leader节点挂掉后，如何选主？

当 Leader 节点挂掉或无法继续提供服务时，Follower 节点会开始 投票 来选举新的 Leader：

• Follower节点如何投票：每个 Follower 节点会为自己拉票，它会请求其他节点投票支持自己成为新的 Leader。Raft 协议中，每个节点都有一个 任期（term），每个选举周期都会有一个新的任期号。节点通过比较任期号来判断是否接受对方的投票。

• 投票规则：在选举过程中，票数最多的节点成为新的 Leader。每个节点只能投一票，而且该票只能投给一个任期号大于自己当前任期号的节点。得票数超过半数的节点成为 Leader。

关于“投票”

1. Follower节点如何知道总共有哪些Follower节点？

   Follower 节点通过 Leader 节点获得集群中其他节点的信息。Leader 节点会定期通过心跳（AppendEntries RPC）向 Follower 节点传递集群成员的信息。Follower 节点在没有 Leader 时，会基于之前的集群信息来进行选举。

2. Follower节点如何拉票？

   Follower 节点通过 请求投票（RequestVote RPC）向其他节点请求支持。每个 Follower 节点会在自己的选举任期内发起投票请求，要求其他节点为自己投票。如果请求节点的任期更大，并且数据更新，被请求方就会同意投票请求。

3. Follower节点如何确定自己票数最多？

   Follower 节点并不需要知道其他节点的具体得票情况。Raft 协议保证，当一个节点获得大多数（过半数）节点的支持时，它会成为 Leader。在选举过程中，节点只需要确保自己获得过半数的选票，而不需要知道其他节点的具体得票情况。

3. 原Leader节点恢复运行后怎么办？是否会出现两个Leader节点？

Raft 协议通过 任期号（Term）来防止出现两个 Leader 节点。当原 Leader 节点恢复运行时，它会发现自己所属的任期号已经过期（即其他节点已选出了新的 Leader），因此它会自动变成 Follower 节点，并接受新的 Leader 的控制。

• 任期号：每次选举时，都会增加任期号。所有节点都会跟踪当前的任期号，任期号大的节点会被视为合法的 Leader。当原 Leader 节点恢复时，由于它的任期号较旧，它会识别出自己已不再是 Leader，从而转变为 Follower。

Raft协议是否解决拜占庭问题？

没有。可以这样说，Raft 协议 的前提假设是集群中的节点是由可信方部署和控制的，且这些节点会按照协议规则运行，不存在执行恶意操作的情况。

总结

主备架构不仅仅应用于数据库和缓存系统，很多微服务架构、消息队列和分布式存储系统都需要通过主备结构来保证系统的高可用性。随着技术的进步，现代的主备结构逐渐引入了更智能的选主机制，确保即使在极端条件下也能迅速恢复服务。