共计 3643 个字符，预计需要花费 10 分钟才能阅读完成。
前言
只有光头才能变强
好的，今天我们要上【铂金二】了，如果还没有上铂金的，赶紧先去蹭蹭经验再回来(不然不带你上分了)：
从零单排学 Redis【青铜】
从零单排学 Redis【白银】
从零单排学 Redis【黄金】
从零单排学 Redis【铂金一】
在上篇中抛出了一个问题：
抛个问题：如果从服务器挂了，没关系，我们一般会有多个从服务器，其他的请求可以交由没有挂的从服务器继续处理。如果主服务器挂了，怎么办？因为我们的写请求由主服务器处理，只有一台主服务器，那就无法处理写请求了？
Redis 提供了哨兵 (Sentinal) 机制供我们解决上面的情况。如果主服务器挂了，我们可以将从服务器升级为主服务器，等到旧的主服务器 (挂掉的那个) 重连上来，会将它 (挂掉的主服务器) 变成从服务器。
这个过程叫做主备切换(故障转移)
在正常的情况下，主从加哨兵 (Sentinal) 机制是这样子的：
主服务器挂了，主从复制操作就中止了，并且哨兵系统是可以察觉出主服务挂了。：
Redis 提供哨兵机制可以将选举一台从服务器变成主服务器
然后旧的主服务器如果重连了，会变成从服务器：
这篇文章主要讲讲 Redis 的哨兵 (Sentinal) 机制的一些细节。希望看完对大家有所帮助~
一、哨兵 (Sentinal) 机制
High Availability: Redis Sentinel is the official high availability solution for Redis.
哨兵 (Sentinal) 机制主要用于实现 Redis 的高可用性，主要的功能如下：
Monitoring. Sentinel constantly checks if your master and slave instances are working as expected.
Sentinel 不停地监控 Redis 主从服务器是否正常工作
Notification. Sentinel can notify the system administrator, another computer programs, via an API, that something is wrong with one of the monitored Redis instances.
如果某个 Redis 实例有故障，那么哨兵负责发送消息通知管理员
Automatic failover. If a master is not working as expected, Sentinel can start a failover process where a slave is promoted to master, the other additional slaves are reconfigured to use the new master, and the applications using the Redis server informed about the new address to use when connecting.
如果主服务器挂掉了，会自动将从服务器提升为主服务器(包括配置都会修改)。
Configuration provider. Sentinel acts as a source of authority for clients service discovery: clients connect to Sentinels in order to ask for the address of the current Redis master responsible for a given service. If a failover occurs, Sentinels will report the new address.
Sentinel 可以作为配置中心，能够提供当前主服务器的信息。
下面来具体讲讲 Sentinel 是如何将从服务器提升为主服务器的。
tips:Sentinel 可以让我们的 Redis 实现高可用，Sentinel 作为这么一个组件，自身也必然是高可用的(不可能是单点的)
1.1 启动和初始化 Sentinel
首先我们要知道的是：Sentinel 本质上只是一个运行在特殊模式下的 Redis 服务器。因为 Sentinel 做的事情和 Redis 服务器是不一样的，所以它们的初始化是有所区别的(比如，Sentinel 在初始化的时候并不会载入 AOF/RDB 文件，因为 Sentinel 根本就不用数据库)。
然后，在启动的时候会将普通 Redis 服务器的代码替换成 Sentinel 专用代码。(所以 Sentinel 虽然作为 Redis 服务器，但是它不能执行 SET、DBSIZE 等等命令，因为命令表的代码被替换了)
接着，初始化 Sentinel 的状态，并根据给定的配置文件初始化 Sentinel 监视的主服务器列表。
最后，Sentinel 会创建两个连向主服务器的网络连接：
命令连接(发送和接收命令)
订阅连接(订阅主服务器的_sentinel_:hello 频道)
1.2 获取和更新信息
Sentinel 通过主服务器发送 INFO 命令来获得主服务器属下所有从服务器的地址信息，并为这些从服务器创建相应的实例结构。
当发现有新的从服务器出现时，除了创建对应的从服务器实例结构，Sentinel 还会创建命令连接和订阅连接。
在 Sentinel 运行的过程中，通过命令连接会以每两秒一次的频率向监视的主从服务器的_sentinel_:hello 频道发送命令(主要发送 Sentinel 本身的信息，监听主从服务器的信息)，并通过订阅连接接收_sentinel_:hello 频道的信息。
这样一来一回，我们就可以更新每个 Sentinel 实例结构的信息。
1.3 判断主服务器是否下线了
判断主服务器是否下线有两种情况：
主观下线
Sentinel 会以每秒一次的频率向与它创建命令连接的实例 (包括主从服务器和其他的 Sentinel) 发送 PING 命令，通过 PING 命令返回的信息判断实例是否在线
如果一个主服务器在 down-after-milliseconds 毫秒内连续向 Sentinel 发送无效回复，那么当前 Sentinel 就会主观认为该主服务器已经下线了。
客观下线
当 Sentinel 将一个主服务器判断为主观下线以后，为了确认该主服务器是否真的下线，它会向同样监视该主服务器的 Sentinel 询问，看它们是否也认为该主服务器是否下线。
如果足够多的 Sentinel 认为该主服务器是下线的，那么就判定该主服务为客观下线，并对主服务器执行故障转移操作。
在多少毫秒内无效回复才认定主服务器是主观下线的，以及有多少个 Sentinel 认为主服务器是下线才认定为客观下线。这都是可以配置的
1.4 选举领头 Sentinel 和故障转移
当一个主服务器认为为客观下线以后，监视这个下线的主服务器的各种 Sentinel 会进行协商，选举出一个领头的 Sentinel，领头的 Sentinel 会对下线的主服务器执行故障转移操作。
选举领头 Sentinel 的规则也比较多，总的来说就是先到先得(哪个快，就选哪个)
选举出领头的 Sentinel 之后，领头的 Sentinel 会对已下线的主服务器执行故障转移操作，包括三个步骤：
在已下线主服务器属下的从服务器中，挑选一个转换为主服务器
让已下线主服务器属下的所有从服务器改为复制新的主服务器
已下线的主服务器重新连接时，让他成为新的主服务器的从服务器
(这三步实际上就是文章开头的图片)
挑选某一个从服务器作为主服务器也是有策略的，大概如下：
（1）跟 master 断开连接的时长
（2）slave 优先级
（3）复制 offset
（4）run id
最后
这篇文章主要讲解了 Sentinel 的作用和工作的基本过程(我觉得已经基本 OK 了)，其中也涉及到了很多的细节，这里我就没有一一整理出来了。想要深入学习的同学最好自己看看书或者文档~~
tips: 目前为止的主从 + 哨兵架构可以说 Redis 是高可用的，但要清楚的是：Redis 还是会丢失数据的
丢失数据有两种情况：
异步复制导致的数据丢失
有部分数据还没复制到从服务器，主服务器就宕机了，此时这些部分数据就丢失了
脑裂导致的数据丢失
有时候主服务器脱离了正常网络，跟其他从服务器不能连接。此时哨兵可能就会认为主服务器下线了(然后开启选举，将某个从服务器切换成了主服务器)，但是实际上主服务器还运行着。这个时候，集群里就会有两个服务器(也就是所谓的脑裂)。
虽然某个从服务器被切换成了主服务器，但是可能客户端还没来得及切换到新的主服务器，客户端还继续写向旧主服务器写数据。旧的服务器重新连接时，会作为从服务器复制新的主服务器(这意味着旧数据丢失)。
可以通过以下两个配置尽量减少数据丢失的可能：
min-slaves-to-write 1
min-slaves-max-lag 10
从零单排学 Redis【铂金三】，敬请期待~
参考资料：
《Redis 设计与实现》
《Redis 实战》
如果你觉得我写得还不错，了解一下：
坚持原创的技术公众号：Java3y。回复 1 加入 Java 交流群
文章的目录导航(精美脑图 + 海量视频资源)：https://github.com/ZhongFuCheng3y/3y
