共计 2350 个字符，预计需要花费 6 分钟才能阅读完成。
文章原创于公众号：程序猿周先森。本平台不定时更新，喜欢我的文章，欢迎关注我的微信公众号。
Redis 主从复制实际上就是将主 Redis 节点的数据，复制到其他从 Redis 节点去进行存储，当主节点因为出现异常宕机后，如何将从节点切换成主节点继续提供服务呢？Redis 主从切换主要分为以下两种方式：手动切换以及哨兵模式。今天我们一起来看看 Redis 在出现故障是如何进行主从切换继续提供服务的。
题外话
首先开始讲主从切换前，先补充昨天遗漏的一个知识点：我们启动主节点和启动不同的从节点启动间隔时间不能太短，因为主节点需要将数据同步到不同的从节点会耗费大量资源。
主从手动切换
当主节点出现宕机时，这时候最简单的方式可以使用主从手动切换的方式，手动的将一台从节点切换成主节点，所以我们需要人工干预手动设置，最关键在手动切换的过程中会造成 Redis 服务不可用。所以说主从手动切换的方案不是一个合适的主从切换方案，但是我们也来看下主从手动切换是如何实现的。
当主节点出现宕机，这时候我们需要手动将从节点设置成主节点。命令：
- redis-cli -h < 从节点 ip> -p < 从节点端口号 > slaveof no one
通过上面命令，可以将该从节点临时设置为主节点。当 Redis 重启时，主从切换设置将会失效。然后按照上一篇主从复制的配置将其他从节点的主配置改成现在的主节点。当原来的主节点从宕机中进行恢复，则将临时主节点的数据进行保存，将 AOF 文件与 RDB 文件拷贝替换原主节点下的 AOF 文件与 RDB 文件。然后重启原主节点 Redis 服务以及临时主节点 Redis 服务，恢复原先的主从关系。但是毕竟主从手动切换方案是存在问题的不是很适用，所以一般主从切换会采用哨兵模式。
哨兵模式
在 Redis 中，哨兵是一个独立的进程独立运行。由一个或多个 Sentinel 实例组成，可以监视多个主节点以及主节点下的从节点。当监视的主节点因为故障宕机，Sentinel 实例可以自动的将主节点下的其中一个从节点升级为新的主节点，由这个新的主节点继续处理写请求。实际上可以把哨兵理解为一个运行在特殊模式下的 Redis 服务器，在哨兵服务器初始化完成后，哨兵服务器会保存所有的哨兵功能有关的状态记录。哨兵实际上一共有三个任务：监控 (Monitoring)、提醒 (Notification)、自动故障迁移 (Automatic failover)。
- 监控：Sentinel 实例会不断检测主从节点是否正常运行。
- 提醒：当某个节点出现异常宕机时，Sentinel 实例会向管理员或者其他应用发送提醒。
- 自动故障迁移：当主节点宕机时，Sentinel 实例会将该主节点下的其中一个从节点升级为新的主节点，并且原先其他从节点重新发起 socket 请求成为新的主节点的从节点。
- 配置中心：向客户端返回新主节点的地址，就可以正常上使用新的主节点来处理请求了。
通过上面的简单介绍，其实可以发现哨兵模式实际上就可以将主从手动切换给变成自动切换，哨兵会定时通过发送命令，让监视的主从节点返回运行状态，当哨兵监视到主节点宕机，则会自动选择该主节点下的一个从节点，切换成新的主节点。然后通知其他从节点修改成新的主节点的从节点，这样就可以成功进行主从切换开始处理新请求。但是如果我们只使用一个哨兵，也就是只开启一个 Sentinel 实例进行监视，容易出现问题，一般情况下会开启多个 Sentinel 实例进行监控，一般情况下至少需要 3 个 Sentinel 实例。
节点的两种宕机状态
哨兵检测到主节点宕机一般有两种状态：sdown(主观宕机) 和 odown(客观宕机)。如果只有一个哨兵认为这个主节点宕机了，则成为主观宕机。如果达到一定数量的节点认为该主节点宕机，则成为客观宕机。
哨兵如何判断主观宕机与客观宕机
当某一个哨兵 ping 该主节点，在超过了 is-master-down-after-milliseconds 配置的超时毫秒数没有信息返回，则该哨兵认为这个主节点宕机，这个时候成为主观宕机，也就是 sdown。当这个哨兵在指定时间内收到了指定数量的哨兵同样认为该主节点宕机，则这个时候就是客观宕机，也就是 odown。当一定时间内没有足够数量的哨兵认同主节点宕机，则主节点的客观宕机状态将会移除。当认为主观宕机的哨兵再次 ping 并得到有效回复时，则主节点的主观宕机也会被移除。
为什么至少需要 3 个 Sentinel 实例？
刚才说过了，当指定时间内指定哨兵数量都认为主节点宕机则称为客观宕机。那指定数量是多少呢？这个指定数量实际上等于哨兵数量 / 2 + 1. 也就是说如果哨兵数量等于 2，出现一个哨兵宕机的情况，在需要主从切换的时候因为无法达到认为主节点宕机的哨兵数量为 2，所以在主节点出现宕机时无法进行主从切换。所以说部署哨兵至少需要 3 个 Sentinel 实例来保证健壮性。
哨兵模式引发数据丢失问题
哨兵模式 + Redis 主从复制这种部署结构，无法保证数据不会出现丢失。哨兵模式下数据丢失主要有两种情况：
- 因为主从复制是异步操作，可能主从复制还没成功，主节点宕机了。这时候还没成功复制的数据就会丢失了。
- 如果主节点无法与其他从节点连接，但是实际上还在运行。这时候哨兵会将一个从节点切换成新的主节点，但是在这个过程中实际上主节点还在运行，所以继续向这个主节点写入的数据会被丢失。
解决数据丢失方案
使用命令：
- min-slaves-to-write 1
- min-slaves-max-lag 10
使用这组命令可以设置至少有一个从节点数据复制延迟不能超过 10S，也就是说如果一个直接点下所有从节点数据复制延迟都超过 10S，则停止主节点继续接收处理新的请求。这样可以保证数据丢失最多只会丢失 10S 内的数据。
欢迎关注公众号：程序猿周先森。
本文由博客一文多发平台 OpenWrite 发布！
