转:https://www.jianshu.com/p/74c4017d57ef
一、Redis Sentinel
Redis Sentinel是一个分布式架构(建议使用2.8以上版本),其中包含若干个Sentinel节点和Redis数据节点,每个Sentinel节点会对数据节点和其余Sentinel节点进行监控,当它发现节点不可达时,会对节点做下线标识。如果被标识的是主节点,它还会和其他Sentinel节点进行“协商”,当大多数Sentinel节点都认为主节点不可达时,它们会选举出一个Sentinel节点来完成自动故障转移的工作,同时会将这个变化实时通知给Redis应用方,从而实现真正的高可用。
Redis Sentinel包含了若个Sentinel节点,对于节点的故障判断是由多个Sentinel节点共同完成,这样可以有效地防止误判。同时,即使个别Sentinel节点不可用,整个Sentinel节点集合依然是健壮的。(生产环境中建议Redis Sentinel的所有节点应该分布在不同的物理机上。)
•监控:Sentinel节点会定期检测Redis数据节点、其余Sen-tinel节点是否可达。
•通知:Sentinel节点会将故障转移的结果通知给应用方。
•主节点故障转移:实现从节点晋升为主节点并维护后续正确的主从关系。
•配置提供者:在Redis Sentinel结构中,客户端在初始化的时候连接的是Sentinel节点集合,从中获取主节点信息。
1、配置与部署
配置说明
#配置Sentinel节点
redis-sentinel-26379.conf
port 26379 daemonize yes logfile "26379.log" dir /opt/soft/redis/data sentinel monitor mymaster 127.0.0.1 6379 2 sentinel down-after-milliseconds mymaster 30000 sentinel parallel-syncs mymaster 1 sentinel failover-timeout mymaster 180000 #启动 redis-sentinel redis-sentinel-26379.conf #确认 $ redis-cli -h 127.0.0.1 -p 26379 info Sentinel #Sentinel sentinel_masters:1 sentinel_tilt:0 sentinel_running_scripts:0 sentinel_scripts_queue_length:0 master0:name=mymaster,status=ok,address=127.0.0.1:6379,slaves=2,sentinels=3
sentinel monitor <master-name> <ip> <port> <quorum>
Sentinel节点会对所有节点进行监控,但是在Sentinel节点的配置中没有看到有关从节点和其余Sentinel节点的配置,那是因为Sentinel节点会从主节点中获取有关从节点以及其余Sentinel节点的相关信息。
<quorum>参数用于故障发现和判定,例如将quorum配置为2,代表至少有2个Sentinel节点认为主节点不可达,那么这个不可达的判定才是客观的。对于<quorum>设置的越小,那么达到下线的条件越宽松,反之越严格。一般建议将其设置为Sentinel节点的一半加1。同时<quorum>还与Sentinel节点的领导者选举有关,至少要max(quorum,num(sentinels)/2+1)个Sentinel节点参与选举,才能选出领导者Sentinel。
sentinel down-after-milliseconds <master-name> <times>
每个Sentinel节点都要通过定期发送ping命令来判断Re-dis数据节点和其余Sentinel节点是否可达,如果超过了down-after-milliseconds配置的时间且没有有效的回复,则判定节点不可达,<times>(单位为毫秒)就是超时时间。
down-after-milliseconds越大,代表Sentinel节点对于节点不可达的条件越宽松,反之越严格。条件宽松有可能带来的问题是节点确实不可达了,那么应用方需要等待故障转移的时间越长,也就意味着应用方故障时间可能越长。条件严格虽然可以及时发现故障完成故障转移,但是也存在一定的误判率。
sentinel parallel-syncs <master-name> <nums>
parallel-syncs就是用来限制在一次故障转移之后,每次向新的主节点发起复制操作的从节点个数。如果这个参数配置的比较大,那么多个从节点会向新的主节点同时发起复制操作,尽管复制操作通常不会阻塞主节点,但是同时向主节点发起复制,必然会对主节点所在的机器造成一定的网络和磁盘IO开销。
sentinel failover-timeout <master-name> <times>
failover-timeout通常被解释成故障转移超时时间,但实际上它作用于故障转移的各个阶段:
a)选出合适从节点。
b)晋升选出的从节点为主节点。
c)命令其余从节点复制新的主节点。
d)等待原主节点恢复后命令它去复制新的主节点。
上面任一阶段超过failover-timeout时间则故障转移失败,如果Redis Sentinel对一个主节点故障转移失败,那么下次再对该主节点做故障转移的起始时间是failover-timeout的2倍。
部署技巧
Sentinel节点不应该部署在一台物理“机器”上。
部署至少三个且奇数个的Sentinel节点。
只有一套Sentinel,还是每个主节点配置一套Sentinel。(前者维护方便,后者可用性更高)
2、Redis Sentinel API与客服端
API:
#主节点信息
127.0.0.1:26379> sentinel master mymaster-1
1) "name"
2) "mymaster-1" 3) "ip" 4) "127.0.0.1" 5) "port" 6) "6379" #从节点信息 127.0.0.1:26379> sentinel slaves mymaster-11) 1) "name" 2) "127.0.0.1:6380" 3) "ip" 4) "127.0.0.1" 5) "port" 6) "6380" .........忽略............ #哨兵信息 127.0.0.1:26379> sentinel sentinels mymaster-1 1) "name" 2) "127.0.0.1:26380" 3) "ip" 4) "127.0.0.1" 5) "port" 6) "26380" .........忽略............ #获取主节点ip+port 127.0.0.1:26379> sentinel get-master-addr-by-name mymaster-1 1) "127.0.0.1" 2) "6379" #强制故障转移,运维节点故障时且无法自动转移使用 127.0.0.1:26379> sentinel failover mymaster-2 OK #检测当前可达的Sentinel节点总数是否达到<quorum>的个数 127.0.0.1:26379> sentinel ckquorum mymaster-1 OK 3 usable Sentinels. Quorum and failover authorization can be reached
Redis Sentinel客户端在初始化和切换主节点时需要和Sentinel节点集合进行交互来获取主节点信息。
1)遍历Sentinel节点集合获取一个可用的Sentinel节点(Sentinel节点之间可以共享数据),从任意一个Sentinel节点获取主节点信息都是可以的。
2)通过sentinel get-master-addr-by-name master-name这个API来获取对应主节点的相关信息。
3)验证当前获取的“主节点”是真正的主节点,这样做的目的是为了防止故障转移期间主节点的变化。
#JedisSentinelPool
public class JedisSentinelPool extends Pool<Jedis> { //按照common-pool的标准模式 protected GenericObjectPoolConfig poolConfig; protected int connectionTimeout = Protocol.DEFAULT_TIMEOUT; protected int soTimeout = Protocol.DEFAULT_TIMEOUT; protected String password; protected int database = Protocol.DEFAULT_DATABASE; protected String clientName; protected Set<MasterListener> masterListeners = new HashSet<MasterListener>(); private volatile JedisFactory factory; private volatile HostAndPort currentHostMaster; public HostAndPort getCurrentHostMaster() { private void initPool(HostAndPort master) { if (!master.equals(currentHostMaster)) { currentHostMaster = master; if (factory == null) { factory = new JedisFactory(master.getHost(), master.getPort(), connectionTimeout, soTimeout, password, database, clientName); initPool(poolConfig, factory); } else { factory.setHostAndPort(currentHostMaster); internalPool.clear(); } log.info("Created JedisPool to master at " + master); } } #初始化哨兵节点和获取主节点 private HostAndPort initSentinels(Set<String> sentinels, final String masterName) { HostAndPort master = null; boolean sentinelAvailable = false; log.info("Trying to find master from available Sentinels..."); for (String sentinel : sentinels) { final HostAndPort hap = toHostAndPort(Arrays.asList(sentinel.split(":"))); log.fine("Connecting to Sentinel " + hap); Jedis jedis = null; try { jedis = new Jedis(hap.getHost(), hap.getPort()); // 使用sentinel get-master-addr-by-name masterName获取主节点信息 List<String> masterAddr = jedis.sentinelGetMasterAddrByName(masterName); // connected to sentinel... sentinelAvailable = true; // 命令返回列表为空或者长度不为2,继续从下一个sentinel节点查询 if (masterAddr == null || masterAddr.size() != 2) { log.warning("Can not get master addr, master name: " + masterName + ". Sentinel: " + hap + "."); continue; } master = toHostAndPort(masterAddr); log.fine("Found Redis master at " + master); break; } catch (JedisException e) { log