基本概念
主从复制的优缺点:
优点:
- 第一，作为主节点的一个备份，一旦主节点出了故障不可达的情况，从节点可以作为后备“顶”上来，并且保证数据尽量不丢
失（主从复制是最终一致性）。 - 第二，从节点可以扩展主节点的读能力，一旦主节点不能支撑住大并发量的读操作，从节点可以在一定程度上帮助主节点分担读压力。
缺点:
- 第一，一旦主节点出现故障，需要手动将一个从节点晋升为主节点，同时需要修改应用方的主节点地址，还需要命令其他从节点去复制新的主节点，整个过程都需要人工干预。
- 第二，主节点的写能力受到单机的限制。
- 第三，主节点的存储能力受到单机的限制。
当主节点出现故障时，Redis Sentinel能自动完成故障发现和故障转移，并通知应用方，从而实现真正的高可用。
Redis Sentinel功能:
- 监控：Sentinel节点会定期检测Redis数据节点、其余Sentinel节点是否可达。
- 通知：Sentinel节点会将故障转移的结果通知给应用方。
- 主节点故障转移：实现从节点晋升为主节点并维护后续正确的主从关系。
- 配置提供者：在Redis Sentinel结构中，客户端在初始化的时候连接的是Sentinel节点集合，从中获取主节点信息。
安装和部署
- 部署Redis数据节点
1.启动主节点
配置：
redis-6379.conf
port 6379
daemonize yes
logfile "6379.log"
dbfilename "dump-6379.rdb"
dir "/opt/soft/redis/data/"
启动主节点：
redis-server redis-6379.conf
确认是否启动:
$ redis-cli -h 127.0.0.1 -p 6379 ping
2.启动两个从节点
配置：
redis-6380.conf
port 6380
daemonize yes
logfile "6380.log"
dbfilename "dump-6380.rdb"
dir "/opt/soft/redis/data/"
slaveof 127.0.0.1 6379
启动两个从节点：:
redis-server redis-6380.conf
redis-server redis-6381.conf
验证：
$ redis-cli -h 127.0.0.1 -p 6380 ping
PONG
$ redis-cli -h 127.0.0.1 -p 6381 ping
PONG
3.确认主从关系
$ redis-cli -h 127.0.0.1 -p 6379 info replication
- 部署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
1）Sentinel节点的默认端口是26379。
2）sentinel monitor mymaster127.0.0.163792配置代表sentinel-1节点需要监控127.0.0.1：6379这个主节点，2代表判断主节点失败至少需要2个Sentinel节点同意，mymaster是主节点的别名。
2.启动Sentinel节点
方法一，使用redis-sentinel命令：
redis-sentinel redis-sentinel-26379.conf
方法二，使用redis-server命令加--sentinel参数：
redis-server redis-sentinel-26379.conf --sentinel
3.确认
$ 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
Redis Sentinel最终拓扑结构
- 配置优化
Redis安装目录下有一个sentinel.conf，是默认的Sentinel节点配置文件
1.配置说明和优化
port 26379
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 auth-pass <master-name> <password>
#sentinel notification-script <master-name> <script-path>
#sentinel client-reconfig-script <master-name> <script-path>
（1）sentinel monitor
sentinel monitor <master-name> <ip> <port> <quorum>
Sentinel节点要监控的是一个名字叫做<master-name>，ip地址和端口为<ip><port>的主节点。<quorum>代表要判定主节点最终不可达所需要的票数。
（2）sentinel down-after-milliseconds
sentinel down-after-milliseconds <master-name> <times>
每个Sentinel节点都要通过定期发送ping命令来判断Redis数据节点和其余Sentinel节点是否可达，如果超过了down-after-milliseconds配置的时间且没有有效的回复，则判定节点不可达，<times>（单位为毫秒）就是超时时间。这个配置是对节点失败判定的重要依据。
（3）sentinel parallel-syncs
sentinel parallel-syncs <master-name> <nums>
parallel-syncs就是用来限制在一次故障转移之后，每次向新的主节点发起复制操作的从节点个数。
（4）sentinel failover-timeout
sentinel failover-timeout <master-name> <times>
failover-timeout通常被解释成故障转移超时时间，但实际上它作用于故障转移的各个阶段：
a）选出合适从节点。
b）晋升选出的从节点为主节点。
c）命令其余从节点复制新的主节点。
d）等待原主节点恢复后命令它去复制新的主节点。
（5）sentinel auth-pass
sentinel auth-pass <master-name> <password>
如果Sentinel监控的主节点配置了密码，sentinel auth-pass配置通过添加主节点的密码，防止Sentinel节点对主节点无法监控。
（6）sentinel notification-script
sentinel notification-script <master-name> <script-path>
sentinel notification-script的作用是在故障转移期间，当一些警告级别的Sentinel事件发生（指重要事件，例如-sdown：客观下线、-odown：主观下线）时，会触发对应路径的脚本，并向脚本发送相应的事件参数。
sentinel notification-script mymaster /opt/redis/scripts/notification.sh
（7）sentinel client-reconfig-script
sentinel client-reconfig-script <master-name> <script-path>
sentinel client-reconfig-script的作用是在故障转移结束后，会触发对应路径的脚本，并向脚本发送故障转移结果的相关参数,具体参数如下：
<master-name> <role> <state> <from-ip> <from-port> <to-ip> <to-port>
mymaster leader start 127.0.0.1 6379 127.0.0.1 6380
mymaster observer start 127.0.0.1 6379 127.0.0.1 6380
mymaster observer start 127.0.0.1 6379 127.0.0.1 6380
如何监控多个主节点
Redis Sentinel监控多个主节点
sentinel monitor master-business-1 10.10.xx.1 6379 2
sentinel down-after-milliseconds master-business-1 60000
sentinel failover-timeout master-business-1 180000
sentinel parallel-syncs master-business-1 1
sentinel monitor master-business-2 10.16.xx.2 6380 2
sentinel down-after-milliseconds master-business-2 10000
sentinel failover-timeout master-business-2 180000
sentinel parallel-syncs master-business-2 1
动态调整配置
sentinel set <param> <value>
sentinel set命令如果执行成功会立即刷新配置文件，这点和Redis普通数据节点设置配置需要执行config rewrite刷新到配置文件不同。
部署技巧
1）Sentinel节点不应该部署在一台物理“机器”上。
2）部署至少三个且奇数个的Sentinel节点。(提高对于故障判定的准确性)
3）只有一套Sentinel，还是每个主节点配置一套Sentinel？
API
1.sentinel masters 展示所有被监控的主节点状态以及相关的统计信息
2.sentinel master<master name> 展示指定<master name>的主节点状态以及相关的统计信息
3.sentinel slaves<master name> 展示指定<master name>的从节点状态以及相关的统计信息
4.sentinel sentinels<master name> 展示指定<master name>的Sentinel节点集合
5.sentinel get-master-addr-by-name<master name> 返回指定<master name>主节点的IP地址和端口
6.sentinel reset<pattern> 当前Sentinel节点对符合<pattern>（通配符风格）主节点的配置进行重置，包含清除主节点的相关状态（例如故障转移），重新发现从节点和Sentinel节点。
7.sentinel failover<master name> 对指定<master name>主节点进行强制故障转移（没有和其他Sentinel节点“协商”）
8.sentinel ckquorum<master name> 检测当前可达的Sentinel节点总数是否达到<quorum>的个数。
9.sentinel flushconfig 将Sentinel节点的配置强制刷到磁盘上
10.sentinel remove<master name> 取消当前Sentinel节点对于指定<master name>主节点的监控。
11.sentinel monitor<master name><ip><port><quorum> 命令的形式来完成Sentinel节点对主节点的监控。
12.sentinel set<master name> 动态修改Sentinel节点配置选项
13.sentinel is-master-down-by-addr Sentinel节点之间用来交换对主节点是否下线的判断
客户端连接
- Redis Sentinel客户端基本实现原理
1）遍历Sentinel节点集合获取一个可用的Sentinel节点
2）通过sentinel get-master-addr-by-name master-name这个API来获取对应主节点的相关信息
3）验证当前获取的“主节点”是真正的主节点，这样做的目的是为了防止故障转移期间主节点的变化
4）保持和Sentinel节点集合的“联系”，时刻获取关于主节点的相关“信息”
- Java操作Redis Sentinel
public JedisSentinelPool(String masterName, Set<String> 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——客户端名。
- 客户端核心代码
private HostAndPort initSentinels(Set<String> 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<String> 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）每隔10秒，每个Sentinel节点会向主节点和从节点发送info命令获取最新的拓扑结构
Sentinel节点定时执行info命令
2）每隔2秒，每个Sentinel节点会向Redis数据节点的sentinel：hello频道上发送该Sentinel节点对于主节点的判断以及当前Sentinel节点的信息，同时每个Sentinel节点也会订阅该频道，来了解其他Sentinel节点以及它们对主节点的判断
3）每隔1秒，每个Sentinel节点会向主节点、从节点、其余Sentinel节点发送一条ping命令做一次心跳检测，来确认这些节点当前是否可达。 - 主观下线和客观下线
1.主观下线
每个Sentinel节点会每隔1秒对主节点、从节点、其他Sentinel节点发送ping命令做心跳检测，当这些节点超过down-after-milliseconds没有进行有效回复，Sentinel节点就会对该节点做失败判定，这个行为叫做主观下线。
2.客观下线
大部分Sentinel节点都对主节点的下线做了同意的判定，那么这个判定就是客观的 - 领导者Sentinel节点选举(Raft算法)
1）每个在线的Sentinel节点都有资格成为领导者，当它确认主节点主观下线时候，会向其他Sentinel节点发送sentinel is-master-down-by-addr命令，要求将自己设置为领导者。
2）收到命令的Sentinel节点，如果没有同意过其他Sentinel节点的sentinelis-master-down-by-addr命令，将同意该请求，否则拒绝。
3）如果该Sentinel节点发现自己的票数已经大于等于max（quorum，num（sentinels）/2+1），那么它将成为领导者。
4）如果此过程没有选举出领导者，将进入下一次选举。 - 故障转移(领导者选举出的Sentinel节点负责故障转移)
1）在从节点列表中选出一个节点作为新的主节点
a）过滤：“不健康”（主观下线、断线）、5秒内没有回复过Sentinel节点ping响应、与主节点失联超过down-after-milliseconds*10秒。
b）选择slave-priority（从节点优先级）最高的从节点列表，如果存在则返回，不存在则继续。
c）选择复制偏移量最大的从节点（复制的最完整），如果存在则返回，不存在则继续。
d）选择runid最小的从节点。
选出最好的从节点
2）Sentinel领导者节点会对第一步选出来的从节点执行slaveof no one命令让其成为主节点。
3）Sentinel领导者节点会向剩余的从节点发送命令，让它们成为新主节点的从节点，复制规则和parallel-syncs参数有关。
4）Sentinel节点集合会将原来的主节点更新为从节点，并保持着对其关注，当其恢复后命令它去复制新的主节点。
高可用读写分离
1.从节点的作用
第一，当主节点出现故障时，作为主节点的后备“顶”上来实现故障转移，Redis Sentinel已经实现了该功能的自动化，实现了真正的高可用。第二，扩展主节点的读能力，尤其是在读多写少的场景非常适用
2.Redis Sentinel读写分离设计思路
·+switch-master：切换主节点（原来的从节点晋升为主节点），说明减少了某个从节点。
·+convert-to-slave：切换从节点（原来的主节点降级为从节点），说明添加了某个从节点。
·+sdown：主观下线，说明可能某个从节点可能不可用（因为对从节点不会做客观下线），所以在实现客户端时可以采用自身策略来实现类似主观下线的功能。
·+reboot：重新启动了某个节点，如果它的角色是slave，那么说明添加了某个从节点。
Redis Sentinel下的读写分离架构图
总结
1）Redis Sentinel是Redis的高可用实现方案：故障发现、故障自动转移、配置中心、客户端通知。
2）Redis Sentinel从Redis2.8版本开始才正式生产可用，之前版本生产不可用。
3）尽可能在不同物理机上部署Redis Sentinel所有节点。
4）Redis Sentinel中的Sentinel节点个数应该为大于等于3且最好为奇数。
5）Redis Sentinel中的数据节点与普通数据节点没有区别。
6）客户端初始化时连接的是Sentinel节点集合，不再是具体的Redis节点，但Sentinel只是配置中心不是代理。
7）Redis Sentinel通过三个定时任务实现了Sentinel节点对于主节点、从节点、其余Sentinel节点的监控。
8）Redis Sentinel在对节点做失败判定时分为主观下线和客观下线。
9）看懂Redis Sentinel故障转移日志对于Redis Sentnel以及问题排查非常有帮助。
10）Redis Sentinel实现读写分离高可用可以依赖Sentinel节点的消息通知，获取Redis数据节点的状态变化。
