【Redis 进阶】哨兵模式
思维导图：
一、哨兵模式概述
（一）传统主从复制模式的局限性
在传统的Redis主从复制架构中，若主节点发生故障，运维人员需手动执行故障转移操作，将一个从节点提升为新主节点，并逐一通知所有客户端更新连接信息。然而，这种手动切换方式不仅效率低下，而且在高并发场景下容易引发数据不一致性问题。此外，随着企业规模的扩大，客户端数量增多，手动切换带来的运维成本和风险也显著增加。因此，Redis引入了哨兵（Sentinel）模式以提升系统的高可用性。
（二）哨兵模式的引入及优势
Redis哨兵模式通过引入哨兵节点，实现了对主从节点的自动监控和故障转移，极大地简化了运维工作并提高了系统的可用性。哨兵模式能够在主节点发生故障时自动选举新的主节点，并通知客户端更新连接信息，从而确保系统的持续稳定运行。此外，哨兵模式还支持配置动态调整和监控告警功能，为运维人员提供了更加便捷和高效的管理手段。
二、哨兵模式基本概念
（一）主节点与从节点
- 主节点：负责处理所有写操作，并将数据同步到从节点。
- 从节点：负责处理读操作，并从主节点同步数据。
（二）哨兵节点及其集合
- 哨兵节点：独立的进程，用于监控Redis主从节点的状态。
- 哨兵节点集合：由多个哨兵节点组成，防止单点故障。
（三）Redis哨兵整体架构
Redis哨兵模式包括主节点、从节点和哨兵节点集合。哨兵节点通过TCP长连接定期发送心跳包来监控主从节点的状态，并在检测到故障时自动执行故障转移操作。
三、哨兵模式工作机制
（一）监控机制
哨兵节点通过TCP长连接定期发送心跳包来监控主从节点的状态。如果某个哨兵节点在一定时间内未收到主节点的心跳响应，则会将其标记为主观下线。当多个哨兵节点同时标记主节点为主观下线时，会触发客观下线判定。
（二）自动故障转移流程
- 主观下线判定：单个哨兵节点单方面认为主节点挂了，但可能也存在网络波动的关系。
- 客观下线判定：多个哨兵节点共同确认主节点挂了，防止误判。
- Leader选举：多个哨兵节点选出Leader，负责执行故障转移操作。
- 新主节点选举：从从节点中选出一个优先级最高、数据同步最多的节点作为新的主节点。
- 配置更新：哨兵节点通知其他从节点和新主节点更新配置。
（三）客户端通知机制
哨兵节点会自动通知客户端程序新的主节点是谁，后续客户端的写入操作就会针对新的主节点进行了。这种机制确保了客户端能够及时感知主节点的变化并进行相应的调整。
四、哨兵节点集合的优势
（一）防止单点故障
哨兵节点集合由多个哨兵实例组成，这种冗余设计旨在防止单点故障。当某个哨兵节点因硬件故障或网络问题不可用时，其余哨兵节点仍能继续履行监控和管理职责，确保系统的稳定运行。
（二）降低误判概率
通过多个哨兵节点的共同确认，可以有效降低误判概率。传输过程中可能会出现丢包或网络抖动，单个哨兵节点的判断可能存在误差，但多个哨兵节点的共同确认可以提高判断的准确性。
五、Docker部署环境搭建
（一）Docker简介及优势
Docker是一种轻量级的容器化技术，通过操作系统级别的虚拟化实现资源的隔离和限制。与传统的虚拟机相比，Docker容器共享宿主操作系统内核，启动速度快，资源占用少，非常适合用于部署和扩展分布式应用。
（二）Docker准备工作
- 安装Docker和Docker Compose。
- 停止运行的Redis进程，防止冲突。
- 使用Docker获取Redis镜像。
（三）容器编排步骤详解
- 创建Redis主从容器：
- 使用Docker Compose定义一个YAML文件，指定主节点和从节点的配置参数。
- 启动容器并验证主从复制是否正常工作。
- 创建哨兵容器：
- 定义另一个YAML文件，指定哨兵节点的配置参数。
- 启动哨兵容器并验证其监控和管理功能。
六、哨兵重新选取主节点过程剖析
（一）主观下线与客观下线判定
- 主观下线：单个哨兵节点单方面认为主节点挂了，但可能也存在网络波动的关系。
- 客观下线：多个哨兵节点共同确认主节点挂了，防止误判。
（二）Leader选举机制
- 第一个发现客观下线的哨兵节点会投给自己一票，并向其他哨兵节点拉票。
- 其他哨兵节点接收到请求后，会投给它。如果出现多个同时拉票，那么谁快投谁，当其中一个哨兵节点的票数超过半数的时候，选举就完成了。
（三）新主节点选择策略
- 优先级：每个从节点在配置文件中，都会有优先级的设置，优先级高的胜出。
- offset：如果不能区分，就看谁同步数据的多，多的胜出。
- run id：每个Redis启动时随机生成一串数字，谁越小，就挑选谁。
七、注意事项及最佳实践
（一）哨兵节点数量规划建议
哨兵节点的数量应根据实际业务需求和系统规模进行合理规划。通常建议部署奇数个哨兵节点，以便在发生故障时能够通过多数投票机制选出新的主节点。
（二）数据一致性与存储容量考量
哨兵+主从复制解决的是"可用性"问题，并不能解决在极端情况下的数据丢失问题。此外，哨兵+主从复制并不能提高数据的存储容量，数据的持久化和备份仍需通过其他手段实现。
（三）系统可用性保障措施
- 定期备份数据，确保在发生故障时能够快速恢复。
- 监控系统性能指标，及时发现和处理潜在问题。
- 进行容灾演练，验证系统的可靠性和稳定性。