redis高可用sentinel集群搭建

哨兵机制，它基于 Redis 主从复制，主要作用便是解决主节点故障恢复的自动化问题，进一步提高系统的高可用性。

哨兵的架构

它由两部分组成，哨兵节点和数据节点：
哨兵节点：哨兵系统由一个或多个哨兵节点组成，哨兵节点是特殊的 Redis 节点，不存储数据。
数据节点：主节点和从节点都是数据节点。

获取redis
wget http://download.redis.io/releases/redis-3.2.12.tar.gz
解压 、编译

配置一个简单的redis sentinel 集群，一个主节点 两个从节点，和3个哨兵节点。

主从复制配置
#主redis-6380.conf

port 6380
#打开守护线程 后台运行
daemonize yes
logfile “6380.log”
dbfilename “dump-6380.rdb”
#注意 bind要开启 可以指定ip 也可以设置0.0.0.0

#从节点 redis-6381.conf

port 6381
#打开守护线程 后台运行
daemonize yes
logfile “6381.log”
dbfilename “dump-6381.rdb”
#设置主节点的ip和端口
slaveof 127.0.0.1 6380
#注意 bind要开启 可以指定ip 也可以设置0.0.0.0

#从节点 redis-6382.conf

port 6382
#打开守护线程 后台运行
daemonize yes
logfile “6382.log”
dbfilename “dump-6382.rdb”
#设置主节点的ip和端口
slaveof 127.0.0.1 6380
#注意 bind要开启 可以指定ip 也可以设置0.0.0.0

配置完成后再依次启动redis服务

./redis-3.2.12/src/redis-server redis-6380.conf
./redis-3.2.12/src/redis-server redis-6381.conf
./redis-3.2.12/src/redis-server redis-6382.conf

启动完成之后 我们可以通过客户端的工具查看一下配置主从节点的信息
./redis-3.2.12/src/redis-cli -p 6380
#查看主从复制信息
info Replication

上图显示 连接的slave 节点有两个，并可以清楚的查看slave信息。

哨兵节点的配置

哨兵节点本质是特殊的节点，不存储任何数据，只是负责监控数据节点。而哨兵节点的配置也是很简单的，区别在于端口修改。
配置哨兵
#sentinel-26380.conf

#sentinel-26381.conf

#sentinel-26382.conf

配置完成后，启动哨兵节点。

./redis-3.2.12/src/redis-sentinel sentinel-26380.conf
./redis-3.2.12/src/redis-sentinel sentinel-26381.conf
./redis-3.2.12/src/redis-sentinel sentinel-26382.conf
也可以通过redis-server启动 加上 --sentinel参数
./redis-3.2.12/src/redis-server sentinel-26382.conf --sentinel
启动完成之后，我们可以通过redis的客户端工具连接查看一下。
#使用 info Sentinel 命令查看

slaves 表示有两个从节点，sentinel 表示有3个哨兵正在运行的状态。

启动完成之后 我们可以通过命令查看sentinel的配置文件
#cat sentinel-26380.conf

测试故障转移

我们看到现在的主节点是6381 ，直接结束6381端口的进程 kill -9 1502

在查看主节点的信息

发现主节点的信息已经切换到了6382上，在故障转移切换的时候，会自动的修改配置文件

优先将第一位的推选为主节点。
哨兵会登陆到6382的服务中，并修改 为主节点 ，命令为 slaveof no one，再登陆到其他服务中修改为从节点，执行的命令为 slaveof 127.0.0.1 6382

哨兵配置

sentinel monitor {masterName} {masterIp} {masterPort}{quorum}
sentinel monitor 是哨兵最核心的配置，在前文讲述部署哨兵节点时已说明，其中：masterName 指定了主节点名称，masterIp 和 masterPort 指定了主节点地址，quorum 是判断主节点客观下线的哨兵数量阈值。
当判定主节点下线的哨兵数量达到 quorum 时，对主节点进行客观下线。建议取值为哨兵数量的一半加 1。

sentinel down-after-milliseconds {masterName} {time}
sentinel down-after-milliseconds 与主观下线的判断有关：哨兵使用 ping 命令对其他节点进行心跳检测。如果其他节点超过 down-after-milliseconds 配置的时间没有回复，哨兵就会将其进行主观下线，该配置对主节点、从节点和哨兵节点的主观下线判定都有效。
down-after-milliseconds 的默认值是 30000，即 30s；可以根据不同的网络环境和应用要求来调整。
值越大，对主观下线的判定会越宽松，好处是误判的可能性小，坏处是故障发现和故障转移的时间变长，客户端等待的时间也会变长。
例如，如果应用对可用性要求较高，则可以将值适当调小，当故障发生时尽快完成转移；如果网络环境相对较差，可以适当提高该阈值，避免频繁误判。

sentinel parallel-syncs {masterName} {number}
sentinel parallel-syncs 与故障转移之后从节点的复制有关：它规定了每次向新的主节点发起复制操作的从节点个数。
例如，假设主节点切换完成之后，有 3 个从节点要向新的主节点发起复制；如果 parallel-syncs=1，则从节点会一个一个开始复制；如果 parallel-syncs=3，则 3 个从节点会一起开始复制。

parallel-syncs 取值越大，从节点完成复制的时间越快，但是对主节点的网络负载、硬盘负载造成的压力也越大；应根据实际情况设置。
例如，如果主节点的负载较低，而从节点对服务可用的要求较高，可以适量增加 parallel-syncs 取值。parallel-syncs 的默认值是 1。

sentinel failover-timeout {masterName} {time}
sentinel failover-timeout 与故障转移超时的判断有关，但是该参数不是用来判断整个故障转移阶段的超时，而是其几个子阶段的超时。
例如如果主节点晋升从节点时间超过 timeout，或从节点向新的主节点发起复制操作的时间(不包括复制数据的时间)超过 timeout，都会导致故障转移超时失败。

failover-timeout 的默认值是 180000，即 180s；如果超时，则下一次该值会变为原来的 2 倍。

通过这些命令，可以查询哨兵系统的拓扑结构、节点信息、配置信息等：
info sentinel：获取监控的所有主节点的基本信息。
sentinel masters：获取监控的所有主节点的详细信息。
sentinel master mymaster：获取监控的主节点 mymaster 的详细信息。
sentinel slaves mymaster：获取监控的主节点 mymaster 的从节点的详细信息。
sentinel sentinels mymaster：获取监控的主节点 mymaster 的哨兵节点的详细信息。
sentinel get-master-addr-by-name mymaster：获取监控的主节点 mymaster 的地址信息，前文已有介绍。
sentinel is-master-down-by-addr：哨兵节点之间可以通过该命令询问主节点是否下线，从而对是否客观下线做出判断。

小结
哨兵系统的搭建过程，有几点需要注意：
哨兵系统中的主从节点，与普通的主从节点并没有什么区别，故障发现和转移是由哨兵来控制和完成的。
哨兵节点本质上是 Redis 节点。
每个哨兵节点，只需要配置监控主节点，便可以自动发现其他的哨兵节点和从节点。
在哨兵节点启动和故障转移阶段，各个节点的配置文件会被重写(config rewrite)。
本文的例子中，一个哨兵只监控了一个主节点；实际上，一个哨兵可以监控多个主节点，通过配置多条 sentinel monitor 即可实现

客户端访问哨兵系统

     public static void sentinel() throws Exception {
         String masterName = "mymaster";
         Set<String> sentinels = new HashSet<>();
         sentinels.add("192.168.1.128:26379");
         sentinels.add("192.168.1.128:26380");
         sentinels.add("192.168.1.128:26381");
         
         qweqweJedisSentinelPool pool = new JedisSentinelPool(masterName, sentinels); //初始化过程做了很多工作
         Jedis jedis = pool.getResource();
         jedis.set("key1", "value1");
         pool.close();
  	}