redis HA高可用方案Sentinel和shard

1、搭建redis-master、redis-slave以及seninel哨兵监控

在最小配置：master、slave各一个节点的情况下，不管是master还是slave down掉一个，“完整的”读/写功能都将受影响，这在生产环境中显然不能接受。幸好redis提供了sentinel（哨兵）机制，通过sentinel模式启动redis后，自动监控master/slave的运行状态，基本原理是：心跳机制+投票裁决

每个sentinel会向其它sentinal、master、slave定时发送消息，以确认对方是否“活”着，如果发现对方在指定时间（可配置）内未回应，则暂时认为对方已挂（所谓的“主观认为宕机” Subjective Down，简称SDOWN）。

若“哨兵群”中的多数sentinel，都报告某一master没响应，系统才认为该master"彻底死亡"(即：客观上的真正down机，Objective Down，简称ODOWN)，通过一定的vote算法，从剩下的slave节点中，选一台提升为master，然后自动修改相关配置

最小化的sentinel配置文件为：

1 port 26389
2 
3 dir ./tmp
4 
5 sentinel monitor mymaster 127.0.0.1 6379 1
6 sentinel down-after-milliseconds mymaster 5000
7 sentinel parallel-syncs mymaster 1
8 sentinel failover-timeout mymaster 15000

第1行，指定sentinel使用的端口，不能与redis-server运行实例的端口冲突

第3行，指定工作目录

第5行，显示监控master节点10.6.144.155，master节点使用端口7030，最后一个数字表示投票需要的"最少法定人数"，比如有10个sentinal哨兵都在监控某一个master节点，如果需要至少6个哨兵发现master挂掉后，才认为master真正down掉，那么这里就配置为6，最小配置1台master，1台slave，在二个机器上都启动sentinal的情况下，哨兵数只有2个，如果一台机器物理挂掉，只剩一个sentinal能发现该问题，所以这里配置成1，至于mymaster只是一个名字，可以随便起，但要保证5-8行都使用同一个名字

第6行，表示如果5s内mymaster没响应，就认为SDOWN

第8行，表示如果15秒后,mysater仍没活过来，则启动failover，从剩下的slave中选一个升级为master

第7行，表示如果master重新选出来后，其它slave节点能同时并行从新master同步缓存的台数有多少个，显然该值越大，所有slave节点完成同步切换的整体速度越快，但如果此时正好有人在访问这些slave，可能造成读取失败，影响面会更广。最保定的设置为1，只同一时间，只能有一台干这件事，这样其它slave还能继续服务，但是所有slave全部完成缓存更新同步的进程将变慢。

另：一个sentinal可同时监控多个master，只要把5-8行重复多段，加以修改即可。

各自启动redis主备和sentinal哨兵，查看redis的master

./redis-cli -p 26389 sentinel masters 可通过该命令查看当前的master节点情况

模拟当master挂掉，是否slave switch为master.

切换成功,将挂掉master启起来，是否该redis变幻为slave.

2、sentinel和shard redis保证redis 集群的高可用。

Sentinel&Jedis看上去是个完美的解决方案，这句话只说对了一半，在无分片的情况是这样，但我们的应用使用了数据分片-sharing，数据被平均分布到4个不同的实例上，每个实例以主从结构部署，Jedis没有提供基于Sentinel的ShardedJedisPool，也就是说在4个分片中，如果其中一个分片发生主从切换，应用所使用的ShardedJedisPool无法获得通知，所有对那个分片的操作将会失败。
本文提供一个基于Sentinel的ShardedJedisPool，能及时感知所有分片主从切换行为，进行连接池重建..........

3\监控..

目前针对redis的监控比较少见，主要有redis-live、dredis等。但这些工具对redis性能消耗比较严重，实时监控比较困难。

redis的监控可以简单分为安全监控和性能监控。安全监控可以通过redissentinel的输出日志判断Master和Slave的状态；性能监控需要收集redis的性能参数进行评估。因此二者并不冲突，通过shell脚本可以实现轻量级的监控，缺点是没有可视化的实时图表。

1、安全监控

Redis sentinel的输出日志简洁而且内容很丰富，包含redis的实时状态、故障切换时间以及sentinel自身的状态，并且针对故障消除也有详细的记录。通过对sentinel日志挖掘，找出故障时刻进行及时报警，并通知管理员。

由于sentinel默认不启用日志记录，可以通过以下方法记录日志：

启动输入日志:

src/redis-sentinel sentinel.conf >>sentinel.log &