Redis高可用架构的应用及改进经验谈

TommieAlcal 4年前
   <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>