Redis哨兵高可用架构

redis在生产环境为了保持高可用，通常有几种方式：主从、哨兵和集群，主从是基础中的基础，哨兵是特殊的redis服务，用来监控redis实例节点。

在哨兵架构下，客户端第一次访问时通过哨兵找到主节点，后续就会直接访问主节点，当主节点发生变化时，哨兵会第一时间感知到，并且第一时间通知给客户端。

准备工作：redis版本：5.0.10。启动三个redis实例，6379为master，6380和6381为slave。

上哨兵配置：

#复制一份sentinel.conf文件 
cp sentinel.conf sentinel‐26379.conf 
# 编辑配置文件
vi sentinel‐26379.conf 
# 哨兵端口号
port 26379
# 允许后台运行
daemonize yes
# 进程文件 
pidfile "/var/run/redis‐sentinel‐26379.pid" 
# 日志文件名称
logfile "26379.log" 
# 数据文件目录
dir "/usr/local/redis‐5.0.10/data/26379" 
# 哨兵监控
sentinel monitor mymaster 192.168.0.16 6379 2
# 启动哨兵
src/redis‐sentinel sentinel‐26379.conf

在哨兵配置文件中，有一行内容：

# sentinel monitor <master‐redis‐name> <master‐redis‐ip> <master‐redis‐port> <quorum>

master‐redis‐name随便取，此处取名为mymaster，quorum表示的是当多少个哨兵认为master失效时，master才算真正的失效。

再配置两个哨兵，端口使用26380，26381

查看哨兵信息，可以看到已经识别主从

src/redis‐cli ‐p 26379
127.0.0.1:26379>info

哨兵集群启动完毕之后，哨兵会将集群的元数据追加到配置文件中

# 表示从节点
sentinel known‐replica mymaster 192.168.0.16 6380  
sentinel known‐replica mymaster 192.168.0.16 6381  
# 其他哨兵节点
sentinel known‐sentinel mymaster 192.168.0.16 26380 20ec81e05363c04b9a6e9cb0e172e1e8e5ba44b4  
sentinel known‐sentinel mymaster 192.168.0.16 26381 5779a19510594f650b591be880ec32490375ef90 

如果主节点挂掉，哨兵会重新选取主节点。查看哨兵配置

# 表示从节点
sentinel known‐replica mymaster 192.168.0.16 6379  
sentinel known‐replica mymaster 192.168.0.16 6381  
# 其他哨兵节点
sentinel known‐sentinel mymaster 192.168.0.16 26380 ac78eca353f2b5717a93bfffccddb7fc571f5805  
sentinel known‐sentinel mymaster 192.168.0.16 26381 5779a19510594f650b591be880ec32490375ef90 

同时将配置文件中的哨兵监控主节点改掉

sentinel monitor mymaster 192.168.0.16 6380 2

主节点启动之后会当做从节点加入哨兵集群中。

哨兵架构下，master节点异常时会由哨兵选举新的master并做主从切换，切换的这段时间容易出现访问瞬断。且哨兵架构中，只有一个主节点对外提供服务，所以并发量不高，而且单主节点不易将内存设置过大，否则数据太多，持久化文件过大，会影响主从同步和数据恢复的性能。所以哨兵在高性能和高可用的表现其实一般，但满足小公司的一般性需求和体验是可以的。现在更多的选择是redis提供的集群服务，多个主从节点组成的分布式集群架构，可用性和性能更高。