《Redis高可用架构的应用及改进经验谈》要点：
本文介绍了Redis高可用架构的应用及改进经验谈，希望对您有用。如果有疑问，可以联系我们。
作者介绍
HA架构图
首先部署Redis主从复制集群,比如1主3从；然后部署3个Sentinel节点.
为了安全起见,Sentinel节点分别部署在不同的服务器上,Redis主从节点分别部署在不同服务器上.具体部署步骤,这里不再赘述.
最佳实践
说明：如果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密码参数一旦被加上””,在运维和使用过程中,就会存在比较大的风险和麻烦.
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服务很稳定,没有问题.
- https://github.com/giantmangu888/redis3.0.7
或者直接下载：
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 [email protected] 举报，一经查实，本站将立刻删除。
