前面的多个redis节点，都是一个节点存储一个分片的信息，如果单个节点宕机，会导致这个分片的数据未命中，这就需要实现单个分片的高可用，通过配置多个从节点来backup主节点。另外主从节点之间是没有一个监听者的，主节点宕机后，从节点不会知道自己有上位的机会，redis提供的哨兵就是一个监听者的角色，它可以实现主从的故障转移。
单个分片高可用
实现单个分片高可用，需要实现主从复制，即配置一个主节点，多个从节点，主节点上的数据可以复制到从节点上。redis有一主多从，和多级主从的结构，主从结构不宜复杂，这样会让数据同步的路径更多，会有不稳定的风险。
一主多从，企业常用，一般配置1主6从。
多级主从结构示意。
下面在单台centos服务器中，配置一主两从的结构，实现主从复制。
（1）准备3个redis.conf文件，启动时加载用，里面修改端口号为6382、6383和6384，其他配置参考https://www.cnblogs.com/youngchaolin/p/11983705.html。
# 三个文件以端口号来区分，启动加载时不容易出错
-rw-r--r--. 1 root root 46750 Dec 8 05:05 redis6382.conf -rw-r--r--. 1 root root 46750 Dec 8 05:06 redis6383.conf -rw-r--r--. 1 root root 46750 Dec 8 05:06 redis6384.conf
（2）redis-server redisXXXX.conf来启动三个redis节点，使用info命令选一个来查看信息，发现都是默认自己就是master主节点，并且从节点数为0。
启动redis-server。
[root@node01 /home/software/redis-3.2.11]# redis-server redis6382.conf [root@node01 /home/software/redis-3.2.11]# redis-server redis6383.conf [root@node01 /home/software/redis-3.2.11]# redis-server redis6384.conf [root@node01 /home/software/redis-3.2.11]# ps -ef|grep redis root 8828 1 0 05:09 ? 00:00:00 redis-server *:6382 root 8832 1 0 05:09 ? 00:00:00 redis-server *:6383 root 8836 1 0 05:09 ? 00:00:00 redis-server *:6384 root 8869 5351 0 05:11 pts/1 00:00:00 grep redis You have new mail in /var/spool/mail/root
info replication命令查看节点信息。
# 参考了文末博文
127.0.0.1:6382> info replication # Replication role:master #角色主节点，slave就是从节点 connected_slaves:0 #连接的从节点数为0 master_repl_offset:0 # 主节点复制偏移量 repl_backlog_active:0 #复制积压缓冲区是否开启 repl_backlog_size:1048576 #复制积压缓冲区大小 repl_backlog_first_byte_offset:0 #复制积压缓冲区偏移量大小 repl_backlog_histlen:0 #等于master_repl_offset - repl_backlog_first_byte_offset,该值不会超过repl_backlog_size的大小
（3）将6383和6384的从节点挂接到6382主节点，有两种方式来实现，分为临时和永久两种方式，重启服务后临时方式的主从关系将消失，永久方式的主从启动后就会存在。
a.临时挂接，需要登录到6383和6384的客户端，使用slaveof master的IP master的端口来实现，完成后登录6382来使用info replication继续查看信息。
[root@node01 /home/software/redis-3.2.11]# redis-cli -p 6383
# 临时挂接使用127.0.0.1 127.0.0.1:6383> slaveof 127.0.0.1 6382 OK 127.0.0.1:6383> quit [root@node01 /home/software/redis-3.2.11]# redis-cli -p 6384
# 挂接 127.0.0.1:6384> slaveof 127.0.0.1 6382 OK 127.0.0.1:6384> quit [root@node01 /home/software/redis-3.2.11]# redis-cli -p 6382
# 查看信息，发现发生了变化 127.0.0.1:6382> info replication # Replication role:master # 角色依然为主 connected_slaves:2 # 有两个从节点，下面就是从节点信息 slave0:ip=127.0.0.1,port=6383,state=online,offset=43,lag=0 slave1:ip=127.0.0.1,port=6384,state=online,offset=43,lag=0 master_repl_offset:43 repl_backlog_active:1 repl_backlog_size:1048576 repl_backlog_first_byte_offset:2 repl_backlog_histlen:42
查看从节点信息，其中slave_repl_offset偏移量在主节点宕机后，会作为一个判断的依据，偏移量越大代表从节点上的数据越新，越有可能成为新的主节点。
[root@node01 /home/software/redis-3.2.11]# redis-cli -p 6383 127.0.0.1:6383> info replication # Replication role:slave # 从节点 master_host:127.0.0.1 # master ip master_port:6382 # master 端口 master_link_status:up # 与master的同步状态，up代表连接，down代表断开 master_last_io_seconds_ago:9 # 主节点多少秒没发送数据到从节点 master_sync_in_progress:0 # 主节点是否和从节点在同步 slave_repl_offset:323 # 从节点复制偏移量 slave_priority:100 # 从节点的优先级，默认100，可以修改 slave_read_only:1 # 从节点是否只读，1代表只读，代表只能查看不能删除修改数据 connected_slaves:0 # 连接的从节点个数 master_repl_offset:0 # 主节点复制偏移量 repl_backlog_active:0 # 同上 repl_backlog_size:1048576 # 同上 repl_backlog_first_byte_offset:0 # 同上 repl_backlog_histlen:0 # 同上
b.永久挂接，需要修改从节点redis.conf配置文件，启动服务后，使用上面命令查看，启动redis服务后就是主从关系，重启后依然是主从关系。
# 添加永久配置，这里使用实际的ip，当前centos6.5的ip为192.168.200.140
# slaveof <masterip> <masterport> slaveof 192.168.200.140 6382
（4）主节点写入数据，查看从节点，发现成功的同步了主节点的数据。
# 主节点添加一个hash类型数据
127.0.0.1:6382> hmset messi score 11 assist 10 shoot 5 OK 127.0.0.1:6382> hmget messi score assist shoot 1) "11" 2) "10" 3) "5" 127.0.0.1:6382> quit You have new mail in /var/spool/mail/root
# 6383从节点有复制到数据 [root@node01 /home/software/redis-3.2.11]# redis-cli -p 6383 127.0.0.1:6383> keys * 1) "messi" 127.0.0.1:6383> hmget messi score assist shoot 1) "11" 2) "10" 3) "5" 127.0.0.1:6383> quit
# 6384从节点也有复制到数据 [root@node01 /home/software/redis-3.2.11]# redis-cli -p 6384 127.0.0.1:6384> keys * 1) "messi"
另外从节点默认配置是只读的，想删除上面的数据会报错提示只读，只能从主节点来删除数据。
127.0.0.1:6384> flushdb (error) READONLY You can't write against a read only slave.
从redis2.6开始，配置文件里从节点默认是只读。
哨兵集群故障转移
在上面配置了主从关系后，如果将6382主节点宕机掉，查看从节点信息，发现依然显示是从节点。这样只实现了主从复制，不能实现主从故障转移和替换，即不能实现主节点挂掉，从节点顶上去提供服务的功能，如果使用SharedJedisPool来连接，还需要修改连接的ip和端口，这样会很麻烦。
127.0.0.1:6383> info replication # Replication role:slave # 依然是从节点 master_host:127.0.0.1 master_port:6382 master_link_status:down # 主节点宕机了，从节点依然是从节点 ...省略
这样就需要一个监听者来管理这些节点，redis提供了这样的角色，就是哨兵sentinal，启动哨兵进程后，就可以实现监听管理，以下是它的原理图。
（1）master和slave之间实现主从复制。
（2）哨兵启动后，会连接master，通过10秒一次的频率，会通过向master发送INFO命令来获取master和slave的信息，保存到内存后持久化到sentinal配置文件中。
（3）哨兵(这里只有一个)监听所有的master和slave，会通过每秒一次的PING命令，确认master和slave是否还正常"活着"。
（4）当一个哨兵检测到master宕机后，会被认为是sdown，即subjective down(主观宕机)，当哨兵集群中的大多数(过半)认为master down，才会认为是odown，即objective down(客观宕机，真的宕机)，这个时候就需要投票选举新的master了。
（5）当某个master被判定为主观宕机后，接下来哨兵集群内部会进行选举，也是通过过半机制选举出一个领头哨兵，并由这个领头哨兵来进行主节点的故障转移。
（6）哨兵选举出来后，接下来会从从slave中选取出一个合格的节点来作为新的master，并且其他的slave改为和这个新的master进行复制，原master节点会被设置为新master的slave，当它恢复后会作为slave挂接到新的master上。
（7）领头哨兵选举新的master会经历重重筛选，它会先所有的slave的信息保存到一个列表中。
（8）剔除列表中下线或断线的的slave，保存剩下的salve都是"活的"。
（9）剔除列表中最近5s都没有回复领头哨兵INFO命令的slave，保存剩下的slave都是最近能正常通信的。
（10）剔除和原master断开连接超过down-after-milliseconds*10毫秒的slave，这个值默认是30s，这样剔除的作用的是保证剩下的slave都是最近和原master有连接的，相比很早断开连接的salve，这些slave上的数据会更具有时效性。
# 这个时间配置在sentinel.conf文件中
# sentinel down-after-milliseconds <master-name> <milliseconds> # # Number of milliseconds the master (or any attached slave or sentinel) should # be unreachable (as in, not acceptable reply to PING, continuously, for the # specified period) in order to consider it in S_DOWN state (Subjectively # Down). # # Default is 30 seconds.
（11）通过优先级的大小对剩下的slave进行排序，优先级最高的slave获取到继续选举的权利。
（12）如果剩下的slave优先级相同的有多个，会继续比较slave_repl_offset，即复制偏移量，会选出复制偏移量最大的slave，偏移量越大代表从原master复制到的数据更具时效性。
（13）如果剩下的slave优先级最高，复制偏移量最大的有多个，会继续比较运行ID，选出运行ID最小的slave作为新的master。
（14）当新的master选举出来后，领头哨兵会给它发送SLAVEOF no one命令，即不会让它成为任何一个节点的slave。并按照每秒1次的高频率来给它发送INFO命令，如果返回的role信息为master，则领头哨兵才会放心的认为已经选举出新的master了。
配置哨兵集群
下面在上面主从复制功能的基础上，添加哨兵集群、实现对一个分片的高可用 。
（1）准备sentinal.conf文件，修改端口号，保护模式设置为no，并设置监听的主节点。
# 先准备三份配置文件
[root@node01 /home/software/redis-3.2.11]# cp sentinel.conf sentinel26379.conf [root@node01 /home/software/redis-3.2.11]# cp sentinel.conf sentinel26380.conf [root@node01 /home/software/redis-3.2.11]# cp sentinel.conf sentinel26381.conf
以26379的哨兵为例，除了修改保护模式为no，端口号修改为对应端口号外，还需要配置监听主节点逻辑，其中监听主节点配置各个字段的解释：
sentinal monitor：代表这个参数的key；
mymaster：代表master的代号；
ip：master的ip；
redis-port：master的端口号，这里的初始主节点是6382；
quorum：主观投票下限次数，如果是3个哨兵集群，则是2，如果是5个哨兵集群，则是3，采取过半机制
# 保护模式设置为no
protected-mode no # 端口号，三个文件分别修改为26379、26380、26381 # port <sentinel-port> # The port that this sentinel instance will run on port 26379 # 配置监听主节点 # sentinel monitor <master-name> <ip> <redis-port> <quorum>
# ip写主机的实际ip，写127.0.0.1后面使用api会连不上 sentinel monitor mymaster 192.168.200.140 6382 2
（2）在master和slave都启动的情况下，启动一个哨兵，观察控制台情况。发现哨兵启动后，就通过master，获取到了两个salve的信息，这是因为调用了info命令。
[root@node01 /home/software/redis-3.2.11]# redis-sentinel sentinel26379.conf 1680:X 09 Dec 13:10:11.322 * Increased maximum number of open files to 10032 (it was originally set to 1024). _._ _.-``__ ''-._ _.-`` `. `_. ''-._ Redis 3.2.11 (00000000/0) 64 bit .-`` .-```. ```/ _.,_ ''-._ ( ' , .-` | `, ) Running in sentinel mode |`-._`-...-` __...-.``-._|'` _.-'| Port: 26379 | `-._ `._ / _.-' | PID: 1680 `-._ `-._ `-./ _.-' _.-' |`-._`-._ `-.__.-' _.-'_.-'| | `-._`-._ _.-'_.-' | http://redis.io `-._ `-._`-.__.-'_.-' _.-' |`-._`-._ `-.__.-' _.-'_.-'| | `-._`-._ _.-'_.-' | `-._ `-._`-.__.-'_.-' _.-' `-._ `-.__.-' _.-' `-._ _.-' `-.__.-' 1680:X 09 Dec 13:10:11.324 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.
# 生成的myid会持久化到配置文件中
1680:X 09 Dec 13:10:11.326 # Sentinel ID is 6d9373993f231a33686485a7e3baf205ff98d7b7
# 监听6382的节点 1680:X 09 Dec 13:10:11.326 # +monitor master mymaster 192.168.200.140 6382 quorum 2
# 通过6382 master主节点调用info命令获取到slave节点的信息 1680:X 09 Dec 13:10:11.326 * +slave slave 192.168.200.140:6383 192.168.200.140 6383 @ mymaster 192.168.200.140 6382 1680:X 09 Dec 13:10:11.329 * +slave slave 192.168.200.140:6384 192.168.200.140 6384 @ mymaster 192.168.200.140 6382
配置文件中新增myid
（3）开启另外两个哨兵，发现启动后，26379启动的控制台里会添加提示获取到其它两台的哨兵的信息，其它两台也是如此。
26379的关于哨兵的日志
# 发现了26380和26381
1931:X 09 Dec 13:25:48.461 * +sentinel sentinel 931e5386f5d0e31a70cc14a5aa418d68fb46feb4 192.168.200.140 26380 @ mymaster 192.168.200.140 6382 1931:X 09 Dec 13:25:55.809 * +sentinel sentinel 2b402bba6fde9ba010a8f7cd9b2106356aad17cc 192.168.200.140 26381 @ mymaster 192.168.200.140 6382
26380的部分日志
1934:X 09 Dec 13:25:46.323 # Sentinel ID is 931e5386f5d0e31a70cc14a5aa418d68fb46feb4 1934:X 09 Dec 13:25:46.323 # +monitor master mymaster 192.168.200.140 6382 quorum 2 1934:X 09 Dec 13:25:46.323 * +slave slave 192.168.200.140:6384 192.168.200.140 6384 @ mymaster 192.168.200.140 6382 1934:X 09 Dec 13:25:46.324 * +slave slave 192.168.200.140:6383 192.168.200.140 6383 @ mymaster 192.168.200.140 6382
# 发现26379和26381 1934:X 09 Dec 13:25:46.975 * +sentinel sentinel 6d9373993f231a33686485a7e3baf205ff98d7b7 192.168.200.140 26379 @ mymaster 192.168.200.140 6382 1934:X 09 Dec 13:25:55.809 * +sentinel sentinel 2b402bba6fde9ba010a8f7cd9b2106356aad17cc 192.168.200.140 26381 @ mymaster 192.168.200.140 6382
26381的部分日志
1937:X 09 Dec 13:25:53.763 # Sentinel ID is 2b402bba6fde9ba010a8f7cd9b2106356aad17cc 1937:X 09 Dec 13:25:53.763 # +monitor master mymaster 192.168.200.140 6382 quorum 2 1937:X 09 Dec 13:25:53.765 * +slave slave 192.168.200.140:6384 192.168.200.140 6384 @ mymaster 192.168.200.140 6382 1937:X 09 Dec 13:25:53.767 * +slave slave 192.168.200.140:6383 192.168.200.140 6383 @ mymaster 192.168.200.140 6382
# 发现26379和26380 1937:X 09 Dec 13:25:54.715 * +sentinel sentinel 931e5386f5d0e31a70cc14a5aa418d68fb46feb4 192.168.200.140 26380 @ mymaster 192.168.200.140 6382 1937:X 09 Dec 13:25:55.159 * +sentinel sentinel 6d9373993f231a33686485a7e3baf205ff98d7b7 192.168.200.140 26379 @ mymaster 192.168.200.140 6382
可以看到哨兵通过连接主节点6382，获取到了从节点的信息，并且还获取到其它哨兵的信息，获取到的信息会持久化到配置文件中，添加到文件尾部，以26379为例。
（4）将6382主节点宕机，观察每个哨兵控制台情况。
26379的部分日志
# 26379判断6382主观宕机
1931:X 09 Dec 13:32:56.471 # +sdown master mymaster 192.168.200.140 6382
# new-epoch 1，1代表逻辑时钟值，类似zookeeper的epoch，是自增的整数，使用一个计数器来实现。 1931:X 09 Dec 13:32:56.595 # +new-epoch 1
# 选举领头哨兵，选举了尾部为feb4的哨兵，即26380端口号的哨兵 1931:X 09 Dec 13:32:56.596 # +vote-for-leader 931e5386f5d0e31a70cc14a5aa418d68fb46feb4 1 1931:X 09 Dec 13:32:56.934 # +config-update-from sentinel 931e5386f5d0e31a70cc14a5aa418d68fb46feb4 192.168.200.140 26380 @ mymaster 192.168.200.140 6382
# 切换master，6382到6384，这个时候已经选举出新的master 1931:X 09 Dec 13:32:56.934 # +switch-master mymaster 192.168.200.140 6382 192.168.200.140 6384
# 6382和6383变成slave，6384变成master 1931:X 09 Dec 13:32:56.934 * +slave slave 192.168.200.140:6383 192.168.200.140 6383 @ mymaster 192.168.200.140 6384 1931:X 09 Dec 13:32:56.934 * +slave slave 192.168.200.140:6382 192.168.200.140 6382 @ mymaster 192.168.200.140 6384
# 判断6382主观宕机 1931:X 09 Dec 13:33:26.983 # +sdown slave 192.168.200.140:6382 192.168.200.140 6382 @ mymaster 192.168.200.140 6384
26380的部分日志
# 判断6382主观宕机
1934:X 09 Dec 13:32:56.490 # +sdown master mymaster 192.168.200.140 6382
# 有过半的哨兵判断6382主观宕机，状态变成客观宕机odown 1934:X 09 Dec 13:32:56.591 # +odown master mymaster 192.168.200.140 6382 #quorum 2/2
# 进入新的纪元 1934:X 09 Dec 13:32:56.591 # +new-epoch 1
# 尝试故障转移 1934:X 09 Dec 13:32:56.591 # +try-failover master mymaster 192.168.200.140 6382
# 选举尾部为feb4的哨兵为领头哨兵，即选举自己 1934:X 09 Dec 13:32:56.593 # +vote-for-leader 931e5386f5d0e31a70cc14a5aa418d68fb46feb4 1
# 有过半选举26380的哨兵为领头哨兵，则领头哨兵开始进行master筛选。 1934:X 09 Dec 13:32:56.596 # 2b402bba6fde9ba010a8f7cd9b2106356aad17cc voted for 931e5386f5d0e31a70cc14a5aa418d68fb46feb4 1 1934:X 09 Dec 13:32:56.596 # 6d9373993f231a33686485a7e3baf205ff98d7b7 voted for 931e5386f5d0e31a70cc14a5aa418d68fb46feb4 1 1934:X 09 Dec 13:32:56.669 # +elected-leader master mymaster 192.168.200.140 6382 1934:X 09 Dec 13:32:56.669 # +failover-state-select-slave master mymaster 192.168.200.140 6382 1934:X 09 Dec 13:32:56.728 # +selected-slave slave 192.168.200.140:6384 192.168.200.140 6384 @ mymaster 192.168.200.140 6382 1934:X 09 Dec 13:32:56.728 * +failover-state-send-slaveof-noone slave 192.168.200.140:6384 192.168.200.140 6384 @ mymaster 192.168.200.140 6382 1934:X 09 Dec 13:32:56.787 * +failover-state-wait-promotion slave 192.168.200.140:6384 192.168.200.140 6384 @ mymaster 192.168.200.140 6382 1934:X 09 Dec 13:32:56.885 # +promoted-slave slave 192.168.200.140:6384 192.168.200.140 6384 @ mymaster 192.168.200.140 6382 1934:X 09 Dec 13:32:56.885 # +failover-state-reconf-slaves master mymaster 192.168.200.140 6382 1934:X 09 Dec 13:32:56.934 * +slave-reconf-sent slave 192.168.200.140:6383 192.168.200.140 6383 @ mymaster 192.168.200.140 6382 1934:X 09 Dec 13:32:57.739 # -odown master mymaster 192.168.200.140 6382 1934:X 09 Dec 13:32:57.951 * +slave-reconf-inprog slave 192.168.200.140:6383 192.168.200.140 6383 @ mymaster 192.168.200.140 6382 1934:X 09 Dec 13:32:57.951 * +slave-reconf-done slave 192.168.200.140:6383 192.168.200.140 6383 @ mymaster 192.168.200.140 6382 1934:X 09 Dec 13:32:58.042 # +failover-end master mymaster 192.168.200.140 6382
# 将6382成功切换为6384 1934:X 09 Dec 13:32:58.042 # +switch-master mymaster 192.168.200.140 6382 192.168.200.140 6384
# 将slave挂接到新的master上，并且将原master 6382变成了从节点slave 1934:X 09 Dec 13:32:58.042 * +slave slave 192.168.200.140:6383 192.168.200.140 6383 @ mymaster 192.168.200.140 6384 1934:X 09 Dec 13:32:58.042 * +slave slave 192.168.200.140:6382 192.168.200.140 6382 @ mymaster 192.168.200.140 6384
# 6382还没有恢复，认定为主观宕机
1934:X 09 Dec 13:33:28.092 # +sdown slave 192.168.200.140:6382 192.168.200.140 6382 @ mymaster 192.168.200.140 6384
26381的部分日志
1937:X 09 Dec 13:32:56.563 # +sdown master mymaster 192.168.200.140 6382 1937:X 09 Dec 13:32:56.595 # +new-epoch 1
# 选举领头哨兵，本次选举三个哨兵都是选择26380 1937:X 09 Dec 13:32:56.596 # +vote-for-leader 931e5386f5d0e31a70cc14a5aa418d68fb46feb4 1
# 过半认为6382宕机，则判定原master6382客观宕机 1937:X 09 Dec 13:32:56.639 # +odown master mymaster 192.168.200.140 6382 #quorum 3/2 1937:X 09 Dec 13:32:56.639 # Next failover delay: I will not start a failover before Mon Dec 9 13:38:56 2019 1937:X 09 Dec 13:32:56.935 # +config-update-from sentinel 931e5386f5d0e31a70cc14a5aa418d68fb46feb4 192.168.200.140 26380 @ mymaster 192.168.200.140 6382 1937:X 09 Dec 13:32:56.935 # +switch-master mymaster 192.168.200.140 6382 192.168.200.140 6384 1937:X 09 Dec 13:32:56.935 * +slave slave 192.168.200.140:6383 192.168.200.140 6383 @ mymaster 192.168.200.140 6384 1937:X 09 Dec 13:32:56.935 * +slave slave 192.168.200.140:6382 192.168.200.140 6382 @ mymaster 192.168.200.140 6384 1937:X 09 Dec 13:33:26.968 # +sdown slave 192.168.200.140:6382 192.168.200.140 6382 @ mymaster 192.168.200.140 6384
发现master从6382换成了6384，目前有6383一个从节点。
[root@node01 /home/software/redis-3.2.11]# redis-cli -p 6384 127.0.0.1:6384> info replication # Replication role:master connected_slaves:1 slave0:ip=192.168.200.140,port=6383,state=online,offset=26451,lag=0 master_repl_offset:26741 repl_backlog_active:1 repl_backlog_size:1048576 repl_backlog_first_byte_offset:2 repl_backlog_histlen:26740
（5）将6382节点恢复，发现它会作为从节点挂接到新的主节点6384上。
1931:X 09 Dec 13:36:10.239 * +convert-to-slave slave 192.168.200.140:6382 192.168.200.140 6382 @ mymaster 192.168.200.140 6384
继续登录6384，发现6382变成了salve。
[root@node01 /home/software/redis-3.2.11]# redis-cli -p 6384 127.0.0.1:6384> info replication # Replication role:master connected_slaves:2 slave0:ip=192.168.200.140,port=6383,state=online,offset=49089,lag=1 slave1:ip=192.168.200.140,port=6382,state=online,offset=49234,lag=0 master_repl_offset:49234 repl_backlog_active:1 repl_backlog_size:1048576 repl_backlog_first_byte_offset:2 repl_backlog_histlen:49233
哨兵API的操作
有了哨兵了，可以通过连接JedisSentinelPool，来连接哨兵集群，然后通过它来获取到Jedis实例对象，这个对象就是对外提供服务的master节点。
package com.boe; import java.util.HashSet; import java.util.Set; import org.junit.Test; import redis.clients.jedis.HostAndPort; import redis.clients.jedis.Jedis; import redis.clients.jedis.JedisSentinelPool; public class SentinelTest { @Test public void sentinel(){ //多个哨兵之间没有监控关系，顺序遍历，哪个能通就走哪个，不通，再检查下一个哨兵 Set<String> sentinels = new HashSet<String>(); sentinels.add(new HostAndPort("192.168.200.140",26379).toString()); sentinels.add(new HostAndPort("192.168.200.140",26380).toString()); sentinels.add(new HostAndPort("192.168.200.140",26381).toString()); JedisSentinelPool pool = new JedisSentinelPool("mymaster", sentinels); //这一句很有用，能获取到是否有master节点宕机 System.out.println("当前master：" + pool.getCurrentHostMaster()); //通过哨兵获取 jedis 连接的就是master Jedis jedis = pool.getResource(); //jedis.auth("123456"); jedis.set("name", "messi"); System.out.println(jedis.get("name")); } }
现在master节点是6384，它不宕机的情况下，是可以对外提供服务的。
查看redis，数据三个节点均有。
127.0.0.1:6384> get name "messi"
现在把6384给它宕机，继续使用上述哨兵来连接 ，修改代码，将set的key-value做修改，然后尝试连接，发现master变成了6382。
哨兵日志
1931:X 09 Dec 13:40:21.218 # +sdown master mymaster 192.168.200.140 6384
# 6384宕机，又会新一轮的选举，纪元为2 1931:X 09 Dec 13:40:21.302 # +new-epoch 2 1931:X 09 Dec 13:40:21.320 # +vote-for-leader 931e5386f5d0e31a70cc14a5aa418d68fb46feb4 2 1931:X 09 Dec 13:40:21.948 # +config-update-from sentinel 931e5386f5d0e31a70cc14a5aa418d68fb46feb4 192.168.200.140 26380 @ mymaster 192.168.200.140 6384
# 6382成为新的master，6384又变成了slave
1931:X 09 Dec 13:40:21.948 # +switch-master mymaster 192.168.200.140 6384 192.168.200.140 6382 1931:X 09 Dec 13:40:21.948 * +slave slave 192.168.200.140:6383 192.168.200.140 6383 @ mymaster 192.168.200.140 6382 1931:X 09 Dec 13:40:21.948 * +slave slave 192.168.200.140:6384 192.168.200.140 6384 @ mymaster 192.168.200.140 6382 1931:X 09 Dec 13:40:52.013 # +sdown slave 192.168.200.140:6384 192.168.200.140 6384 @ mymaster 192.168.200.140 6382
以上是对分片高可用，以及哨兵集群及故障转移的整理，记录一下后续查看用，后面继续补充redis-cluster的相关内容。
参考博文
（1）https://blog.csdn.net/mysqldba23/article/details/68066322 info replication详解
（2）https://www.cnblogs.com/fu-yong/p/9252837.html 哨兵
（3）https://blog.csdn.net/u012240455/article/details/81843714 哨兵
（4）《redis设计与实践》主节点故障转移