redis 高可用解决方案

【转自】http://warm-breeze.iteye.com/blog/2020413

本文主要介绍一种经过Jedis&Sentinel实现Redis集群高可用方案，该方案须要使用Jedis2.2.2及以上版本（强制），Redis2.8及以上版本(可选，Sentinel最先出如今Redis2.4中，Redis2.8中Sentinel更加稳定)，Redis集群是以分片(Sharding)加主从的方式搭建，知足可扩展性的要求；

 

Redis Sentinel介绍

Redis Sentinel是Redis官方提供的集群管理工具，主要有三大功能： 
监控，能持续监控Redis的主从实例是否正常工做； 
通知，当被监控的Redis实例出问题时，能经过API通知系统管理员或其余程序； 
自动故障恢复，若是主实例没法正常工做，Sentinel将启动故障恢复机制把一个从实例提高为主实例，其余的从实例将会被从新配置到新的主实例，且应用程序会获得一个更换新地址的通知。 
Redis Sentinel是一个分布式系统，能够部署多个Sentinel实例来监控同一组Redis实例，它们经过Gossip协议来肯定一个主实例宕机，经过Agreement协议来执行故障恢复和配置变动，通常在生产环境中部署多个实例来提升系统可用性，只要有一个Sentinel实例运行正常，就能保证被监控的Redis实例运行正常（相似Zookeeper，经过多个Zookeeper来提升系统可用性）； 
本文不涉及Sentinel的实现细节和工做原理，读者能够阅读其余文章了解；

 

Redis HA方案

HA的关键在于避免单点故障及故障恢复，在Redis Cluster未发布以前，Redis通常以主/从方式部署（这里讨论的应用从实例主要用于备份，主实例提供读写，有很多应用是读写分离的，读写操做须要取不一样的Redis实例，该方案也可用于此种应用，原理都是相通的，区别在于数据操做层如何封装），该方式要实现HA主要有以下几种方案： 
1，keepalived：经过keepalived的虚拟IP，提供主从的统一访问，在主出现问题时，经过keepalived运行脚本将从提高为主，待主恢复后先同步后自动变为主，该方案的好处是主从切换后，应用程序不须要知道(由于访问的虚拟IP不变)，坏处是引入keepalived增长部署复杂性； 
2，zookeeper：经过zookeeper来监控主从实例，维护最新有效的IP，应用经过zookeeper取得IP，对Redis进行访问； 
3，sentinel：经过Sentinel监控主从实例，自动进行故障恢复，该方案有个缺陷：由于主从实例地址(IP&PORT)是不一样的，当故障发生进行主从切换后，应用程序没法知道新地址，故在Jedis2.2.2中新增了对Sentinel的支持，应用经过redis.clients.jedis.JedisSentinelPool.getResource()取得的Jedis实例会及时更新到新的主实例地址。 
笔者所在的公司先使用了方案1一段时间后，发现keepalived在有些状况下会致使数据丢失，keepalived经过shell脚本进行主从切换，配置复杂，并且keepalived成为新的单点，后来选用了方案3，使用Redis官方解决方案；（方案2须要编写大量的监控代码，没有方案3简便，网上有人使用方案2读者可自行查看）

选用Sentinel出现的问题

Sentinel&Jedis看上去是个完美的解决方案，这句话只说对了一半，在无分片的状况是这样，但咱们的应用使用了数据分片-sharing，数据被平均分布到4个不一样的实例上，每一个实例以主从结构部署，Jedis没有提供基于Sentinel的ShardedJedisPool，也就是说在4个分片中，若是其中一个分片发生主从切换，应用所使用的ShardedJedisPool没法得到通知，全部对那个分片的操做将会失败。 
本文提供一个基于Sentinel的ShardedJedisPool，能及时感知全部分片主从切换行为，进行链接池重建，源码见ShardedJedisSentinelPool.java

 

ShardedJedisSentinelPool实现分析

构造函数

 相似以前的Jedis Pool的构造方法，须要参数poolConfig提供诸如maxIdle，maxTotal之类的配置，masters是一个List，用来保存全部分片Master在Sentinel中配置的名字（注意master的顺序不能改变，由于Shard算法是依据分片位置进行计算，若是顺序错误将致使数据存储混乱），sentinels是一个Set，其中存放全部Sentinel的地址(格式：IP:PORT，如127.0.0.1:26379)，顺序无关；

初始化链接池

在构造函数中，经过方法

 取得当前全部分片的master地址(IP&PORT)，对每一个分片，经过顺次链接Sentinel实例，获取该分片的master地址，若是没法得到，即全部Sentinel都没法链接，将休眠1秒后继续重试，直到取得全部分片的master地址，代码块以下： 

经过

 初始化链接池，到此链接池中的全部链接都指向分片的master；

监控每一个Sentinel

在方法

 最后，会为每一个Sentinel启动一个Thread来监控Sentinel作出的更改： 

该线程的run方法经过Jedis Pub/Sub API（实现JedisPubSub接口，并经过jedis.subscribe进行订阅）向Sentinel实例订阅“+switch-master”频道，当Sentinel进行主从切换时，该线程会获得新Master地址的通知，经过master name判断哪一个分片进行了切换，将新master地址替换原来位置的地址，并调用initPool(List masters)进行Jedis链接池重建；后续全部经过该链接池取得的链接都指向新Master地址，对应用程序透明；

应用示例

 
总结

本文经过现实中遇到的问题，即在Redis数据分片的状况下，在使用Sentinel作HA时，如何作到主从的切换对应用程序透明，经过Jedis的Pub/Sub功能，能同时监控多个分片的主从切换状况，并经过监听到的新地址从新构造链接池，后续从链接池中取得的全部链接都指向新地址。该方案的关键是：使用sentinel作HA，Jedis版本必须2.2.2及以上，全部访问Redis实例的链接都必须从链接池中获取；

该项目的GitHub主页: https://github.com/warmbreeze/sharded-jedis-sentinel-pool