Redis Cluster迁移遇到的各种运维坑及解决方案(1)
2016-02-20 19:34:04   来源： 董泽润 高效运维    评论：0 点击：

问题2：你这该死的连接数

某天8点40左右，还在地铁的我接到电话，Redis 连接报错，貌似几个实例的连接数被打满。这个故障持续时间较长，PHP Redis 扩展直连 Redis Cluster，连接持续增长，直到打满完全连不上。

后来经过排查，确认是扩展 Bug，导致老连接不释放。同时，其他原因也很多：

1.公司使用 Redhat7，所有的应用都是由 systemd 管理，启动没有指定Limit NOFILE，导致 Redis maxclients 限制死在4000左右。

2.PHP Redis 扩展 Bug，连接不释放，线下稳定复现。

这几次连续故障很严重，Leader 直接决定全部回退到老的 Twemproxy 版本，最后回退了两个最重要的产品线。

反思：

1.架构改动没有经过充分测试，线下稳定复现的Bug没有仔细测试直接上线。

2.运维意识不足，对 systemd 了解不够深入，没有对所有配置做严格检查。

3.做为”世界上最好的语言”，偶尔还是有些问题，最好在 Redis 和 PHP 间隔层 Proxy，将后端 Redis 保护在安全的位置。

问题3：疑似 Cluster 脑裂?

脑裂在所谓的分布式系统中很常见，大家也不陌生，做为DBA最怕的就是Mysql keepalived 脑裂，造成主库双写。难道 Redis Cluster中也会有脑裂么?

凌晨5点接到电话，发现应用看到数据不一致，偶尔是无数据，偶尔有数据，很像读到了脏数据。

Mysql 在多个从库上做读负载均衡很常见，Redis Cluster也会么?

登上Redis，Cluster Nodes，Cluster Config，确实发现不同 Redis 实例配置了不同的Cluster Nodes。想起了昨天有对该集群迁移，下掉了几个实例，但是在 PHP 配置端没有推送配置，导致 PHP 可能读到了旧实例数据，马上重新推送一遍配置，问题解决。

反思：

1.有任务配置的变更，一定考虑好所有环境的连动。这也是当前配置无自动发现的弊端。

2.屏蔽细节，在Redis Cluster上层做 Proxy 的重要性再一次得到验证。

3.运维意识不足，严重的人为故障。

问题4：Bgsave传统的典型问题

问题很典型了，非常严重的故障导致Redis OOM(Out of Memory)。

解决方案：

单台机器不同端口轮流 Bgsave，内存不足时先释放 Cache，释放失败拒绝再 Bgsave 并报警。

问题5：主库重启 Flush 掉从库

考虑不周，备份时，只在 Slave 上 Bgsave。主库由于某些原因重启，立马被 systemd 拉起，时间远短于 Cluster 选举时间。

后面就是普通 Redis Master/Slave 之间的故事了，Master 加载空 dump.rdb，replicate 到 Slave，刷掉 Slave数据。

解决方案:

1.备份的同时，将 dump.rdb rsync 到主库 datadir 目录下面一份。

2.根据 Redis 用途，做存储使用的 Redis systemd 去掉 Auto Restart 配置。

其它典型故障/问题

1.应用设计问题，部分 hset 过大，一度超过48W条记录，Redis频繁卡顿感。

2.使用 Redis 做计数器，占用过大内存空间。这个 Redis 官网有解决方案，利用 hash/list 的线性存储，很有效。但是由于 mget 无法改造，我们没采用。

3.混布，导致部份产品线消耗资源过高，影响其它所有实例。

4.机房IDC故障，单个机柜不通，里面所有混布的产品线无法提供请求，数据请求失败。

5.应用端分不清 Cache/Storage，经常可以做成 Cache 的 Key，不加ttl导致无效内存占用。

写在最后

虽然写在最后，但远没有结束，征程才刚刚开始。

每次故障都是一次反思，但我们拒绝活在过去，生活还要继续。

公司重度依赖Redis，除了图片其它所有数据都在Redis中。在稳定为主的前提下，还在向Redis Cluster迁移，其中有几个问题还待解决：

1.Redis 实例级别高可用，机柜级别高可用。

2.混布的资源隔离，看了 hunantv CMGS 的分享，Docker是一个方案。

3.隔离上层语言与 Redis，提供稳定的 Smart Proxy接口。

4.Redis 集群 build 和交付，缺少配置集中管理。

5.很多集群 QPS 并不高，内存浪费严重，急需持久化 Redis 协议存储，基于 ardb/ledisdb 的 sharding 是个方案，自己开发需要同事的信任，这点很重要。

最终公司线上存在两个版本，Twemproxy 开启 auto_reject_host 做 Cache 集群，Redis Cluster + Smart Proxy做存储。

如何一起愉快地发展

“高效运维”公众号（如下二维码）值得您的关注，作为高效运维系列微信群的唯一官方公众号，每周发表多篇干货满满的原创好文：来自于系列群的讨论精华、运维讲坛线上精彩分享及群友原创。“高效运维”也是互联网专栏《高效运维最佳实践》及运维2.0官方公众号。

提示：目前高效运维新群已经建立，欢迎加入。您可添加萧田国个人微信号xiaotianguo8 为好友，进行申请，请备注“申请入群”。

重要提示：除非事先获得授权，请在本公众号发布2天后，才能转载本文。尊重知识，请必须全文转载，并包括本行。

【编辑推荐】