一、基本概念
Redis Sentinel 是 Redis 的高可用性解决方案之一，用于监控和管理 Redis 主从复制环境。它可以检测节点的状态，并在主节点下线时自动进行故障转移。
主要特性：
监控： Sentinel 能够监控 Redis 主从节点的健康状况，包括网络连接、内存使用、主从同步状态等。
自动故障检测： Sentinel 能够检测到主节点的故障，并在必要时触发自动故障转移。
故障转移：在主节点故障时，Sentinel 会协调选举一个新的主节点，并将其他节点重新配置为新主节点的从节点。
配置提供：Sentinel 可以通过发布/订阅机制向应用程序提供有关节点状态的实时信息，使应用程序能够动态调整连接。
工作原理：
Sentinel 集群部署： Sentinel 通常以多个节点的形式部署，它们之间通过发布/订阅机制保持通信。
节点监控： Sentinel 定期向 Redis 节点发送心跳检测，并根据检测结果维护节点状态。
故障检测： 当 Sentinel 检测到主节点故障时，它会触发一次故障转移流程。通过 Sentinel 集群的协作，它们会选举一个新的主节点，并将其他节点配置为新主节点的从节点。
故障转移： Sentinel 通知 Redis 客户端新的主节点地址，并在 Redis 集群中更新节点配置。
配置提供： Sentinel 可以通过发布/订阅机制向应用程序提供关于节点状态变化的实时信息，使应用程序能够及时调整连接。
二、整体部署流程
1、部署多个 Sentinel 节点。
2、在 Redis 主从节点中配置 Sentinel。
在使用 Sentinel 时，需要在 Redis 主从节点的配置中添加 Sentinel 的相关信息，以便它们能够相互感知和通信。
通过 Sentinel，Redis 能够实现高可用性和故障自动转移，确保系统在节点发生故障时能够保持可用状态。
三、配置哨兵 Sentinel 节点（俩台服务器都配置）
哨兵节点1:192.168.1.137
redis实例：6379（默认master）
哨兵节点2：192.168.1.138
redis实例（6379/6380/6381/6382/6383）
1、复制redis解压目录下的配置文件
cp sentinel.conf /usr/local/redis7/bin
2、编辑配置文件
vim sentinel.conf
port 26379 #端口daemonize yes # 开启后台运行pidfile "/var/run/redis-sentinel-26379.pid" # 进程iddir "/usr/local/redis7/sentinel" # 工作空间目录# 配置哨兵，mymaster是昵称可以自定义#master内网IP master端口#最后一个2代表至少有两个哨兵确认master宕机时才能认定该master失效；#其中的一个哨兵就可以去开始执行故障转移sentinel monitor mymaster 192.168.10.125 6379 2# 密码sentinel auth-pass mymaster 123456# master被sentinel认定为失效的间隔时间，单位：毫秒，即30秒sentinel down-after-milliseconds mymaster 30000# 剩余的slaves重新和新的master做同步的并行个数sentinel parallel-syncs mymaster 1# 主备切换的超时时间，哨兵要去做故障转移，这个时候哨兵也是一个进程，如果他没有去执行，超过这个时间后，会由其他的哨兵来处理sentinel failover-timeout mymaster 180000
复制哨兵配置文件到另一台哨兵主机：
scp sentinel.conf root@192.168.1.137:/usr/local/redis7
2、启动哨兵
俩台主机都执行：
redis-sentinel sentinel.conf
四、哨兵模式测试
1、停掉192.168.1.137的6379实例master；
2、在192.168.1.138的redis实例测试，可以发现master已经实现故障转移：
redis-cli -h 127.0.0.1 -p 6381
127.0.0.1:6381> info Replication# Replicationrole:masterconnected_slaves:4slave0:ip=192.168.1.138,port=6382,state=online,offset=360937,lag=0slave1:ip=192.168.1.138,port=6379,state=online,offset=361104,lag=0slave2:ip=192.168.1.138,port=6380,state=online,offset=361104,lag=0slave3:ip=192.168.1.138,port=6383,state=online,offset=361104,lag=0master_failover_state:no-failovermaster_replid:c9e93599ca489d8bc1ae5e203d72b7e817811583master_replid2:f0fa1c465663eb715e7b1b66d729dd3fa4aa45f2master_repl_offset:361104second_repl_offset:296758repl_backlog_active:1repl_backlog_size:1048576repl_backlog_first_byte_offset:38300repl_backlog_histlen:322805###################################################解释：role:master表示这是一个主节点。connected_slaves:4主节点连接的从节点数量，这里是4个从节点。slave0:ip=192.168.1.138,port=6382,state=online,offset=360937,lag=0从节点0的信息，包括 IP 地址、端口号、状态（online 表示在线）、复制偏移量、滞后（lag）等信息。slave1:ip=192.168.1.138,port=6379,state=online,offset=361104,lag=0从节点1的信息，同样包括 IP 地址、端口号、状态、复制偏移量、滞后等信息。slave2:ip=192.168.1.138,port=6380,state=online,offset=361104,lag=0从节点2的信息。slave3:ip=192.168.1.138,port=6383,state=online,offset=361104,lag=0从节点3的信息。master_failover_state:no-failover主节点故障转移的状态，"no-failover" 表示没有进行故障转移。master_replid:c9e93599ca489d8bc1ae5e203d72b7e817811583主节点的复制ID（Replication ID）。master_replid2:f0fa1c465663eb715e7b1b66d729dd3fa4aa45f2主节点的第二个复制ID，用于故障转移时的判断。master_repl_offset:361104主节点的当前复制偏移量。second_repl_offset:296758从节点复制偏移量的第二个值，用于检测是否需要重新同步数据。repl_backlog_active:1是否激活了复制积压日志（Replication Backlog），"1" 表示激活。repl_backlog_size:1048576复制积压日志的大小，这里是1MB。repl_backlog_first_byte_offset:38300复制积压日志的起始偏移量。repl_backlog_histlen:322805复制积压日志的历史长度。
可以通过调整sentinel down-after-milliseconds和sentinelfailover-timeout参数控制故障切换的时间长短。
四、哨兵模式小结
本次采用俩个哨兵实现对6个redis实例的监测，并实现自动故障切换。
1、 当默认的master宕掉之后，重新恢复，会不会替换选举的master?
当默认的 Redis 主节点宕掉之后，如果使用了 Redis Sentinel 进行主从切换（故障转移），Sentinel 会选择一个健康的从节点晋升为新的主节点，而不是默认的主节点恢复。
2、关于redis集群中的一主二从三哨兵模式？
"一主二从三哨兵"是一种常见的 Redis 高可用配置，但是否是最佳实践取决于具体的应用场景和需求。这种配置有一些优点，如提供了基本的高可用性、故障转移功能和读取负载均衡。"一主二从三哨兵"是一个简单而有效的配置，适用于许多场景。
一主（1M）：
一个 Redis 主节点，负责处理读写操作，是整个集群的核心节点。
b.两从（2S）：
两个 Redis 从节点，用于复制主节点的数据。这些从节点可以接收读请求，提供读取负载均衡，并在主节点发生故障时可以晋升为新的主节点。
c.三哨兵（3H）：
三个 Redis Sentinel，用于监控主节点和从节点的健康状态，以及执行自动故障转移。哨兵负责检测主节点的状态，当主节点宕掉时，哨兵会选出一个健康的从节点晋升为新的主节点。哨兵还负责维护集群配置、发现新的节点，并在需要时触发手动故障转移。
特点：提供了高可用性和容错性。当主节点发生故障时，哨兵可以协调将一个健康的从节点晋升为新的主节点，从而实现故障转移，保证整个系统的可用性。
3、集群选择的考虑因素？
读写比例：
如果应用有较高的读取流量，可能需要更多的从节点来分担读取负载。在这种情况下，可以增加从节点的数量，以提高读取性能。
b.故障转移速度：
如果对故障转移的速度要求较高，可以考虑增加哨兵的数量，以便更快地检测主节点的故障并进行自动故障转移。
c.数据冗余：
考虑数据冗余的需求，以确保在主节点发生故障时，从节点上有足够的数据副本可供使用。增加从节点的数量可以提高数据冗余性。
d.容量规模：
随着系统容量的增加，可能需要调整节点的数量和配置，以满足性能和可用性的需求。
e.数据分片：
如果数据量巨大，可能需要考虑使用 Redis Cluster 进行分片，以便水平扩展。Redis Cluster 提供了更复杂的分布式架构，适用于大规模部署。
