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

• 3个Sentinel的连接方式(不是Redis主库连接方式)
• Redis密码
• masterName

说明：如果Sentinel上层使用了LVS,那么配置里改为VIP.

应用程序通过和Sentinel交互,获取到Redis主库信息,然后再处理读写请求.其中,由于Sentinel带来的性能开销很小,可以忽略.

需要注意的地方：

1. 多个Sentinel连接方式,驱动如何选择推荐的处理方式：采用轮训或者随机选择,支持负载均衡.
2. 如果某个Sentinel宕机,驱动如何处理推荐的处理方式：采用重试和黑名单机制,及时上线和下线故障节点,支持高可用.
3. 驱动是否具有连接池功能一般情况下,主流的语言,比如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服务很稳定,没有问题.

这是修改过的Redis源码,已上传到GitHub：

• https://github.com/giantmangu888/redis3.0.7

或者直接下载：

• git clone https://github.com/giantmangu888/redis3.0.7.git
• 相关专题：一个小改进,解决Redis数据在线加载大痛点
• 文章来自微信公众号：DBAplus社群