redis-sentinel 高可用方案实践

近期公司的一块核心业务使用redis作为配置转发中心，存在单点问题，考虑服务的可靠性。针对业务需求，我们确定了我们的需求：

1. 异地跨机房容灾
2. 故障自动切换
3. 尽可能高的保证数据不丢失

针对以上需求，我们分别对redis主从复之，redis-cluster，redis-sentinel方案进行了调研，对比结果如下：

方案	数据可靠性	服务可靠性	风险
主从备份	高	无	出问题需要手动切换，中间推送的数据会丢失
redis-cluster	高	高	异地机房热备，机房间网络出问题的情况下会出现脑裂的问题；同时我们对redis-cluster无运维和使用经验
redis-sentinel	高	中	在master宕机后，客户端会通过api查询当前master归属，重连redis 使用内网同步，主从之间的数据丢失同步基本可以忽略，业务可以忍受

基于以上调研，我们放弃了主从备份方案，对redis-cluster及redis-sentinel方案进行了深入分析。redis-cluster采用主从备份、master选举的方式实现高可用，但在异地机房部署时，如配置不当，很容易引发脑裂问题；同时由于redis-cluster我们并没有成熟的运维经验，最终放弃了该方案，转向redis-sentinel。 redis-sentinel就像他的名字一样，他是一个哨兵，监控master状态，如果超过规定时间没有响应，则自动进行主从切换，期间会有一段时间（决定于具体的配置参数）redis集群无法提供服务 。原理类似mysql的MHA。redis-sentinel-server同时提供了一套接口，用于查询当前集群的状态，Java的客户端有完整的封装，php的扩展并没有提供相应功能，在github上有几个package，但由于太过复杂，不适合迁移到现有业务（没有使用命名空间和composer），所以基于phpredis-2.2.8封装了一个简易的redis-sentinel客户端，目前已在核心业务生产环境上稳定运行。Java客户端与php客户端通过查询redis-sentinel集群获得当前redis-master地址，进行连接，当集群发生主从切换时，客户端会进行重连。 php-redis-sentinel的demo代码如下：

1 2 3 4 5 6 7 8 9 10

$sentinel_pool = new \Jenner\RedisSentinel\SentinelPool(); $sentinel_pool->addSentinel('127.0.0.1', 26379); $sentinel_pool->addSentinel('127.0.0.1', 26380);   $address = $sentinel_pool->master('mymaster'); print_r($address);   $redis = $sentinel_pool->getRedis('mymaster'); $info = $redis->info(); print_r($info);

参考资料： redis-sentinel: https://redis.io/topics/sentinel cluster-tutorial: https://redis.io/topics/cluster-tutorial cluster-spec: https://redis.io/topics/cluster-spec  

原创文章，转载请注明： 转载自始终不够