1、哨兵模式
反客为主的自动版，能够后台监控主机是否故障，如果故障了根据投票数自动将从库转换为主库
1. 哨兵模式步骤
1）调整为一主二仆模式，6379带着6380、6381
其他模式也可以，一主二仆更明显
2）自定义的/opt/module/redis目录下新建sentinel.conf文件，名字绝不能错
3）配置哨兵,填写内容
sentinel monitor mymaster 127.0.0.1 6379 1
其中mymaster为监控对象起的服务器名称（名称随意）， 1 为至少有多少个哨兵同意迁移的数量（1则表示至少1个哨兵同意即可）。
4）启动哨兵redis-sentinel
redis-sentinel /opt/module/redis/sentinel.conf
redis做压测可以用自带的redis-benchmark工具
执行redis-sentinel /myredis/sentinel.conf
默认的端口号：26379
编写java代码时，应该在连接池中指定url为sentinel哨兵的端口号（因为master的端口号是不能被确定的）
5）主机挂掉，从机选举中产生新的主机
(大概10秒左右可以看到哨兵窗口日志，切换了新的主机)
哪个从机会被选举为主机呢？根据优先级别：slave-priority
原主机重启后会变为从机。
6）复制延时
由于所有的写操作都是先在Master上操作，然后同步更新到Slave上，所以从Master同步到Slave机器有一定的延迟，当系统很繁忙的时候，延迟问题会更加严重，Slave机器数量的增加也会使这个问题更加严重。
7）故障恢复
| 新主登基 | 群仆俯首 | 旧主俯首 |
|---|---|---|
| 所有从服务中挑选一个作为主服务；选择次序： 1、选择优先级靠前的； 2、选择偏移量最大的； 3、选择runid最小的 |
挑选主新的主服务后，sentinel向原主服务的从服务发送slaveof新主服务命令，复制新master | 当已下线的服务重新上线时，sentinel会向其发送slaveof命令，让其变为从服务 |
- 优先级在redis.conf中默认：replica-priority 100，值越小优先级越高
早起版本是：slave-priority 100
6版本之后：replica-priority 100
-
偏移量是指获得原主机数据最全的
-
每个redis实例启动后都会随机生成一个40位的runid
8）java实现主从复制
private static JedisSentinelPool jedisSentinelPool=null;
public static Jedis getJedisFromSentinel(){
if(jedisSentinelPool==null){
Set<String> sentinelSet=new HashSet<>();
// 指定url为哨兵的端口
sentinelSet.add("192.168.11.103:26379");
JedisPoolConfig jedisPoolConfig =new JedisPoolConfig();
jedisPoolConfig.setMaxTotal(10); //最大可用连接数
jedisPoolConfig.setMaxIdle(5); //最大闲置连接数
jedisPoolConfig.setMinIdle(5); //最小闲置连接数
jedisPoolConfig.setBlockWhenExhausted(true); //连接耗尽是否等待
jedisPoolConfig.setMaxWaitMillis(2000); //等待时间
jedisPoolConfig.setTestOnBorrow(true); //取连接的时候进行一下测试 ping pong
// 指定服务名称，哨兵中配置的
jedisSentinelPool=new JedisSentinelPool("mymaster",sentinelSet,jedisPoolConfig);
return jedisSentinelPool.getResource();
}else{
return jedisSentinelPool.getResource();
}
}