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