前言
随着很多公司使用Redis作为缓存和高性能存储方案，Redis的可用性也变得越来越重要。目前
比较主流的HA方案是Sentinel+Redis主从复制。Sentinel是Redis官方自带的高可用中间件，运维简单、稳定，建议使用Redis
3.0及以上稳定版本。
本文重点介绍如何使用该架构，以及需要注意的问题和解决方案。
HA架构图
首先部署Redis主从复制集群，比如1主3从；然后部署3个Sentinel节点。
为了安全起见，Sentinel节点分别部署在不同的服务器上，Redis主从节点分别部署在不同服务器上。 具体部署步骤，这里不再赘述。
最佳实践
针对这个HA架构，应用程序该如何使用呢？这里介绍一个比较简单可靠的使用方法。
在应用程序（APP）配置里设置如下信息：
3个Sentinel的连接方式（不是Redis主库连接方式）
Redis密码
masterName
说明： 如果Sentinel上层使用了LVS，那么配置里改为VIP。
应用程序通过和Sentinel交互，获取到Redis主库信息，然后再处理读写请求。 其中，由于Sentinel带来的性能开销很小，可以忽略。
需要注意的地方：
多个Sentinel连接方式，驱动如何选择
推荐的处理方式：采用轮训或者随机选择，支持负载均衡。
如果某个Sentinel宕机，驱动如何处理
推荐的处理方式：采用重试和黑名单机制，及时上线和下线故障节点，支持高可用。
驱动是否具有连接池功能
一般情况下，主流的语言，比如Java，PHP等等，驱动具有连接管理器的，支持连接复用。
可以从Redis的info信息里查看，如下：
10.11.11.13:6379> info clients
# Clients
connected_clients:150
client_longest_output_list:0
client_biggest_input_buf:0
blocked_clients:0
如果连接无法复用，connected_clients会飙升到上千，甚至导致Redis服务异常，停止处理请求。 如果驱动不支持连接池，需要选择新驱动，或者二次开发驱动。
问题分析
使用以上HA架构，细心的朋友会发现这样一个问题。 如果Redis主库宕机，Redis配置会发生改变，如下：
某些参数的值会自动被加上""，比如密码参数。 一般禁止使用类似""作为密码的一部分。Redis密码 参数一旦被加上""，在运维和使用过程中，就会存在比较大的风险和麻烦。
分析Redis源码，以下情况会触发配置修改：
1）Master故障切换
2）新加入Sentinel
3）执行 config rewrite
4）执行 sentinel flushconfig
5）执行 sentinel remove
6）Sentinel新加入Redis master节点
解决方案
针对该问题，常用解决方法：
1 人工处理
为Redis密码加上监控，一旦变更，报警后人工处理。 这是最简单也是不可靠的方法。
2 脚本控制
开发一个脚本，周期性监控Redis密码，一旦发现变更后，自动改回。 这种方法，增加了运维成本和风险，也无法100%保证解决问题。
3 修改源码逻辑
修改源码，从根本上解决这个问题，方法如下：
src/config.c
修改函数int rewriteConfig(char *path)
注释如下两行：
rewriteConfigStringOption(state,"masterauth",server.masterauth,NULL);
rewriteConfigStringOption(state,"requirepass",server.requirepass,NULL);
修改后重新编译Redis源码。 可以通过执行config rewrite命令验证，Redis密码参数不会备自动修改了。
由于代码改动很小，没有风险点，笔者在线上已经使用一年多时间，Redis服务很稳定，没有问题。
在此我向大家推荐一个架构学习交流群。交流学习群号： 744642380， 里面会分享一些资深架构师录制的视频录像：有Spring，MyBatis，Netty源码分析，高并发、高性能、分布式、微服务架构的原理，JVM性能优化、分布式架构等这些成为架构师必备的知识体系。还能领取免费的学习资源，目前受益良