目录
哨兵模式
哨兵配置
启动哨兵
测试哨兵
当前问题
从上一篇改进为哨兵模式
云服务器redis主从复制-一主二仆-CSDN博客主机数据更新后，自动同步到备机Master以写为主，Slave以读为主目的读写分离，性能扩展容灾快速恢复1 一个redis服务作为主机,主要负责写操作2 两个redis服务作为从机,主要负责读操作3 从机自动从主机同步数据下来4 从机主动找主机,而主机不会找从机！！注意：生产环境，主从复制每个服务都在不同的机器上，这里使用一台机器 不同端口模拟搭建真是环境。https://blog.csdn.net/guo13313/article/details/167179189?spm=1001.2014.3001.5502
哨兵模式
能够后台监控主机是否故障，如果故障了根据投票数自动将从库转换为主库
在原来的一主二仆模式下进行改造
进入到目录
cd /opt/redis/master_slave
哨兵配置
新建 sentinel.conf 文件，内容如下
sentinel monitor mymaster 127.0.0.1 6379 1
# 其中mymaster为监控对象起的服务器名称， 1 为至少有多少个哨兵同意迁移的数量。
启动哨兵
redis-sentinel sentinel.conf
测试哨兵
当主机宕机,会从从机中选择一个作为新的主机,根据优先级slave-properity, 原主机重启后会成为从机
# 关闭主节点
redis-cli -p 6379
shutdown
+sdown：主观下线（Subjective Down）当前这个哨兵进程，单方面认为 master（mymaster，127.0.0.1:6379）挂了。只是单个哨兵的判断，不代表集群认定主节点故障。
+odown：客观下线（Objective Down）多个哨兵达成共识，判定主节点真的宕机，可以触发故障转移。
quorum 1/1：法定票数 1，当前达成投票 1。哨兵配置
quorum=1，单哨兵架构。只要这一个哨兵认为主节点挂了，直接进入客观下线，开始选主。生产环境强烈不建议 quorum=1，单点哨兵本身就是单点故障！
进入到 6381
redis-cli -p 6381
info replication
可以看到 6381已经切换为master节点
当前问题
- 哨兵模式，配置了一台哨兵，生产环境起码要配置3台，防止哨兵挂了，高可用直接失效
- 容量不够，后续如何扩容，是否方便
- 并发写操作，如何分摊
集群。。。
