Redis高可用方案：sentinel（哨兵模式）和集群_redis高可用集群方案-优快云博客

本文链接：https://blog.youkuaiyun.com/2401_84004024/article/details/138336427

本文介绍了Redis的高可用方案，包括哨兵模式和集群搭建。哨兵模式中，通过哨兵节点监控、故障发现、领导者选举实现主从切换。在集群配置中，详细阐述了节点分配、数据分配以及主从模式，强调了集群至少需要奇数个节点以保证服务连续性。最后，提供了集群搭建的步骤，涉及多个实例的配置与连接。

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

接着其他Sentinel也陆续发现故障，这个时候其中一个Sentinel就会发起投票。一定数量的哨兵(在配置文件中指定)确认Master被标记为主观下线，此时将Master标记为客观下线。

3.sentinel的leader选举：

要想完成故障切换（将故障master剔除，并将一个slave提升为master）就必须先选举一个leader。最先发现故障的sentinel向其他哨兵发起请求成为leader，其他哨兵在没有同意别的哨兵的leader请求时，就会把票投给该sentinel。当半数以上的sentinel投票通过后就认定该sentinel为leader。接下来的故障切换有该leader完成。

4.master选举：

leader选好后将故障master剔除，从slave中挑选一个成为master。遵照的原则如下：

slave的优先级
slave从master那同步的数据量，那个slave多就优先。

5.新Master再通过发布订阅模式通知所有sentinel更新监控主机信息。

6.故障的主服务器修复后将成为从服务器继续工作。

故障发生

故障切换

Master重新上线后

哨兵模式配置

本实验在一台机器上完成，创建不同端口的redis实例。

1.创建redis实例

[root@redis ~]# nohup redis-server --port 6380 >> /data/redis/log/6380.log 2>&1 &

[root@redis ~]# nohup redis-server --port 6381 >> /data/redis/log/6381.log 2>&1 &

[root@redis ~]# nohup redis-server --port 6382 >> /data/redis/log/6382.log 2>&1 &

[root@redis ~]# ps -ef |grep redis

root 16421 16314 0 03:01 pts/1 00:00:00 redis-server *:6380

root 16427 16314 0 03:01 pts/1 00:00:00 redis-server *:6381

root 16431 16314 0 03:01 pts/1 00:00:00 redis-server *:6382

root 16436 16314 0 03:01 pts/1 00:00:00 grep --color=auto redis

2.连接数据库并设置主从复制

[root@redis ~]# redis-cli -p 6380

127.0.0.1:6380>

[root@redis ~]# redis-cli -p 6381

127.0.0.1:6381> SLAVEOF 127.0.0.1 6380 #将6380设置为master

[root@redis ~]# redis-cli -p 6382

127.0.0.1:6382> SLAVEOF 127.0.0.1 6380

3.搭建哨兵模式集群

创建sentinel配置文件

[root@redis conf]# cat sentinel1.conf

port 26300 #指定sentinel进程端口号

sentinel monitor redis1 127.0.0.1 6380 2 #Sentinel monitor

[root@redis conf]# cat sentinel2.conf

port 26301

sentinel monitor redis1 127.0.0.1 6380 2

name ：redis主服务名称，可以自行命名，但是在一个sentinel网络中，一个redis主服务只能有一个名称；
ip和port ：redis主服务的IP地址和端口号.
quorum ：表示要将这个主服务器判断为失效并下线至少需要2个sentinel同意
protected-mode ：关闭保护模式（默认情况下，redis node和sentinel的protected-mode都是yes，在搭建集群时，若想从远程连接redis集群，需要将redis node和sentinel的protected-mode修改为no，若只修改redis node，从远程连接sentinel后，依然是无法正常使用的，且sentinel的配置文件中没有protected-mode配置项，需要手工添加。依据redis文档的说明，若protected-mode设置为no后，需要增加密码证或是IP限制等保护机制，否则是极度危险的。）

启动sentinel

[root@redis ~]# nohup redis-sentinel /data/redis/conf/sentinel1.conf >> /data/redis/log/sentinel1.log 2>&1 &

[1] 16522

[root@redis ~]# nohup redis-sentinel /data/redis/conf/sentinel2.conf >> /data/redis/log/sentinel2.log 2>&1 &

[2] 16526

[root@redis ~]# ps -ef |grep sentinel

root 16522 16440 0 03:55 pts/2 00:00:00 redis-sentinel *:26300 [sentinel]

root 16526 16440 0 03:55 pts/2 00:00:00 redis-sentinel *:26301 [sentinel]

4.测试。模拟主节点故障，查看故障后主从环境改变

关闭主节点

[root@redis ~]# ps -ef |grep redis-server

root 16604 16440 0 04:12 pts/2 00:00:02 redis-server *:6381

root 16608 16440 0 04:12 pts/2 00:00:03 redis-server *:6382

root 16702 16314 0 04:46 pts/1 00:00:00 redis-server *:6380

[root@redis ~]# kill 16702

此时查看6381和6382的日志文件，在6382的日志文件中发现了如下内容，说明此时已经将6381切换为主节点。

再次启动6380时，6380成为slave，6381时master

最后查看一下sentinel配置文件：

cat /data/redis/conf/sentinel2.conf

port 26301

sentinel myid 74cdfbb5ae55a77ad4d05d5d9d50fd64725e192a

# Generated by CONFIG REWRITE

dir “/root”

protected-mode no

sentinel deny-scripts-reconfig yes

sentinel monitor redis1 127.0.0.1 6381 1 #主节点

sentinel config-epoch redis1 1

sentinel leader-epoch redis1 1

sentinel known-replica redis1 127.0.0.1 6382 #从节点

sentinel known-replica redis1 127.0.0.1 6380

sentinel known-sentinel redis1 127.0.0.1 26300 9539652da78b0385479a827e753deceaef864989

sentinel current-epoch 1

二. redis高可用方案–集群

使用哨兵模式，解决了主节点故障自动切换的问题，但是却不可以动态扩充redis。所以在redis3.0之后提出了集群模式。

redis集群设计：

redis集群采用无中心结构，每个节点保存数据和整个集群状态,每个节点都和其他所有节点连接。

特点：

所有的redis节点彼此互联(PING-PONG机制),内部使用二进制协议优化传输速度和带宽。
节点的失效是通过集群中超过半数的节点检测失效时才生效。
集群是一个整体，客户端与redis节点直连,不需要中间proxy层.客户端不需要连接集群所有节点,连接集群中任何一个可用节点即可。
Redis集群预分好16384个桶，当需要在 Redis 集群中放置一个 key-value 时，根据 CRC16(key) mod 16384的值，决定将一个key放到哪个桶中。