redis 学习笔记(4)-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，然后自动修改相关配置。

@Test
public void testRedisson() throws InterruptedException, ExecutionException,
TimeoutException {

Config config = new Config();

config.useSentinelConnection().setMasterName("mymaster")
.addSentinelAddress("10.6.144.155:7031", "10.6.144.156:7031");
config.useSentinelConnection().setRetryInterval(1000);
config.useSentinelConnection().setRetryAttempts(1);

Redisson redisson = Redisson.create(config);

String key = "test";

RBucket<String> myObj = redisson.getBucket(key);
if (myObj != null) {
myObj.delete();
}

myObj.set("aaa");// 写入

System.out.println(myObj.get());// 读取

myObj.set("bbb");// down掉master，观察是否能写入新master

System.out.println(myObj.get());

redisson.shutdown();

}

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