Redis入门完整教程：客户端连接

通过前面的学习，相信读者对Redis Sentinel有了一定的了解，本节将介
绍应用方如何正确地连接Redis Sentinel。有人会说这有什么难的，已经知道
了主节点的ip地址和端口，用对应编程语言的客户端连接主节点不就可以了
吗？但试想一下，如果这样使用客户端，客户端连接Redis Sentinel和主从复
制的Redis又有什么区别呢，如果主节点挂掉了，虽然Redis Sentinel可以完
成故障转移，但是客户端无法获取这个变化，那么使用Redis Sentinel的意义
就不大了，所以各个语言的客户端需要对Redis Sentinel进行显式的支持。

9.4.1　Redis Sentinel的客户端
Sentinel节点集合具备了监控、通知、自动故障转移、配置提供者若干
功能，也就是说实际上最了解主节点信息的就是Sentinel节点集合，而各个
主节点可以通过进行标识的，所以，无论是哪种编程语言的
客户端，如果需要正确地连接Redis Sentinel，必须有Sentinel节点集合和
masterName两个参数。

9.4.2　Redis Sentinel客户端基本实现原理
实现一个Redis Sentinel客户端的基本步骤如下：
1）遍历Sentinel节点集合获取一个可用的Sentinel节点，后面会介绍
Sentinel节点之间可以共享数据，所以从任意一个Sentinel节点获取主节点信
息都是可以的，如图9-22所示。
2）通过sentinel get-master-addr-by-name master-name这个API来获取对应
主节点的相关信息，如图9-23所示。
3）验证当前获取的“主节点”是真正的主节点，这样做的目的是为了防
止故障转移期间主节点的变化，如图9-24所示。

4）保持和Sentinel节点集合的“联系”，时刻获取关于主节点的相关“信
息”，如图9-25所示。

从上面的模型可以看出，Redis Sentinel客户端只有在初始化和切换主节
点时需要和Sentinel节点集合进行交互来获取主节点信息，所以在设计客户
端时需要将Sentinel节点集合考虑成配置（相关节点信息和变化）发现服
务。
上述过程只是从客户端设计的角度进行分析，在开发客户端时要考虑的
细节还有很多，但是这些问题并不需要深究，下面将介绍如何使用Java的
Redis客户端操作Redis Sentinel，并结合本节的内容分析一下相关源码。

9.4.3　Java操作Redis Sentinel
我们依然使用Jedis2.8.2（以下简称Jedis）作为Redis的Java客户端，
Jedis能够很好地支持Redis Sentinel，并且使用Jedis连接Redis Sentinel也很简
单，按照Redis Sentinel的原理，需要有masterName和Sentinel节点集合两个参
数。第4章我们介绍了Jedis的连接池JedisPool，为了不与之相混淆，Jedis针
对Redis Sentinel给出了一个JedisSentinelPool，很显然这个连接池保存的连接
还是针对主节点的。Jedis给出很多构造方法，其中最全的如下所示：

public JedisSentinelPool(String masterName, Set sentinels,
final GenericObjectPoolConfig poolConfig, final int connectionTimeout,
final int soTimeout,
final String password, final int database,
final String clientName)

具体参数含义如下：
·masterName——主节点名。
·sentinels——Sentinel节点集合。
·poolConfig——common-pool连接池配置。
·connectTimeout——连接超时。
·soTimeout——读写超时。
·password——主节点密码。
·database——当前数据库索引。
·clientName——客户端名。
例如要想通过简单的几个参数获取JedisSentinelPool，可以直接按照下
面方式进行JedisSentinelPool的初始化。
JedisSentinelPool jedisSentinelPool = new JedisSentinelPool(masterName,
sentinelSet, poolConfig, timeout);
此时timeout既代表连接超时又代表读写超时，password为空，database
默认使用0，clientName为空。具体可以参考JedisSentinelPool源码。
和JedisPool非常类似，我们在使用JedisSentinelPool时也要尽可能按照
common-pool的标准模式进行代码的书写，和第4章介绍的JedisPool的推荐使
用方法是一样的，这里就不赘述了。 

Jedis jedis = null;
try {
jedis = jedisSentinelPool.getResource();
// jedis command
} catch (Exception e) {
logger.error(e.getMessage(), e);
} finally {
if (jedis != null)
jedis.close();
}

jedis.close（）是和第4章介绍的一样，并不是关闭Jedis连接。
JedisSentinelPool和JedisPool一样，尽可能全局只有一个。
Jedis源码中的JedisSentinelPool就是按照9.4.2节的原理来实现的，所以
有必要介绍一下JedisSentinelPool的实现过程，下面给出的代码就是

JedisSentinelPool的初始化方法。
public JedisSentinelPool(String masterName, Set sentinels,
final GenericObjectPoolConfig poolConfig, final int connectionTimeout,
final int soTimeout, final String password, final int database,
final String clientName) {
…
HostAndPort master = initSentinels(sentinels, masterName);
initPool(master);
…
}
下面的代码就是JedisSentinelPool初始化代码的重要函数
initSentinels（Setsentinels，final String masterName），和9.4.2节分析
的一样，包含了Sentinel节点集合和masterName参数，用来获取指定主节点
的ip地址和端口。

private HostAndPort initSentinels(Set sentinels, final String masterName) {
//  主节点
HostAndPort master = null;
//  遍历所有 sentinel 节点
for (String sentinel : sentinels) {
//  连接 sentinel 节点
HostAndPort hap = toHostAndPort(Arrays.asList(sentinel.split(":")));
Jedis jedis = new Jedis(hap.getHost(), hap.getPort());
//  使用 sentinel get-master-addr-by-name masterName 获取主节点信息
List masterAddr = jedis.sentinelGetMasterAddrByName(masterName);
//  命令返回列表为空或者长度不为 2 ，继续从下一个 sentinel 节点查询
if (masterAddr == null || masterAddr.size() != 2) {
continue;
}
//  解析 masterAddr 获取主节点信息
master = toHostAndPort(masterAddr);
//  找到后直接跳出 for 循环
break;
}
if (master == null) {
//  直接抛出异常，
throw new Exception();
}
//  为每个 sentinel 节点开启主节点 switch 的监控线程
for (String sentinel : sentinels) {
final HostAndPort hap = toHostAndPort(Arrays.asList(sentinel.split(":")));
MasterListener masterListener = new MasterListener(masterName, hap.getHost(),
hap.getPort());
masterListener.start();
}
//  返回结果
return master;
}

具体过程如下：
1）遍历Sentinel节点集合，找到一个可用的Sentinel节点，如果找不到就
从Sentinel节点集合中去找下一个，如果都找不到直接抛出异常给客户端：
new JedisException("Can connect to sentinel, but " + masterName + " seems to be not monitored...")
2）找到一个可用的Sentinel节点，执行
sentinelGetMasterAddrByName（masterName），找到对应主节点信息：
List masterAddr = jedis.sentinelGetMasterAddrByName(masterName);
3）JedisSentinelPool中没有发现对主节点角色验证的代码，这是因为
get-master-addr-by-name master-name这个API本身就会自动获取真正的主节点
（例如故障转移期间）。
4）为每一个Sentinel节点单独启动一个线程，利用Redis的发布订阅功
能，每个线程订阅Sentinel节点上切换master的相关频道+switch-master。
for (String sentinel : sentinels) {
final HostAndPort hap = toHostAndPort(Arrays.asList(sentinel.split(":")));
MasterListener masterListener = new MasterListener(masterName, hap.
getHost(), hap.getPort());
masterListener.start();
}
下面代码就是MasterListener的核心监听代码，代码中比较重要的部分就
是订阅Sentinel节点的+switch-master频道，它就是Redis Sentinel在结束对主
节点故障转移后会发布切换主节点的消息，Sentinel节点基本将故障转移的
各个阶段发生的行为都通过这种发布订阅的形式对外提供，开发者只需订阅
感兴趣的频道即可（参见9.6节表9-6），这里我们比较关心的是+switch-
master这个频道。

Jedis sentinelJedis = new Jedis(sentinelHost, sentinelPort);
//  客户端订阅 Sentinel 节点上 "+switch-master"( 切换主节点 ) 频道
sentinelJedis.subscribe(new JedisPubSub() {
@Override
public void onMessage(String channel, String message) {
String[] switchMasterMsg = message.split(" ");
if (switchMasterMsg.length > 3) {
//  判断是否为当前 masterName
if (masterName.equals(switchMasterMsg[0])) {
//  发现当前 masterName 发生 switch ，使用 initPool 重新初始化连接池
initPool(toHostAndPort(switchMasterMsg[3], switchMasterMsg[4]));
}
}
}
}, "+switch-master");

9.5　实现原理
本节将介绍Redis Sentinel的基本实现原理，具体包含以下几个方面：
Redis Sentinel的三个定时任务、主观下线和客观下线、Sentinel领导者选举、
故障转移，相信通过本节的学习读者能对Redis Sentinel的高可用特性有更加
深入的理解和认识。

9.5.1　三个定时监控任务
一套合理的监控机制是Sentinel节点判定节点不可达的重要保证，Redis
Sentinel通过三个定时监控任务完成对各个节点发现和监控：
1）每隔10秒，每个Sentinel节点会向主节点和从节点发送info命令获取
最新的拓扑结构，如图9-26所示。

例如下面就是在一个主节点上执行info replication的结果片段：
# Replication
role:master
connected_slaves:2
slave0:ip=127.0.0.1,port=6380,state=online,offset=4917,lag=1
slave1:ip=127.0.0.1,port=6381,state=online,offset=4917,lag=1
Sentinel节点通过对上述结果进行解析就可以找到相应的从节点。
这个定时任务的作用具体可以表现在三个方面：
·通过向主节点执行info命令，获取从节点的信息，这也是为什么
Sentinel节点不需要显式配置监控从节点。
·当有新的从节点加入时都可以立刻感知出来。
·节点不可达或者故障转移后，可以通过info命令实时更新节点拓扑信
息。
2）每隔2秒，每个Sentinel节点会向Redis数据节点的__sentinel__：hello
频道上发送该Sentinel节点对于主节点的判断以及当前Sentinel节点的信息
（如图9-27所示），同时每个Sentinel节点也会订阅该频道，来了解其他
Sentinel节点以及它们对主节点的判断，所以这个定时任务可以完成以下两
个工作：
·发现新的Sentinel节点：通过订阅主节点的__sentinel__：hello了解其他
的Sentinel节点信息，如果是新加入的Sentinel节点，将该Sentinel节点信息保
存起来，并与该Sentinel节点创建连接。
·Sentinel节点之间交换主节点的状态，作为后面客观下线以及领导者选
举的依据。
Sentinel节点publish的消息格式如下：

< 主节点名字 > < 主节点 Ip> < 主节点端口 > < 主节点配置版本 >
3）每隔1秒，每个Sentinel节点会向主节点、从节点、其余Sentinel节点
发送一条ping命令做一次心跳检测，来确认这些节点当前是否可达。如图9-
28所示。通过上面的定时任务，Sentinel节点对主节点、从节点、其余
Sentinel节点都建立起连接，实现了对每个节点的监控，这个定时任务是节
点失败判定的重要依据。 

9.5.2　主观下线和客观下线
1.主观下线
上一小节介绍的第三个定时任务，每个Sentinel节点会每隔1秒对主节
点、从节点、其他Sentinel节点发送ping命令做心跳检测，当这些节点超过
down-after-milliseconds没有进行有效回复，Sentinel节点就会对该节点做失败
判定，这个行为叫做主观下线。从字面意思也可以很容易看出主观下线是当
前Sentinel节点的一家之言，存在误判的可能，如图9-29所示。 

2.客观下线
当Sentinel主观下线的节点是主节点时，该Sentinel节点会通过sentinel is-
master-down-by-addr命令向其他Sentinel节点询问对主节点的判断，当超过
个数，Sentinel节点认为主节点确实有问题，这时该Sentinel节点会
做出客观下线的决定，这样客观下线的含义是比较明显了，也就是大部分
Sentinel节点都对主节点的下线做了同意的判定，那么这个判定就是客观
的，如图9-30所示。
注意
从节点、Sentinel节点在主观下线后，没有后续的故障转移操作。
这里有必要对sentinel is-master-down-by-addr命令做一个介绍，它的使用
方法如下：
sentinel is-master-down-by-addr
·ip：主节点IP。
·port：主节点端口。
·current_epoch：当前配置纪元。
·runid：此参数有两种类型，不同类型决定了此API作用的不同。
当runid等于“*”时，作用是Sentinel节点直接交换对主节点下线的判定。 

当runid等于当前Sentinel节点的runid时，作用是当前Sentinel节点希望目
标Sentinel节点同意自己成为领导者的请求，有关Sentinel领导者选举，后面
会进行介绍。

例如sentinel-1节点对主节点做主观下线后，会向其余Sentinel节点（假
设sentinel-2和sentinel-3节点）发送该命令：
sentinel is-master-down-by-addr 127.0.0.1 6379 0 *
返回结果包含三个参数，如下所示：
·down_state：目标Sentinel节点对于主节点的下线判断，1是下线，0是
在线。
·leader_runid：当leader_runid等于“*”时，代表返回结果是用来做主节点
是否不可达，当leader_runid等于具体的runid，代表目标节点同意runid成为
领导者。
·leader_epoch：领导者纪元。 

9.5.3　领导者Sentinel节点选举
假如Sentinel节点对于主节点已经做了客观下线，那么是不是就可以立
即进行故障转移了？当然不是，实际上故障转移的工作只需要一个Sentinel
节点来完成即可，所以Sentinel节点之间会做一个领导者选举的工作，选出
一个Sentinel节点作为领导者进行故障转移的工作。Redis使用了Raft算法实
现领导者选举，因为Raft算法相对比较抽象和复杂，以及篇幅所限，所以这
里给出一个Redis Sentinel进行领导者选举的大致思路：
1）每个在线的Sentinel节点都有资格成为领导者，当它确认主节点主观
下线时候，会向其他Sentinel节点发送sentinel is-master-down-by-addr命令，
要求将自己设置为领导者。
2）收到命令的Sentinel节点，如果没有同意过其他Sentinel节点的sentinel
is-master-down-by-addr命令，将同意该请求，否则拒绝。
3）如果该Sentinel节点发现自己的票数已经大于等于max（quorum，
num（sentinels）/2+1），那么它将成为领导者。
4）如果此过程没有选举出领导者，将进入下一次选举。
图9-31展示了一次领导者选举的大致过程：
1）s1（sentinel-1）最先完成了客观下线，它会向s2（sentinel-2）和
s3（sentinel-3）发送sentinel is-master-down-by-addr命令，s2和s3同意选其为
领导者。
2）s1此时已经拿到2张投票，满足了大于等于max（quorum，
num（sentinels）/2+1）=2的条件，所以此时s1成为领导者。 

由于每个Sentinel节点只有一票，所以当s2向s1和s3索要投票时，只能获
取一票，而s3由于最后完成主观下线，当s3向s1和s2索要投票时一票都得不
到，整个过程如图9-32和9-33所示。
实际上Redis Sentinel实现会更简单一些，因为一旦有一个Sentinel节点获
得了max（quorum，num（sentinels）/2+1）的票数，其他Sentinel节点再去确
认已经没有意义了，因为每个Sentinel节点只有一票，如果读者有兴趣的
话，可以修改sentinel.c源码，在Sentinel的执行命令列表中添加monitor命令：

struct redisCommand sentinelcmds[] = {
{"monitor",monitorCommand,1,"",0,NULL,0,0,0,0,0},
{"ping",pingCommand,1,"",0,NULL,0,0,0,0,0},
{"sentinel",sentinelCommand,-2,"",0,NULL,0,0,0,0,0},
...
}重新编译部署Redis Sentinel测试环境，在3个Sentinel节点上执行monitor
命令：
1）可以看到sentinel is-master-down-by-addr命令，此命令的执行过程并
没有在Redis的日志中有所体现，monitor监控类似如下命令：
//  因为最后参数是 "*" ，所以此时是 Sentinel 节点之间交换对主节点的失败判定
[0 127.0.0.1:38440] "SENTINEL" "is-master-down-by-addr" "127.0.0.1" "6379" "0" "*"
//  因为最后参数是具体的 runid ，所以此时代表 runid="2f4430bb62c039fb125c5771d7cde2571a7
a5ab4" 的节点希望目标 Sentinel 节点同意自己成为领导者。
[0 127.0.0.1:38440] "SENTINEL" "is-master-down-by-addr" "127.0.0.1" "6379" "1"
"2f4430bb62c039fb125c5771d7cde2571a7a5ab4"
2）选举的过程非常快，基本上谁先完成客观下线，谁就是领导者。
3）一旦Sentinel得到足够的票数，不存在图9-32和图9-33的过程。
注意
有关Raft算法可以参考其GitHub主页https://raft.github.io/。 

 9.5.4　故障转移
领导者选举出的Sentinel节点负责故障转移，具体步骤如下：
1）在从节点列表中选出一个节点作为新的主节点，选择方法如下：
a）过滤：“不健康”（主观下线、断线）、5秒内没有回复过Sentinel节
点ping响应、与主节点失联超过down-after-milliseconds*10秒。
b）选择slave-priority（从节点优先级）最高的从节点列表，如果存在则
返回，不存在则继续。
c）选择复制偏移量最大的从节点（复制的最完整），如果存在则返
回，不存在则继续。
d）选择runid最小的从节点。
整个过程如图9-34所示。

2）Sentinel领导者节点会对第一步选出来的从节点执行slaveof no one命
令让其成为主节点。
3）Sentinel领导者节点会向剩余的从节点发送命令，让它们成为新主节
点的从节点，复制规则和parallel-syncs参数有关。
4）Sentinel节点集合会将原来的主节点更新为从节点，并保持着对其关
注，当其恢复后命令它去复制新的主节点。