Redis-HA高可用方案Sentinel配置

上一节中介绍了master-slave模式，在最小配置：master、slave各一个节点的情况下，不管是master还是slave down掉一个，“完整的”读/写功能都将受影响，这在生产环境中显然不能接受。幸好redis提供了sentinel（哨兵）机制，通过sentinel模式启动redis后，自动监控master/slave的运行状态，基本原理是：心跳机制+投票裁决

每个sentinel会向其它sentinal、master、slave定时发送消息，以确认对方是否“活”着，如果发现对方在指定时间（可配置）内未回应，则暂时认为对方已挂（所谓的“主观认为宕机” Subjective Down，简称SDOWN）。

若“哨兵群”中的多数sentinel，都报告某一master没响应，系统才认为该master"彻底死亡"(即：客观上的真正down机，Objective Down，简称ODOWN)，通过一定的vote算法，从剩下的slave节点中，选一台提升为master，然后自动修改相关配置。

1     @Test
2     public void testRedisson() throws InterruptedException, ExecutionException,
3             TimeoutException {
4
5         Config config = new Config();
6
7         config.useSentinelConnection().setMasterName("mymaster")
8                 .addSentinelAddress("10.6.144.155:7031", "10.6.144.156:7031");
9         config.useSentinelConnection().setRetryInterval(1000);
10         config.useSentinelConnection().setRetryAttempts(1);
11
12         Redisson redisson = Redisson.create(config);
13
14         String key = "test";
15
16         RBucket<String> myObj = redisson.getBucket(key);
17         if (myObj != null) {
18             myObj.delete();
19         }
20
21         myObj.set("aaa");// 写入
22
23         System.out.println(myObj.get());// 读取
24
25         myObj.set("bbb");// down掉master，观察是否能写入新master
26
27         System.out.println(myObj.get());
28
29         redisson.shutdown();
30
31     }

View Code
同样做类似的测试，二次写，二次读，如果第1次写后，人工down掉master，剩下的slave会提升成master，第二次写ok，但此时redis节点中，只剩master，没有slave了，从测试结果上看，第二次get还是尝试去找slave节点，但是此时已经不存在了，所以一直在等候，导致后面的的处理被阻塞。

这不是redis的问题，而是Redisson客户端设计不够智能。

鉴于这种现状，如果要使用Redisson，最好做成1主2从的部署结构：(sentinel.conf中的“法定人数”，建议调整成2)



这样的好处是，1个master挂掉后，剩下的2台slave中，会有1台提升为master，整体仍然保证有1个master和1个slave，读写均不受影响。

关于Sentinel的更多细节，可参考官网文档：http://www.redis.io/topics/sentinel