关于Redis高可用方案，看到较多的是keepalived、zookeeper方案。
keepalived是主备模式，意味着总有一台浪费着。
zookeeper工作量成本偏高。
本文主要介绍下使用官方sentinel做redis高可用方案的设计。
Redis Sentinel
Sentinel介绍
Sentinel是Redis官方为集群提供的高可用解决方案。 在实际项目中可以使用sentinel去做redis自动故障转移，减少人工介入的工作量。
另外sentinel也给客户端提供了监控消息的通知，这样客户端就可根据消息类型去判断服务器的状态，去做对应的适配操作。
下面是Sentinel主要功能列表：
Monitoring：Sentinel持续检查集群中的master、slave状态，判断是否存活。
Notification：在发现某个redis实例死的情况下，Sentinel能通过API通知系统管理员或其他程序脚本。
Automatic failover：如果一个master挂掉后，sentinel立马启动故障转移，把某个slave提升为master。其他的slave重新配置指向新master。
Configuration provider：对于客户端来说sentinel通知是有效可信赖的。客户端会连接sentinel去请求当前master的地址，一旦发生故障sentinel会提供新地址给客户端。
Sentinel配置
Sentinel本质上只是一个运行在特殊模式下的redis服务器，通过不同配置来区分提供服务。 sentinel.conf配置：
启动后Sentinel会：
以10秒一次的频率，向被监视的master发送info命令，根据回复获取master当前信息。
以1秒一次的频率，向所有redis服务器、包含sentinel在内发送PING命令，通过回复判断服务器是否在线。
以2秒一次的频率，通过向所有被监视的master，slave服务器发送包含当前sentinel，master信息的消息。
另外建议sentinel至少起3个实例以上，并配置2个实例同意即可发生转移。 5个实例，配置3个实例同意以此类推。
故障转移消息接收的3种方式
Redis服务器一旦发送故障后，sentinel通过raft算法投票选举新master。 故障转移过程可以通过sentinel的API获取/订阅接收事件消息。
脚本接收
//当故障转移期间，可以指定一个“通知”脚本用来告知系统管理员，当前集群的情况。 //脚本被允许执行的最大时间为60秒，如果超时，脚本将会被终止(KILL)
服务间接接收
这种方式在第二种基础上扩展了一层，即应用端不直接订阅sentinel。 单独做服务去干这件事情，然后应用端提供API供这个服务回调通知。 这样做的好处在于：
减少应用端监听失败出错的可能性。
应用端由主动方变成被动方，降低耦合。
性能提高，轮询变回调。
独立成服务可扩展性更高。
比如：
1：以后换掉sentinel，我们只需要动服务即可，应用端无需更改。
2：可以在服务内多增加一层守护线程去主动拉取redis状态，这样可确保即使sentinel不生效，也能及时察觉redis状态，并通知到应用端。 当然这种情况很极端，因为sentinel配的也是多节点，同时挂的几率非常小。 示例： 应用端提供回调API，在这个API逻辑下去刷新内存中的Redis连接。
总结
各种sentinel通知消息类型见官方文档，项目中使用的redis客户端在github上。本文分享了楼主在项目中做Redis高可用的经验，希望对大家有所帮助。
在人力物力满足的情况下还是推荐使用zookeeper方案的。 只有三五杆枪的情况下也就退而求其次，利用最小成本满足需求并保留可扩展性。
相信没有最好的架构，只有更合适的架构。
参考：http://redis.io/topics/sentinel
近期热文推荐：
1.600+ 道 Java面试题及答案整理(2021最新版)
2.终于靠开源项目弄到 IntelliJ IDEA 激活码了，真香！
3.阿里 Mock 工具正式开源，干掉市面上所有 Mock 工具！
4.Spring Cloud 2020.0.0 正式发布，全新颠覆性版本！
5.《Java开发手册（嵩山版）》最新发布，速速下载！
觉得不错，别忘了随手点赞+转发哦！
