Redis Sentinel 说明-CSDN博客

本文介绍Redis Sentinel配置文件详解及如何利用Sentinel实现高可用性(HA)。Sentinel能够监控、通知并自动故障转移Redis实例。通过配置文件中的关键参数，如端口、日志文件位置、监控主节点等，可以实现对Redis集群的有效管理。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

sentinel.conf 配置文件说明:

daemonize yes – 以后台进程模式运行
port 26379 – 哨兵的端口号，该端口号默认为26379，不得与任何redis node的端口号重复
logfile “/var/log/redis/sentinel.log“ – log文件所在地
sentinel monitor master1 192.168.56.101 7001 1 – （第一次配置时）哨兵对哪个master进行监测，此处的master1为一“别名”可以任意如sentinel-26379，然后哨兵会通过这个别名后的IP知道整个该master内的slave关系。因此你不用在此配置slave是什么而由哨兵自己去维护这个“链表”。
sentinel monitor master1 192.168.56.101 7001 1 – 这边有一个“1”，这个“1”代表当新master产生时，同时进行“slaveof”到新master并进行同步复制的slave个数。在salve执行salveof与同步时，将会终止客户端请求。此值较大，意味着“集群”终止客户端请求的时间总和和较大。此值较小,意味着“集群”在故障转移期间，多个salve向客户端提供服务时仍然使用旧数据。我们这边只想让一个slave来做此时的响应以取得较好的客户端体验。
sentinel down-after-milliseconds master1 1000 – 如果master在多少秒内无反应哨兵会开始进行master-slave间的切换，使用“选举”机制
sentinel failover-timeout master1 5000 – 如果在多少秒内没有把宕掉的那台master恢复，那哨兵认为这是一次真正的宕机，而排除该宕掉的master作为节点选取时可用的node然后等待一定的设定值的毫秒数后再来探测该节点是否恢复，如果恢复就把它作为一台slave加入哨兵监测节点群并在下一次切换时为他分配一个“选取号”。

按照master->slave->sentinel的顺序来启动redis的sentinel HA群

使用Redis Sentinel来做HA

sentinel是一个管理redis实例的工具，它可以实现对redis的监控、通知、自动故障转移。sentinel不断的检测redis实例是否可以正常工作，通过API向其他程序报告redis的状态，如果redis master不能工作，则会自动启动故障转移进程，将其中的一个slave提升为master，其他的slave重新设置新的master服务器。
sentinel是一个分布式系统，在源码包的src目录下会有redis-sentinel命令，你甚至还可以在多台机器上部署sentinel进程，共同监控redis实例。

一个Master可以有多个Slave；
Redis使用异步复制。从2.8开始，Slave会周期性（每秒一次）发起一个Ack确认复制流（replication stream）被处理进度；
不仅主服务器可以有从服务器，从服务器也可以有自己的从服务器，多个从服务器之间可以构成一个图状结构；
复制在Master端是非阻塞模式的，这意味着即便是多个Slave执行首次同步时，Master依然可以提供查询服务；
复制在Slave端也是非阻塞模式的：如果你在redis.conf做了设置，Slave在执行首次同步的时候仍可以使用旧数据集提供查询；你也可以配置为当Master与Slave失去联系时，让Slave返回客户端一个错误提示；
当Slave要删掉旧的数据集，并重新加载新版数据时，Slave会阻塞连接请求（一般发生在与Master断开重连后的恢复阶段）；
复制功能可以单纯地用于数据冗余（data redundancy），也可以通过让多个从服务器处理只读命令请求来提升扩展性（scalability）：比如说，繁重的 SORT 命令可以交给附属节点去运行。
可以通过修改Master端的redis.config来避免在Master端执行持久化操作（Save），由Slave端来执行持久化。