Redis Sentinel（哨兵）部署

       在一个典型的一主已从或一主多从的Redis系统中，从数据库虽然可以起到了数据冗余备份和读写分离的作用。但是也能发现，当主节点发生故障后，需要人为干预手动提升一个从节点为主节点继续对外提供服务，难以实现自动化。
       为此，Redis 2.8版本开始提供了哨兵工具来实现自动化的系统监控和故障恢复功能。

什么是哨兵？

Redis哨兵为Redis提供了高可用性。实际上这意味着你可以使用哨兵模式创建一个可以不用人为干预而应对各种故障的Redis部署。

哨兵模式还提供了其他的附加功能，如监控，通知，为客户端提供配置。

下面是在宏观层面上哨兵模式的功能列表：

监控：哨兵不断的检查master和slave是否正常的运行。

通知：当监控的某台Redis实例发生问题时，可以通过API通知系统管理员和其他的应用程序。

自动故障转移：如果一个master不正常运行了，哨兵可以启动一个故障转移进程，将一个slave升级成为master，其他的slave被重新配置使用新的master，并且应用程序使用Redis服务端通知的新地址。

配置提供者：哨兵作为Redis客户端发现的权威来源：客户端连接到哨兵请求当前可靠的master的地址。如果发生故障，哨兵将报告新地址。

Redis哨兵是一个独立的进程，使用哨兵的一个典型架构图如下：

这是一张多哨兵的架构图，以保证系统足够的稳健，防止单节点哨兵故障，当然也可以只使用一个哨兵节点。

哨兵配置

一、部署哨兵之前需要了解的基本事情

1）一个健壮的部署至少需要三个哨兵实例。

2）三个哨兵实例应该放置在客户使用独立方式确认故障的计算机或虚拟机中。例如不同的物理机或不同可用区域的虚拟机。

3）sentinel + Redis实例不保证在故障期间保留确认的写入，因为Redis使用异步复制。然而有方式部署哨兵使丢失数据限制在特定时刻，虽然有更安全的方式部署它。

4）Sentinel，Docker，或者其他形式的网络地址交换或端口映射需要加倍小心：Docker执行端口重新映射，破坏Sentinel自动发现其他的哨兵进程和master的slave列表。

二、部署哨兵

1)Redis Sentinel规划

 

2)安装Redis

参考

http://www.cnblogs.com/zuxing/articles/7724111.html

3）设置主从复制

修改redis.conf 文件

bind 0.0.0.0              #改127.0.0.1 为0.0.0.0 不然Sentinel切换主从失败
daemonize yes
pidfile "/var/run/redis_6379.pid"
logfile "/usr/local/redis/redis-6379.log"
dir "/usr/local/redis"
slaveof 192.168.1.135 6379   #在从库上设置

这里需要注意一点，如果主数据库设置了密码，需要所有Redis的配置文件中设置masterauth"Redis-Password"，包括主数据库。Sentinel可以切换主从数据库，主数据库可能会变成从数据库，因此也需要设置主数据库密码。

 4）配置Sentinel.config

daemonize yes
port 5000
sentinel monitor mymaster 192.168.1.160 6379 2

5）Sentinel验证

按照之前的步骤我们已经配置好了3台Redisnode和Sentinel集群，Redis主数据库为192.168.1.160:6379　

模拟主数据库故障

这里直接关闭主数据库，终端输入

/usr/local/redis/redis-cli -p 6379 shutdown

经过一段时间后，我们可以看到sentinel.log文件中增加了以下内容：

2146:X 24 Jan 17:26:29.562 # -sdown master mymaster 192.168.1.160 6379
22146:X 24 Jan 17:26:29.562 # -odown master mymaster 192.168.1.160 6379
22146:X 24 Jan 17:39:38.013 # +sdown master mymaster 192.168.1.160 6379
22146:X 24 Jan 17:39:38.013 # +odown master mymaster 192.168.1.160 6379 #quorum 1/1
22146:X 24 Jan 17:39:38.013 # +new-epoch 12
22146:X 24 Jan 17:39:38.013 # +try-failover master mymaster 192.168.1.160 6379
22146:X 24 Jan 17:39:38.060 # +vote-for-leader ccedb78c9ab16e00e04f849a6b3ac9ee52ab3ea0 12
22146:X 24 Jan 17:39:38.060 # +elected-leader master mymaster 192.168.1.160 6379
22146:X 24 Jan 17:39:38.060 # +failover-state-select-slave master mymaster 192.168.1.160 6379
22146:X 24 Jan 17:39:38.113 # -failover-abort-no-good-slave master mymaster 192.168.1.160 6379
22146:X 24 Jan 17:39:38.179 # Next failover delay: I will not start a failover before Wed Jan 24 17:45:38 2018

+sdown 表示哨兵主观认为数据库下线
+odown 表示哨兵客观认为数据库下线
+try-failover 表示哨兵开始进行故障恢复
+failover-end 表示哨兵完成故障修复，其中包括了领头哨兵的选举、备选从数据库的选择等等较为复杂的过程
+switch-master表示主数据库从51服务器迁移到52服务器
+slave列出了新的主数据库的2个从数据库，而哨兵并没有彻底清除51服务器的实力信息，这是因为停止的实例有可能会在将来恢复，哨兵会让其重新加入进来。

恢复故障数据库

重新启动192.168.1.51上的Redis数据库，查看sentinel.log文件，日志中增加了以下的内容：

22146:X 24 Jan 17:39:38.113 # -failover-abort-no-good-slave master mymaster 192.168.1.160 6379