深度解析：分布式集群选举机制及其高可用性保障

常见分布式集群选举机制总结

1、Zookeeper-paxos2、kafka-在Zookeeper3上创建节点、redis-Sentinel4模式、Eureka-相互复制。
当我们讨论选择这些集群的机制时，我们实际上是在讨论它们的高可用性。
如果集群部分节点宕机，如何保证可用性？这个问题是分布式系统面临的三个主要问题之一。
Zookeeper的leader选举机制是四个集群中最复杂的选举机制，也是四个集群中最接近paxos算法的实现。
相比Zookeeper的选举机制，Kafka集群、Redis集群、Eureka集群的选举机制要简单得多。
Zookeeper领导者的选举是保证Zookeeper数据一致性的关键，但也存在一些挑战。
了解Zookeeper的优缺点对于我们有效地使用它还是有必要的。
Zookeeper的选举机制有两个触发条件：集群启动阶段和leader挂掉的集群运行阶段。
这两种场景下的选举过程本质上是相同的。
为了说明这一点，我们以集群运行阶段的领导者冻结为例。
领导挂机后，重新选举领导。
选举过程如下：1.Zookeeper集群中的follower检测到leader挂掉，然后将其状态设置为LOOKING，开始选举leader。
2.每个服务器选举自己为领导者，然后通过广播通知其他服务器其投票结果。
3.每个服务器接收其他服务器的投票并进行合法性检查。
验证基本上有两点：检查选举轮次和检查服务器状态。
4.处理选票。
每个服务器将使用其投票以及其他服务器的投票。
PC规则如下：第一规则：ZXIDPC先完成，数量最多者获胜。
第二条规则：如果ZXID相等，则进行PCmyid，较大者获胜。
PK结束后，如果当前服务器PK失败，则会将自己的投票广播给获胜者，然后通过广播通知其他服务器更新的投票结果。
5.计票。
本着更多的原则一半，每个服务器统计leader的票数。
如果超过半数，则选举终止。
6.更新服务器状态。
follower将其状态更新为NEXT，leader将其状态更新为LEAD。
好了，这就是Zookeeper的leader选择机制。
经过几轮选举后，Zookeeper集群继续对外提供服务。
由于投票PC首先比较ZXID，Zookeeper可以确保leader的数据是最新的。
Kafka集群如何提供高可用？Kafka使用Zookeeper来管理集群配置、选举领导者以及在消费者组发生变化时进行重新平衡。
那么我想问一下，Kafka是如何选择Leader的呢？简而言之，KafkaLeader选举流程如下：所有KafkaBroker在/controllerZookeeper路径下创建临时节点。
成功创建的经纪商将成为领导者，剩余的经纪商将成为追随者。
当leader挂掉时，临时节点将会被移除。
这是因为其他节点会通过Zookeeper监控机制监控leader的变化，然后所有follower都会重新选举出leader。
Kafka的选择其实就是临时节点的创建，本质上和Zookeeper的分布式锁实现原理是一样的。
了解Redis主从切换和Redis集群。
需要注意的是，主从切换默认只使用一台Master，但对于多Master集群则没有主从切换。
Redis没有像Zookeeper那样的选举机制。
当Redismaster出现故障后，Redis集群通过主从设备切换来维持高可用性。
Redis主从切换有两种方式：手动切换和自动切换。
这里我们讨论的是自动切换。
Redis主从自动切换需要支持Sentinel模式，简单来说就是：监控master和slave，自动将slave切换成master。
担任新的主人。
奴隶向外界提供服务。
更准确地说，Eureka集群中的节点之间不存在主从关系。
Eureka集群中节点之间的关系是点对点的，其他三个集群是主从关系。
这是Eureka集群的一个特点。
Eureka集群中的不同服务器通过相互注册来保证集群的高可用性。
数据同步方式为增量备份，保证每台服务器都是最新最全的数据。
这保证了集群的高可用性。
这样，即使服务器出现故障，集群仍然能够向外界提供服务。
Eureka有一个配置元素：eureka.client.fetch-register，它允许你从Eurekaserver获取注册信息。
如果我们是Eureka集群，那么此项设置为true。
这样Eurekaserver之间就可以直接互相注册了。
好吧，本文只是大致介绍了四个集群的选举机制，具体的细节还是很复杂的。
之前的文章专门分析了Zookeeper领导人选举，以后还会有文章分析其他几个集群的选举机制。
我们稍后会更详细地解释这一点。

Redis哨兵(Sentinel)机制--高可用的保障

如果用来保证redis集群高可用的monitor是专用机的话，看门狗挂掉重启有多可怕？因此，守望者也被聚集起来，并要求在所有行业进行投票。
（1）故障期间，需要多数哨兵一致判定主节点宕机与分布式选举问题相关。

我们在多台机器上部署了哨兵，它们必须协同工作才能完成一项任务，因此它们形成了一个“分布式系统”。

在分布式系统领域；允许多个节点就某个问题达成共同协议的算法称为共识算法。

在这种情况下，几个守望者聚集在一起选出一位他们都认可的领导者。
它使用共识算法来工作。

该算法规定节点数必须为奇数。
如果系统中某个节点发生故障。
这确保了剩余节点中超过“一半”的节点可以处于正常状态并且仍然保持不变。
提供有效结果；那是，该算法还兼容故障节点的存在。

分布式系统领域有很多共识算法如Paxos、Raft等

sdown和odown两种失败状态

sdown成功的条件如果哨兵被主站ping通；它超越了主-下-后的范围。
以毫秒为单位指定的毫秒数（sentinel配置文件可配置）；在那之后，我主观上认为master挂了。

从sdown变为odown的条件很简单，如果一个士兵在一定时间内获得一定数量的积分。
其他守望者也这么认为。
主正在延迟。
我认为这令人谦卑。
主客观地认为他已经堕落了。

通过redispub/sub系统发送的服务器之间的任何相互发现都会向__sentinel__:hello通道发送一条消息。
该消息可以与其他看门狗一起使用。
感知其他哨兵的存在

每个哨兵都会监听与监控__sentinel__:hellochannel的每个主站关联的从站。
存在其他哨兵监视这些主站+从站

哨兵将自动修改从站的某些方面，例如如果master宕机并选择新的master。
主从设备与主设备连接错误；失败后，守望者将确保他们连接到正确的主机。

如果主机被认为已关闭。
大多数值班人员（允许大多数值班人员。
如果主/备开关打开，此时有员工；必须先选择一个从节点

选择新的主节点会考虑到一些从节点的信息。
(1)首先过滤掉打开时间过长的主连接。
然后（2）slave优先级（3）偏移复制（4）runid

删除长切节点并对slave进行排序（1）按slave优先级类型对slave进行排序；优先级越低；(2)如果从机优先级相同，则优先级越高。
查看从服务器复制更多数据的副本。
你压制得越多，你就能压制得越多。
优先级越高(3)如果满足以上两个条件同样的事情然后选择一个run较小的slave。

主要原理就是断定那个slave拥有的数据是最后的。
主备倒换的条件。

每当哨兵想要在活动和备份之间切换时。
考虑首先删除哨兵组的顶部，然后允许一个哨兵在到达大多数哨兵之前进行更改。
这使得交换机有效

Sentinel将监控redismaster+slave集群并拥有一个版本号和相关的监控配置，每个交换机的版本号必须是唯一的。
（Configurationepoch用于比较你的配置是否是节点最后发布的；请看第8点）

master）开始进行切换。
哨兵切换主从节点。

哨兵完成切换后。
它将在本地更新并生成最新的主配置。
这将通过前面描述的pub/subtext消息传递机制同步到其他Sentinel。

以前这里的版本号非常重要；因为在完成屏幕上的新按钮后，各种消息是通过通道广播和监视的。
新的主配置将遵循新的版本号。

其他看门狗根据版本号更新其主配置（如果发现其版本晚于接收到的版本，则更新其主配置）

如何评价redis的高可用详解?

Redis高可用解决方案提供持久化、主从复制；由哨兵和集群组成。
持久化方案重点关注数据备份，保证数据安全可靠。
主从复制机制侧重于多机热备份和数据故障转移，同时提供负载均衡和提高性能。
Sentinel系统专注于监视和更改服务事件以提高高可用性。
扩展数据存储限制从服务实例和数据层面入手，实现数据容灾和高可用。
主从复制上下文中的使用方法；基本原理（全转录、部分转录、心跳机制）；应用中需要特别注意的问题（数据不一致、复制超时、缓冲区溢出）和配置（重试超时、client-output-buffer-limitslave）等。
在主从复制过程中发起复制；包括数据同步和命令分发步骤。
Redis采用乐观复制策略，允许主从之间数据暂时变化，最终实现同步。
主从复制策略针对不同场景优化的全量复制；部分复制和并行复制之间存在区别。
全量复制用于主从初始化或从机切换，主服务器通过RDB文件发送数据。
在部分复制中，主从延迟或者从机重启等异常情况。
主服务器向从服务器发送部分信息。
转录缓存区用于存储主服务器数据，主从服务器偏移量用于确定数据一致性。
主从建立后，异步复制继续进行，主服务器的写操作与从服务器同步。
数据安全策略，例如设置“replica-read-onlyyes”和“masterauth”以增强保护。
关注数据延迟问题并通过“repl-disable-tcp-nodelayyes”进行管理。
为了保证实时性，主从节点连接状态监控通过`repl-ping-replica-period`和`repl-ping-slave-period`指定。