极客时间已完结课程限时免费阅读

07 | 哨兵机制：主库挂了，如何不间断服务？

07 | 哨兵机制：主库挂了，如何不间断服务？-极客时间

07 | 哨兵机制：主库挂了，如何不间断服务？

2020-08-19 蒋德钧 来自北京
《Redis核心技术与实战》
课程介绍

讲述：蒋德钧

时长15:23大小14.09M

你好，我是蒋德钧。
上节课，我们学习了主从库集群模式。在这个模式下，如果从库发生故障了，客户端可以继续向主库或其他从库发送请求，进行相关的操作，但是如果主库发生故障了，那就直接会影响到从库的同步，因为从库没有相应的主库可以进行数据复制操作了。
而且，如果客户端发送的都是读操作请求，那还可以由从库继续提供服务，这在纯读的业务场景下还能被接受。但是，一旦有写操作请求了，按照主从库模式下的读写分离要求，需要由主库来完成写操作。此时，也没有实例可以来服务客户端的写操作请求了，如下图所示：
主库故障后从库无法服务写操作
无论是写服务中断，还是从库无法进行数据同步，都是不能接受的。所以，如果主库挂了，我们就需要运行一个新主库，比如说把一个从库切换为主库，把它当成主库。这就涉及到三个问题：
主库真的挂了吗？
该选择哪个从库作为主库？
怎么把新主库的相关信息通知给从库和客户端呢？
这就要提到哨兵机制了。在 Redis 主从集群中，哨兵机制是实现主从库自动切换的关键机制，它有效地解决了主从复制模式下故障转移的这三个问题。
接下来，我们就一起学习下哨兵机制。

哨兵机制的基本流程

哨兵其实就是一个运行在特殊模式下的 Redis 进程，主从库实例运行的同时，它也在运行。哨兵主要负责的就是三个任务：监控、选主（选择主库）和通知。
我们先看监控。监控是指哨兵进程在运行时，周期性地给所有的主从库发送 PING 命令，检测它们是否仍然在线运行。如果从库没有在规定时间内响应哨兵的 PING 命令，哨兵就会把它标记为“下线状态”；同样，如果主库也没有在规定时间内响应哨兵的 PING 命令，哨兵就会判定主库下线，然后开始自动切换主库的流程。
这个流程首先是执行哨兵的第二个任务，选主。主库挂了以后，哨兵就需要从很多个从库里，按照一定的规则选择一个从库实例，把它作为新的主库。这一步完成后，现在的集群里就有了新主库。
然后，哨兵会执行最后一个任务：通知。在执行通知任务时，哨兵会把新主库的连接信息发给其他从库，让它们执行 replicaof 命令，和新主库建立连接，并进行数据复制。同时，哨兵会把新主库的连接信息通知给客户端，让它们把请求操作发到新主库上。
我画了一张图片，展示了这三个任务以及它们各自的目标。
哨兵机制的三项任务与目标
在这三个任务中，通知任务相对来说比较简单，哨兵只需要把新主库信息发给从库和客户端，让它们和新主库建立连接就行，并不涉及决策的逻辑。但是，在监控和选主这两个任务中，哨兵需要做出两个决策：
在监控任务中，哨兵需要判断主库是否处于下线状态；
在选主任务中，哨兵也要决定选择哪个从库实例作为主库。
接下来，我们就先说说如何判断主库的下线状态。
你首先要知道的是，哨兵对主库的下线判断有“主观下线”和“客观下线”两种。那么，为什么会存在两种判断呢？它们的区别和联系是什么呢？

主观下线和客观下线

我先解释下什么是“主观下线”。
哨兵进程会使用 PING 命令检测它自己和主、从库的网络连接情况，用来判断实例的状态。如果哨兵发现主库或从库对 PING 命令的响应超时了，那么，哨兵就会先把它标记为“主观下线”。
如果检测的是从库，那么，哨兵简单地把它标记为“主观下线”就行了，因为从库的下线影响一般不太大，集群的对外服务不会间断。
但是，如果检测的是主库，那么，哨兵还不能简单地把它标记为“主观下线”，开启主从切换。因为很有可能存在这么一个情况：那就是哨兵误判了，其实主库并没有故障。可是，一旦启动了主从切换，后续的选主和通知操作都会带来额外的计算和通信开销。
为了避免这些不必要的开销，我们要特别注意误判的情况。
首先，我们要知道啥叫误判。很简单，就是主库实际并没有下线，但是哨兵误以为它下线了。误判一般会发生在集群网络压力较大、网络拥塞，或者是主库本身压力较大的情况下。
一旦哨兵判断主库下线了，就会开始选择新主库，并让从库和新主库进行数据同步，这个过程本身就会有开销，例如，哨兵要花时间选出新主库，从库也需要花时间和新主库同步。而在误判的情况下，主库本身根本就不需要进行切换的，所以这个过程的开销是没有价值的。正因为这样，我们需要判断是否有误判，以及减少误判。
那怎么减少误判呢？在日常生活中，当我们要对一些重要的事情做判断的时候，经常会和家人或朋友一起商量一下，然后再做决定。
哨兵机制也是类似的，它通常会采用多实例组成的集群模式进行部署，这也被称为哨兵集群。引入多个哨兵实例一起来判断，就可以避免单个哨兵因为自身网络状况不好，而误判主库下线的情况。同时，多个哨兵的网络同时不稳定的概率较小，由它们一起做决策，误判率也能降低。
这节课，你只需要先理解哨兵集群在减少误判方面的作用，就行了。至于具体的运行机制，下节课我们再重点学习。
在判断主库是否下线时，不能由一个哨兵说了算，只有大多数的哨兵实例，都判断主库已经“主观下线”了，主库才会被标记为“客观下线”，这个叫法也是表明主库下线成为一个客观事实了。这个判断原则就是：少数服从多数。同时，这会进一步触发哨兵开始主从切换流程。
为了方便你理解，我再画一张图展示一下这里的逻辑。
如下图所示，Redis 主从集群有一个主库、三个从库，还有三个哨兵实例。在图片的左边，哨兵 2 判断主库为“主观下线”，但哨兵 1 和 3 却判定主库是上线状态，此时，主库仍然被判断为处于上线状态。在图片的右边，哨兵 1 和 2 都判断主库为“主观下线”，此时，即使哨兵 3 仍然判断主库为上线状态，主库也被标记为“客观下线”了。
客观下线的判断
简单来说，“客观下线”的标准就是，当有 N 个哨兵实例时，最好要有 N/2 + 1 个实例判断主库为“主观下线”，才能最终判定主库为“客观下线”。这样一来，就可以减少误判的概率，也能避免误判带来的无谓的主从库切换。（当然，有多少个实例做出“主观下线”的判断才可以，可以由 Redis 管理员自行设定）。
好了，到这里，你可以看到，借助于多个哨兵实例的共同判断机制，我们就可以更准确地判断出主库是否处于下线状态。如果主库的确下线了，哨兵就要开始下一个决策过程了，即从许多从库中，选出一个从库来做新主库。

如何选定新主库？

一般来说，我把哨兵选择新主库的过程称为“筛选 + 打分”。简单来说，我们在多个从库中，先按照一定的筛选条件，把不符合条件的从库去掉。然后，我们再按照一定的规则，给剩下的从库逐个打分，将得分最高的从库选为新主库，如下图所示：
新主库的选择过程
在刚刚的这段话里，需要注意的是两个“一定”，现在，我们要考虑这里的“一定”具体是指什么。
首先来看筛选的条件。
一般情况下，我们肯定要先保证所选的从库仍然在线运行。不过，在选主时从库正常在线，这只能表示从库的现状良好，并不代表它就是最适合做主库的。
设想一下，如果在选主时，一个从库正常运行，我们把它选为新主库开始使用了。可是，很快它的网络出了故障，此时，我们就得重新选主了。这显然不是我们期望的结果。
所以，在选主时，除了要检查从库的当前在线状态，还要判断它之前的网络连接状态。如果从库总是和主库断连，而且断连次数超出了一定的阈值，我们就有理由相信，这个从库的网络状况并不是太好，就可以把这个从库筛掉了。
具体怎么判断呢？你使用配置项 down-after-milliseconds * 10。其中，down-after-milliseconds 是我们认定主从库断连的最大连接超时时间。如果在 down-after-milliseconds 毫秒内，主从节点都没有通过网络联系上，我们就可以认为主从节点断连了。如果发生断连的次数超过了 10 次，就说明这个从库的网络状况不好，不适合作为新主库。
好了，这样我们就过滤掉了不适合做主库的从库，完成了筛选工作。
接下来就要给剩余的从库打分了。我们可以分别按照三个规则依次进行三轮打分，这三个规则分别是从库优先级、从库复制进度以及从库 ID 号。只要在某一轮中，有从库得分最高，那么它就是主库了，选主过程到此结束。如果没有出现得分最高的从库，那么就继续进行下一轮。
第一轮：优先级最高的从库得分高。
用户可以通过 slave-priority 配置项，给不同的从库设置不同优先级。比如，你有两个从库，它们的内存大小不一样，你可以手动给内存大的实例设置一个高优先级。在选主时，哨兵会给优先级高的从库打高分，如果有一个从库优先级最高，那么它就是新主库了。如果从库的优先级都一样，那么哨兵开始第二轮打分。
第二轮：和旧主库同步程度最接近的从库得分高。
这个规则的依据是，如果选择和旧主库同步最接近的那个从库作为主库，那么，这个新主库上就有最新的数据。
如何判断从库和旧主库间的同步进度呢？
上节课我向你介绍过，主从库同步时有个命令传播的过程。在这个过程中，主库会用 master_repl_offset 记录当前的最新写操作在 repl_backlog_buffer 中的位置，而从库会用 slave_repl_offset 这个值记录当前的复制进度。
此时，我们想要找的从库，它的 slave_repl_offset 需要最接近 master_repl_offset。如果在所有从库中，有从库的 slave_repl_offset 最接近 master_repl_offset，那么它的得分就最高，可以作为新主库。
就像下图所示，旧主库的 master_repl_offset 是 1000，从库 1、2 和 3 的 slave_repl_offset 分别是 950、990 和 900，那么，从库 2 就应该被选为新主库。
基于复制进度的新主库选主原则
当然，如果有两个从库的 slave_repl_offset 值大小是一样的（例如，从库 1 和从库 2 的 slave_repl_offset 值都是 990），我们就需要给它们进行第三轮打分了。
第三轮：ID 号小的从库得分高。
每个实例都会有一个 ID，这个 ID 就类似于这里的从库的编号。目前，Redis 在选主库时，有一个默认的规定：在优先级和复制进度都相同的情况下，ID 号最小的从库得分最高，会被选为新主库。
到这里，新主库就被选出来了，“选主”这个过程就完成了。
我们再回顾下这个流程。首先，哨兵会按照在线状态、网络状态，筛选过滤掉一部分不符合要求的从库，然后，依次按照优先级、复制进度、ID 号大小再对剩余的从库进行打分，只要有得分最高的从库出现，就把它选为新主库。

小结

这节课，我们一起学习了哨兵机制，它是实现 Redis 不间断服务的重要保证。具体来说，主从集群的数据同步，是数据可靠的基础保证；而在主库发生故障时，自动的主从切换是服务不间断的关键支撑。
Redis 的哨兵机制自动完成了以下三大功能，从而实现了主从库的自动切换，可以降低 Redis 集群的运维开销：
监控主库运行状态，并判断主库是否客观下线；
在主库客观下线后，选取新主库；
选出新主库后，通知从库和客户端。
为了降低误判率，在实际应用时，哨兵机制通常采用多实例的方式进行部署，多个哨兵实例通过“少数服从多数”的原则，来判断主库是否客观下线。一般来说，我们可以部署三个哨兵，如果有两个哨兵认定主库“主观下线”，就可以开始切换过程。当然，如果你希望进一步提升判断准确率，也可以再适当增加哨兵个数，比如说使用五个哨兵。
但是，使用多个哨兵实例来降低误判率，其实相当于组成了一个哨兵集群，我们会因此面临着一些新的挑战，例如：
哨兵集群中有实例挂了，怎么办，会影响主库状态判断和选主吗？
哨兵集群多数实例达成共识，判断出主库“客观下线”后，由哪个实例来执行主从切换呢？
要搞懂这些问题，就不得不提哨兵集群了，下节课，我们来具体聊聊哨兵集群的机制和问题。

每课一问

按照惯例，我给你提个小问题。这节课，我提到，通过哨兵机制，可以实现主从库的自动切换，这是实现服务不间断的关键支撑，同时，我也提到了主从库切换是需要一定时间的。所以，请你考虑下，在这个切换过程中，客户端能否正常地进行请求操作呢？如果想要应用程序不感知服务的中断，还需要哨兵或需要客户端再做些什么吗？
欢迎你在留言区跟我交流讨论，也欢迎你能帮我把今天的内容分享给更多人，帮助他们一起解决问题。我们下节课见。
分享给需要的人，Ta购买本课程，你将得20元
生成海报并分享

赞 152

提建议

© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
上一篇
06 | 数据同步：主从库如何实现数据一致？
下一篇
08 | 哨兵集群：哨兵挂了，主从库还能切换吗？
unpreview
 写留言

精选留言(96)

  • Monday
    置顶
    2020-08-19
    1、master_repl_offset是存储在主库的，但主库已经挂了，怎么获取的这个值？ 可否这样理解，master_repl_offset如事物id一样单调递增，这样的话，就只要不叫从库的slave_repl_offset就行。 至于master_repl_offset真实位置可以对master_repl_offset取模就行。

    作者回复: 对master_repl_offset本身的理解没错，master_repl_offset是单调增加的，它的值可以大于repl_backlog_size。Redis会用一个名为repl_backlog_idx的值记录在环形缓冲区中的最新写入位置。 举个例子，例如写入len的数据，那么 master_repl_offset += len repl_backlog_idx += len 但是，如果repl_backlog_idx等于repl_backlog_size时，repl_backlog_idx会被置为0，表示从环形缓冲区开始位置继续写入。 而在实际的选主代码层面，sentinel是直接比较从库的slave_repl_offset，来选择和主库最接近的从库。

    共 25 条评论
    90
  • Kaito
    2020-08-19
    哨兵在操作主从切换的过程中，客户端能否正常地进行请求操作？ 如果客户端使用了读写分离，那么读请求可以在从库上正常执行，不会受到影响。但是由于此时主库已经挂了，而且哨兵还没有选出新的主库，所以在这期间写请求会失败，失败持续的时间 = 哨兵切换主从的时间 + 客户端感知到新主库 的时间。 如果不想让业务感知到异常，客户端只能把写失败的请求先缓存起来或写入消息队列中间件中，等哨兵切换完主从后，再把这些写请求发给新的主库，但这种场景只适合对写入请求返回值不敏感的业务，而且还需要业务层做适配，另外主从切换时间过长，也会导致客户端或消息队列中间件缓存写请求过多，切换完成之后重放这些请求的时间变长。 哨兵检测主库多久没有响应就提升从库为新的主库，这个时间是可以配置的（down-after-milliseconds参数）。配置的时间越短，哨兵越敏感，哨兵集群认为主库在短时间内连不上就会发起主从切换，这种配置很可能因为网络拥塞但主库正常而发生不必要的切换，当然，当主库真正故障时，因为切换得及时，对业务的影响最小。如果配置的时间比较长，哨兵越保守，这种情况可以减少哨兵误判的概率，但是主库故障发生时，业务写失败的时间也会比较久，缓存写请求数据量越多。 应用程序不感知服务的中断，还需要哨兵和客户端做些什么？当哨兵完成主从切换后，客户端需要及时感知到主库发生了变更，然后把缓存的写请求写入到新库中，保证后续写请求不会再受到影响，具体做法如下： 哨兵提升一个从库为新主库后，哨兵会把新主库的地址写入自己实例的pubsub（switch-master）中。客户端需要订阅这个pubsub，当这个pubsub有数据时，客户端就能感知到主库发生变更，同时可以拿到最新的主库地址，然后把写请求写到这个新主库即可，这种机制属于哨兵主动通知客户端。 如果客户端因为某些原因错过了哨兵的通知，或者哨兵通知后客户端处理失败了，安全起见，客户端也需要支持主动去获取最新主从的地址进行访问。 所以，客户端需要访问主从库时，不能直接写死主从库的地址了，而是需要从哨兵集群中获取最新的地址（sentinel get-master-addr-by-name命令），这样当实例异常时，哨兵切换后或者客户端断开重连，都可以从哨兵集群中拿到最新的实例地址。 一般Redis的SDK都提供了通过哨兵拿到实例地址，再访问实例的方式，我们直接使用即可，不需要自己实现这些逻辑。当然，对于只有主从实例的情况，客户端需要和哨兵配合使用，而在分片集群模式下，这些逻辑都可以做在proxy层，这样客户端也不需要关心这些逻辑了，Codis就是这么做的。 另外再简单回答下哨兵相关的问题： 1、哨兵集群中有实例挂了，怎么办，会影响主库状态判断和选主吗？ 这个属于分布式系统领域的问题了，指的是在分布式系统中，如果存在故障节点，整个集群是否还可以提供服务？而且提供的服务是正确的？ 这是一个分布式系统容错问题，这方面最著名的就是分布式领域中的“拜占庭将军”问题了，“拜占庭将军问题”不仅解决了容错问题，还可以解决错误节点的问题，虽然比较复杂，但还是值得研究的，有兴趣的同学可以去了解下。 简单说结论：存在故障节点时，只要集群中大多数节点状态正常，集群依旧可以对外提供服务。具体推导过程细节很多，大家去查前面的资料了解就好。 2、哨兵集群多数实例达成共识，判断出主库“客观下线”后，由哪个实例来执行主从切换呢？ 哨兵集群判断出主库“主观下线”后，会选出一个“哨兵领导者”，之后整个过程由它来完成主从切换。 但是如何选出“哨兵领导者”？这个问题也是一个分布式系统中的问题，就是我们经常听说的共识算法，指的是集群中多个节点如何就一个问题达成共识。共识算法有很多种，例如Paxos、Raft，这里哨兵集群采用的类似于Raft的共识算法。 简单来说就是每个哨兵设置一个随机超时时间，超时后每个哨兵会请求其他哨兵为自己投票，其他哨兵节点对收到的第一个请求进行投票确认，一轮投票下来后，首先达到多数选票的哨兵节点成为“哨兵领导者”，如果没有达到多数选票的哨兵节点，那么会重新选举，直到能够成功选出“哨兵领导者”。
    展开
    共 68 条评论
    881
  • 注定非凡
    2020-08-23
    一，作者讲了什么？ Redis故障转移：主从切换机制哨兵 二，作者是怎么把这事给讲明白的？ 1，提出主从切换的三个问题：a，主机状态确认 b，新主库选举 c，新主库通知 2，讲解了哨兵的本质是一个特殊的redis进程（实例），有三个职责：监控，选主，通知 三，为了讲明白，作者讲了哪些要点，有哪些亮点？ 1，亮点1：哨兵的本质：是一个redis实例，要做三件事：监控主库，选举新主库，通知客户端和从机（这让我对哨兵理解清晰了很多） 2，要点1：哨兵是通过心跳检测，监控主库状态，主库下线被分为：主观下线和客观下线、 3，要点2：哨兵监控是可能误判的，所以哨兵一般是集群部署，采取投票的形式减少误判 4，要点3：选定新主库规则是先筛选在打分，得分高的会被选为新主库， 5，要点4：筛选规则：从库当前的网络连接状况，以及之前的网络连接状况，筛选中断次数标准可以配置 6，要点5：打分规则：从库的优先级，数据同步状况，Id号大小，可以分为三轮，只要有一轮出现得分高的，就能选出 四，对作者所讲，我有哪些发散性思考？ 选举机制，在分布式的场景中经常出现。我在刚开始学习这一类知识的时候，经常会想：那些大神是怎么会想到这种解决方案的？ 后来读了一些西方社会运行机制的书，我有所释然。得到一些感悟：大神思考的技术问题解决方案，和他所生活的社会环境有着莫大的关系 五，将来在哪些场景，我能够使用到它？ 六，留言区的收获 1，数据同步状况的判断：（感谢@Monday 同学的提问） a：判断哪个从库的数据同步最接近主库，不是拿从库与主库比较，而是从库之间互相比较，谁大谁就是最接近的 b：这样做的原因有二：主库已下线无法获取主库信息，环形缓冲区的位置偏移量是单调递增的（主库的被称为：master_repl_offset，从库的被称为：slave_repl_offset，其实两者本质是相同的，叫不同的名字只是为了区分） 2，哨兵的使用：（感谢 @Kaito 大神简洁明了，无私的分享） a：主库下线，可读不可写，写失败的时间=哨兵切换主从的时间+客户端感知新主库时间 b：主库下线无感知，需要客户端与哨兵配合改造： 1：哨兵主动通知：哨兵需要将最新的主库地址写入自己的pubsub中，客户端需要订阅这个pubsub，当这个pubsub有数据时，客户端就能感知到 2：客户端主动获取：客户端不将主从库写死，而是从哨兵集群中获取，从而始终获取最新的主从地址 c：集群分片模式的Redis集群，可以不使用哨兵机制（我们项目组就是这样的）
    展开
    共 7 条评论
    131
  • 悟空聊架构
    2021-05-08
    这篇当中提到了很多分布式的理论，但没有细讲，我这里可以再补充下分布式理论相关的内容。希望对大家有所帮助： 现在很多开发同学对分布式的组件怎么使用都有一定经验，也知道 `CAP` 理论和 `BASE` 理论的大致含义。但认真去看分布式算法的真的很少，原因有三： - 担心算法过于复杂，所以花的时间很少。 - 网上的资料能用大白话将分布式算法讲清楚的比较少。 - 学习分布式算法没有一条清晰的路线。 学习分布式协议和算法的路线可以是先学习四大基础理论，作为地基。然后再学习分布式协议和算法。就像是在地基上建房子，地基打好了，才能建更稳固的高楼大厦。 而分布式理论主要有四大块： 四大基础理论 - 拜占庭将军问题 - CAP 理论 - ACID 理论 - BASE 理论 分布式协议和算法主要有八种： 八大分布式协议和算法 - Paxos 算法 - Raft 算法 - 一致性 Hash 算法 - Gossip 协议算法 - Quorum NWR 算法 - FBFT 算法 - POW 算法 - ZAB 协议 如何高效地学习和掌握？ 开发分布式系统最关键的就是根据场景特点，选择合适的算法，在一致性和可用性之间妥协折中，而如何做好折中方案，依赖于是否真正理解了各算法的特点。 讲真，如果认真学习这些理论和算法，并清楚了每个算法的特点，适合怎样的场景，当开发分布式系统时，做到知己知彼，才能旗开得胜，实际场景中的问题也能分析清楚并解决掉。 那么这些算法有哪些特点和适用场景，该从哪些方面考量？ 分布式算法的四大维度 四大维度：拜占庭容错、一致性、性能、可用性。 这里我做了一个分布式算法四大维度的表格，大家可以对比下： ![分布式算法的对比](http://cdn.jayh.club/blog/20210317/1plCsNXd82rh.png?imageslim) 拜占庭容错 拜占庭容错就是《拜占庭将军问题》中提出的一个模型，该模型描述了一个完全不可信的场景。不可信体现在： - 故障行为。比如节点故障了。 - 恶意行为。比如恶意节点冒充正常节点，发出错误指令。 拜占庭容错的另外一面就是`非拜占庭容错`，又叫故障容错，解决了分布式系统存在故障，但是不存在恶意节点共识的问题，譬如节点所在服务器硬件故障、节点的服务进程崩溃等。 非拜占庭容错算法 在可信的环境，只需要具有故障容错能力，譬如 2PC、TCC、Paxos算法、Raft 算法、Gossip 协议、Ouorum NWR 算法、ZAB 协议。 #### 拜占庭容错算法 而在不可信的环境，需要具有拜占庭容错能力，报错 POW 算法、FBFT 算法。 一致性 一致性分为三种： - 强一致性：保证写操作完成后，任何后续访问都能读到更新后的值。 - 弱一致性：写操作完成后，系统不能保证后续的访问都能读到更新后的值。 - 最终一致性：保证如果对某个对象没有新的写操作，最终所有后续访问都能读到相同的最近更新的值。 在数据库操作层面，我们多使用二阶段提交协议（2PC）保证强一致性。在分布式系统中，多使用 Raft 算法来保证强一致性。如果考虑可用性，则使用 Gossip 协议实现最终一致性，配合 Quorum NWR 算法的三个参数来调节容错能力。而 zookeeper 基于读性能的考虑，通过 ZAB 协议提供最终一致性。 可用性 可用性表示能得到响应数据，但不保证数据最新，强调服务可用。前提条件：访问的是非故障节点。 可用性最强的就是 Gossip 协议了，即时只有一个节点，集群可以提供服务。然后是 Paxos/Raft/ZAB/Quorum NWR/FBFT/POW 算法，能够容忍部分节点故障。 而 2PC、TCC 要求所有节点都正常运行，系统才能正常工作，可用性最低。 性能 性能和可用性联系非常紧密，可用性越高，性能越强。 上面可用性的排序同样适用于性能维度。Gossip 协议可用于 AP 型分布式系统，水平扩展能力强，读写性能最强。 Paxos/Raft/ZAB/Quorum NWR/FBFT/POW 算法都是领导者模型，写性能依赖领导者，读性能依赖一致性的实现。性能处于中等位置。 而 2PC、TCC 实现事务时，需要预留和锁定资源，性能较差。
    展开
    共 11 条评论
    89
  • 吕
    2020-08-19
    关于第二步，根据master_repl_offset和slave_repl_offset来比较，但此时master已经挂掉了，哨兵如何知道master_repl_offset的，难道哨兵也会存一份主的master_repl_offset？根据之前的学习，salve是不存储master_repl_offset的

    作者回复: 文章中为了便于理解，我提到要找的从库，“它的slave_repl_offset需要最接近master_repl_offset”，这种情况下，表明这个从库的复制进度是最快的。 因为不同从库的slave_repl_offset是可以比较的，所以在实际的选主代码中，哨兵在这一步，是通过比较不同从库的slave_repl_offset，找出最大slave_repl_offset的从库。

    共 3 条评论
    47
  • Oracleblog
    2020-08-19
    主从切换选出新的主后，新的从库同步是需要做一次全量同步吗？

    作者回复: 在Redis 4.0前，主从切换后，从库需要和主库做全量同步。但是，在Redis 4.0后，Redis做了优化，从库可以只和新主库做增量同步就行。可以去了解下psync2 ：）

    共 4 条评论
    18
  • yyl
    2020-08-21
    解答： 1.1 绝大部分的读请求，可以响应。由于主库实例挂掉，肯定有小部分数据未被同步至从实例，而这部分数据的读请求是失败的。 1.2 由于主从机制实现了读写分离，主实例挂掉，无法响应写请求。 2. 暂时没想到，看了课代表的解答，蛮详细的
    展开

    作者回复: 1.1 的答案中，如果这小部分数据是新写数据，且未同步的话，发往从库的读请求是会失败的。但如果是更新的数据，且未同步的话，那么从库的读请求会返回旧值。

    共 2 条评论
    12
  • 徐鹏
    2020-08-19
    有两个问题想请教哈 1.每一个哨兵实例都有整个redis集群的信息，会和每一个redis实例通信吗？ 2.在选主过程中，比较从库的salve_repl_offset，是把每个从库salve_repl_offset相互比较还是和master_repl_offset比较？原来的主库不是已经挂了，master_repl_offset 是如何获取到的呢？

    作者回复: 回答一下 1. 每个哨兵实例都会和主库、从库通信的，所以能获得从库的信息。 2. 在哨兵选主代码层面，是通过比较不同从库的salve_repl_offset大小来选择的，也就是选择salve_repl_offset最大的那个从库。

    9
  • ym
    2021-03-15
    你好，老师，我有一个疑问，就是主库挂了之后，通过筛选机制选择了一个从库作为新的主库，但是不能保证这个新的主库（旧从库的slave_repl_offset）和之前的主库（旧主库的master_repl_offset）是相同的，有可能是slave_repl_offset < master_repl_offset，那个即使选择了新的主库，那么数据也是丢失了一部分的，这个问题怎么解决呢。
    共 8 条评论
    7
  • Dovelol
    2020-08-22
    老师好，想问下，redis哨兵机制中，每个哨兵就是通过发布消息互相感知的吗？没有在启动时就指定对应哨兵集群的所有ip。

    作者回复: Redis哨兵集群中，哨兵配置文件中只用配置主节点的IP、端口号。每个哨兵会和主节点连接，并把自己的连接信息发布到主节点的__sentinel__:hello频道上，同时，每个哨兵会订阅这个频道获取其他哨兵的连接地址，这样，哨兵通过主节点上的__sentinel__:hello频道就相互感知了。 文章也有提到，可以回顾下 :)

    共 2 条评论
    6
  • Darren
    2020-08-19
    肯定会中断的，但是这么让客户端无感知，说说可能不成熟的想法，请老师和大家指点： 1、如果是读请求，可以直接读取从库，客户端无影响； 2、如果是写请求，可以先把命令缓存到哨兵中（比如说哨兵内部维护一个队列等），等选主成功后，在新的主库进行执行即可。

    作者回复: 和你探讨下，你有没有考虑过，如果把写命令缓存到哨兵中，那是需要客户端的命令发送，从发给主库切换到发给哨兵么？另外，哨兵实例一般有多个，你的方案中，写命令缓存到哪个哨兵实例呢？

    共 11 条评论
    6
  • Master
    2020-12-13
    在优先级和复制进度都相同的情况下，ID 号最小的从库得分最高，会被选为新主库。这种原则是因为啥啊？id号小，为啥得分高啊

    作者回复: 在分布式系统中，根据节点ID进行选择时，一般就会选择ID号最小的节点，属于较为常见的默认做法。

    共 4 条评论
    4
  • 一步
    2020-08-21
    Redis 的实例ID是根据什么进行生成的？

    作者回复: Redis server启动时，会生成一个40字节长的随机字符串作为runID，具体算法用的是SHA-1算法。

    5
  • 小袁
    2020-08-23
    老师，如果是主库挂了，从库被提升为主库，这我能够理解。但是你在前面某一篇文章中提到，主从同步最好是通过主从从的方式进行级联，这种拓扑结构下，如果机器或者redis出现问题，整个系统会变成怎样呢？这有点烧脑了
    共 1 条评论
    3
  • Gopher
    2021-01-03
    读了后面的一篇文章想到在主从切换过程中如何让客户端无感知的解决方案： 业务系统也可以订阅对应的状态事件，每次进行写请求的时候，判断下状态，如果是处于切换状态可以，先写入到队列中。

    作者回复: 是的，可以让Redis客户端做相应的配合（需要对客户端做相应的开发），如果后端集群正在切换，客户端需要缓存下请求，避免直接发到后端集群。等切换完成，再把请求发到集群处理。

    共 2 条评论
    3
  • 意琦行
    2020-10-04
    这个判断原则就是：少数服从多数。 按道理说主库下线了应该所有哨兵的结果都是下线才对呀，如果有一个哨兵检测为上线那主库肯定是上线状态吧，为什么这种情况也需要重新选举呢。
    共 2 条评论
    2
  • 不负青春不负己🤘
    2020-08-19
    1 sentinel 集群 一般建议是3个节点 还是，多个节点， 怎么保证 sentinal 集群的高可用， 以及集群节点过多 ，会不会 导致选举时间过长， sentinel 选举 类似于 变体raft 协议 2 能不能创建一个微信 或者QQ 群， 一些简单的问题 可以互相交流，
    共 1 条评论
    2
  • 登山看云海
    2020-10-23
    能否讲下客户端在这个过程中如何做到无感知
    共 1 条评论
    1
  • Geek_c37e49
    2020-08-19
    主从切换的时候应该是没办法响应写请求的，不过可以把请求缓存记录下来 读请求应该是可以服务的吧
    1
  • 蔡欧
    2022-08-21 来自广东
    如何解决Redis主库挂了，Redis依赖可以提供服务：使用哨兵，监控、切换和通知整个Redis集群 如何避免哨兵由于主观下线导致Redis切换：使用哨兵集群，采用少数服从多数的方式 哨兵选举的依据：优先级+进度+序号+网络状态监控(down-after-milliseconds时间内断链的次数) Redis客户端如何自动切换：通过配置客户端哨兵集群配置，可以采用主读或者pubsub方式得到最新的Redis集群地址 如何百分百避免在Redis切换过程数据丢失：Redis切换导致写不可用范围为切换时间+客户端感知新Redis主的时间，这段时间导致Redis写不可用，1 把down-after-milliseconds配置改小，对Redis不可用更加敏感，但是可能导致误判 2 客户端改造成有降级措施，把不可用请求先写入消息队列中，后续等Redis可用后再进行重放
    展开
    1