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提供的集群服务，多个主从节点组成的分布式集群架构，可用性和性能更高。