欢迎关注“高效运维”公众号,以免费参加「运维讲坛」每月一次的线下交流活动;并抢先赏阅干货满满的各种原创文章(详见文末)。 编辑
嘉宾介绍
引子这个7月注定不平凡,通过7月连续的Redis故障,细心如你,一定会对技术、公司、同事、职业有了更深刻的认识和反思,先回忆下吧…… 本文主要涉及到的故障包括:
好的,敬请欣赏。 Redis Cluster 的迁移之路我们Redis 部署特点如下:
可以看出来,非常传统的方式。开始只有一个Default集群,PHP 所有功能获取Redis句柄都是这个,流量增长后开始按功能划分。 5月中旬我来到公司,开始推进 Redis Cluster,争取替换掉 Twemproxy,制定了如下方案:
集群模式能够做到自动扩容,可以把机器当成资源池使用 在 PHP 前面部署基于 Cluster 的 Smart Proxy,这是非常必要的,后文会说到。由于公司有自定义 Redis 和 Twemproxy 版本,所以为了做到无缝迁移,必须使用实时同步工具。 好在有@goroutine Redis-Port,非常感谢原 Codis 作者刘奇大大。 基于Redis-Port,修改代码可以把 Redis 玩出各种花样,如同七巧板一样,只有你想不到的没有他做不到的,可以不夸张的说是 Redis 界的瑞士军刀:
迁移方案如下:
这种迁移方案下,原Redis 无需停业务。 注意:
在实施过程中,遇到多种问题,现在简要阐述如下: 问题1:还是网卡故障想起《东京爱情故事》主题曲,突如其来的爱情,不知该从何说起。
千兆网卡在某个周五23:00业务高峰期被打满,导致线上请求失败—如坐针毡的波峰图。 如前文所说,公司集中部署 Redis,此业务是线上 Cache 个人详情页登陆相关的,一共4台机器,每台20实例,无法做到立刻扩容,紧急之下 RD 同学降级,抛掉前端30%的请求。只是恢复后,高峰期已过。 Leader要求周六所有人加班去迁移,But,2点多大家睡了,嗯,就这样睡了ZZZZ~~ 故障暂时解决,但故事依然继续…… 周六上午10点,市场运营推送消息,导致人为打造了小高峰,又是如坐针毡的波峰图,服务立马报警,紧急之下立马再次抛掉30%请求。 然后紧急搭建两套不同功能的 Redis Cluster 集群,采用冷启动的方式,一点点将 Cache 流量打到新集群中,Mysql 几台从库 QPS 一度冲到8K。 针对网卡最后引出两个解决方案:
反思:为什么要睡觉?而不是连夜迁移?做为运维人员,危险意识不够足。 另外:还有一起网卡故障,是应用层 Bug,频繁请求大 Json Key 打满网卡。当时QPS稳定保持在20W左右,千兆网卡被打满。临时解决方案直接干掉这个Key,过后再由 RD 排查。 深度剖析:
问题2:你这该死的连接数某天8点40左右,还在地铁的我接到电话,Redis 连接报错,貌似几个实例的连接数被打满。这个故障持续时间较长,PHP Redis 扩展直连 Redis Cluster,连接持续增长,直到打满完全连不上。 后来经过排查,确认是扩展 Bug,导致老连接不释放。同时 其他原因也很多:
这几次连续故障很严重,Leader 直接决定全部回退到老的 Twemproxy 版本,最后回退了两个最重要的产品线。 反思:
问题3:疑似 Cluster 脑裂?脑裂在所谓的分布式系统中很常见,大家也不陌生,做为DBA最怕的就是Mysql keepalived 脑裂,造成主库双写。难道 Redis Cluster中也会有脑裂么? 凌晨5点接到电话,发现应用看到数据不一致,偶尔是无数据,偶尔有数据,很像读到了脏数据。 Mysql 在多个从库上做读负载均衡很常见,Redis Cluster也会么? 登上 Redis, Cluster Nodes, Cluster Config,确实发现不同 Redis 实例配置了不同的Cluster Nodes。想起了昨天有对该集群迁移,下掉了几个实例,但是在 PHP 配置端没有推送配置,导致 PHP 可能读到了旧实例数据,马上重新推送一遍配置,问题解决。 反思:
问题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数据。 解决方案:
其它典型故障/问题
写在最后虽然写在最后,但远没有结束,征程才刚刚开始。每次故障都是一次反思,但我们拒绝活在过去,生活还要继续。 公司重度依赖Redis,除了图片其它所有数据都在Redis中。在稳定为主的前提下,还在向Redis Cluster迁移,其中有几个问题还待解决:
最终公司线上存在两个版本,Twemproxy 开启 auto_reject_host 做 Cache 集群,Redis Cluster + Smart Proxy做存储。 如何一起愉快地发展“高效运维”公众号(如下二维码)值得您的关注,作为高效运维系列微信群的唯一官方公众号,每周发表多篇干货满满的原创好文:来自于系列群的讨论精华、运维讲坛线上精彩分享及群友原创。“高效运维”也是互联网专栏《高效运维最佳实践》及运维2.0官方公众号。 目前高效运维新群已经建立,欢迎加入。您可添加萧田国个人微信号xiaotianguo8 为好友(或扫描如下二维码),进行申请,请备注“申请入群”。 |
|