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社群