Redis【一】Redis主从复制原理
Redis【二】Redis哨兵模式原理
Redis的高可用实现方案现在官方的有redis-sentinel redis-cluster都是直连（非代理模式）
- redis-sentinel 是主从模式，同一时间只有一个master实例可以写，其他从节点是只读的，如果master节点宕机，redis-sentinel之间会通过raft协议选举出一个负责故障迁移的主redis-sentinel，这个主redis-sentinel负责选择一个slave redis节点作为master，设置其他slave的master为这个新的master
- redis-cluster 是集群、分片加主从模式
1. redis-sentinel拓扑结构图
redis-sentinel拓扑结构图
如上图所示，sentinel是在正常的redis主从配置的基础上，通过监控redis节点的健康状况，实现自动化的主从切换。如果master节点挂掉了，sentinel会及时的发现，自动化的设置新的master，并把其他的slave指向新的master。
Sentinel本质上也是一个Redis节点，但是仅支持部分命令
redis-sentinel基本配置
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
其中最主要的配置是sentinel monitor mymaster 127.0.0.1 6379 2，格式为sentinel monitor {masterMame} {masterIP} {masterPort} {quorum}
- masterName 是当sentinel同时监控多套redis主从的时候区分不同的主从的。
- masterIP masterPort 是监控的Redis实例中master的IP和port，sentinel通过该master可以获取其他所有的slave实例和sentinel节点
- quorum 用于故障发现和判定，如果quorum=2，则代表至少2个Sentinel节点认为主节点不可达，这个不可达的判定才是客观的。一般设置为 {sentinel实例个数}/2 + 1
redis-sentinel的3个定时任务
- 每隔10秒，向Redis master和slave节点发送info命令获取最新的拓扑结构
通过解析info命令中的Replication信息，sentinel就可以获取到所有的最新的master和slave节点，这也是为什么sentinel配而不需要显示的配置slave节点。
定期向Redis master和slave节点发送info命令
- 每隔2秒，向master节点的sentinel:hello 频道上publish该sentinel节点对于主节点的判断以及当前sentinel节点的信息，同时每个sentinel节点也会订阅该频道，来了解其他sentinel节点以及它们对主节点的判断。 所以这个定时任务可以完成以下两个工作：
- sentinel节点之间互相发现，每个sentinel节点上只配置了redis master节点， 通过这种方式，sentinel节点之间就可以实现互相发现。来实现后续的sentinel节点之间的互相通信、选举操作
sentinel节点之间交换主节点状态，作为后面客观下线以及领导者选举的依据。
10.xx.xx.xx,26379,811ee2bc21cfc21e6aea0da3ed90f80deeod91kc,1530,mymaster,10.xx.xx.xx,6379,1530
sentinel节点publish的消息格式如下：
{sentinel节点IP} {sentinel节点端口} {sentinel节点runId} {sentinel节点配置版本} {主节点名字} {主节点IP} {主节点Port} {主节点配置版本}，示例：
每隔2秒向master publish当前sentinel的状态
每隔1秒，会向master、slave节点、其余sentinel节点发送ping命令做一次心跳检测，来确认这些节点当前是否可达。sentinel就是基于这个ping命令来决定redis节点和sentinel节点是否活着。
每隔1秒向master、slave节点以及其他sentinel节点发送ping
2. redis-sentinel故障迁移流程
主观下线和客观下线
- 主观下线
上面介绍的sentinel的第三个定时任务每秒对其他的节点ping一次，如果这个节点超过down-after-milliseconds没有有效的回复，该sentinel节点就会对这个节点做失败判定，这个行为是主观下线。由此可见主观下线只是单个sentinel的判定行为，在分布式环境中，肯定不能只靠一个节点的判断。 - 客观下线
当sentinel主观下线的节点是master时，该sentinel就会向其他sentinel节点发送sentinel is-master-down-by-addr命令询问对主节点的判断，当超过{quorum}个数sentinel节点认为主节点确实有问题，这时该sentinel会做出客观下线的决定。
leader选举
sentinel做出客观下线的决定之后并不会立即进行故障转移，而是要在sentinel之间选举出一个leader，由leader来执行具体的故障转移工作。
其实在上面的客观下线中，sentinel发送sentinel is-master-down-by-addr命令的时候就已经包含了leader选举的一些信息。
sentinel is-master-down-by-addr {故障masterIP} {故障masterPort} {downState} {leader_runid}
- downState：1是下线、0是在线
- leader_runid：如果为*，表示返回结果只是用来表示主节点是否可达，当leader_runid等于具体的runid时，就代表目标节点同意runid称为leader
故障转移
上面选择出一个sentinel作为leader之后，该leader就会开始操作故障转移，具体步骤如下：
-
从所有slave中选出一个slave作为新的master，选择方法如下图所示：
选取从节点过程 - sentinel leader对选择出来的master执行slaveof no one命令让其成为真正的master
- sentinel leader对其他slave发送命令，让它们成为新master的slave，新的slave的复制规则与parallel-syncs（同时允许多少个slave执行sync操作）的配置有关系
- sentinel leader将原来的master更新为slave，并保持对其监控，当它恢复后命令它去复制新的master
3. redis-sentinel客户端逻辑
实现一个Redis Sentinel客户端的基本步骤如下：
- 遍历sentinel节点集合获取一个可用的sentinel节点， 对sentinel节点调用sentinel get-master-addr-by-name master这个API来获取对应主节点的相关信息
- sentinel客户端订阅sentinel的swtich-master事件，如果master有变更，需要更新redis连接。
- sentinel客户端如果是维护的连接池，在获取连接的时候要检查该连接是否与最新的master是一致的，如果不一致就要销毁该连接，重新获取。
redis.clients.jedis.JedisSentinelPool
private HostAndPort initSentinels(Set<String> sentinels, final String masterName) {
HostAndPort master = null;
boolean sentinelAvailable = false;
log.info("Trying to find master from available Sentinels...");
// 遍历sentinel节点，尝试获取master节点
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获取master节点
List<String> masterAddr = jedis.sentinelGetMasterAddrByName(masterName);
// connected to sentinel...
sentinelAvailable = true;
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) {
...
} finally {
if (jedis != null) {
jedis.close();
}
}
}
...
for (String sentinel : sentinels) {
final HostAndPort hap = toHostAndPort(Arrays.asList(sentinel.split(":")));
// MasterListener会订阅sentinel节点的swatich-master渠道，如果master有变更，就会执行initPool操作
MasterListener masterListener = new MasterListener(masterName, hap.getHost(), hap.getPort());
// whether MasterListener threads are alive or not, process can be stopped
masterListener.setDaemon(true);
masterListeners.add(masterListener);
masterListener.start();
}
return master;
}
// 根据最新的master更新线程池中的jedis连接
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);
// clear操作只会destroy idle状态的jedis连接，不会释放正在使用的jedis连接。所以需要在getResource的时候再次做检查
internalPool.clear();
}
log.info("Created JedisPool to master at " + master);
}
}
// 从连接池中获取一个连接
public Jedis getResource() {
while (true) {
Jedis jedis = super.getResource();
jedis.setDataSource(this);
// get a reference because it can change concurrently
final HostAndPort master = currentHostMaster;
final HostAndPort connection = new HostAndPort(jedis.getClient().getHost(), jedis.getClient()
.getPort());
// 检查当前连接的master与最新的master是否相同，如果相同就可以直接返回
if (master.equals(connection)) {
return jedis;
} else {
// 如果master不正确，就把该jedis连接返回给连接池，重新尝试从连接池获取
returnBrokenResource(jedis);
}
}
}
