首页 > 知识库 > 正文

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

这个7月注定不平凡,通过7月连续的Redis故障,本文主要涉及到的故障包括:1 网卡故障2 这该死的连接数3 疑似 Cluster 脑裂?4 Bgsave传统的典型问题5 主库重启 Flush 掉从库

 \

     嘉宾介绍

董泽润 【高级DBA】

2010—2012年在搜狐畅游,负责游戏Mysql相关的运维。

2012—2015年在赶集网担任DBA,负责整个数据库团队的建设,主要研究 Mysql、Redis、MongoDB 等技术。

2015—至今在一家图片社交公司,专注于 Redis 的运维和自动化研发工作。

引子

这个7月注定不平凡,通过7月连续的Redis故障,细心如你,一定会对技术、公司、同事、职业有了更深刻的认识和反思,先回忆下吧……

本文主要涉及到的故障包括:

1.网卡故障

2.这该死的连接数

3.疑似 Cluster 脑裂?

4.Bgsave传统的典型问题

5.主库重启 Flush 掉从库

好的,敬请欣赏。

Redis Cluster 的迁移之路

我们Redis 部署特点如下:

◆集中部署,N台机器专职负责某个产品线。

◆传统 Twemproxy 方式,额外会有自己定制几套 Twemproxy 。

可以看出来,非常传统的方式。开始只有一个Default集群,PHP 所有功能获取Redis句柄都是这个,流量增长后开始按功能划分。

5月中旬,我来到公司,开始推进 Redis Cluster,争取替换掉 Twemproxy,制定了如下方案:

  1. Redis Cluster => Smart Proxy => PHP 

集群模式能够做到自动扩容,可以把机器当成资源池使用

在 PHP 前面部署基于 Cluster 的 Smart Proxy,这是非常必要的,后文会说到。由于公司有自定义 Redis 和 Twemproxy 版本,所以为了做到无缝迁移,必须使用实时同步工具。

好在有@goroutine Redis-Port,非常感谢原 Codis 作者刘奇大大。

基于Redis-Port,修改代码可以把 Redis 玩出各种花样,如同七巧板一样,只有你想不到的没有他做不到的,可以不夸张的说是 Redis 界的瑞士军刀

◆实时同步两套集群

◆跨机房同步

◆同步部分指定Key

◆删除指定Key

◆统计Redis内存分布

◆……

迁移方案如下:

1.Redis Master => Redis-Port => Smart Proxy => Redis Cluster

也即,Redis-Port 从原Redis Master 读取数据,再通过Smart Proxy 写入到 Redis Cluster。

2.修改 PHP Config, Gitlab 发布上线,使用新集群配置。

3.停掉老 Twemproxy 集群,完成迁移。

这种迁移方案下,原Redis 无需停业务。

注意:

此方案中的Smart Proxy 是我们自己写的,事实证明很有必要,其作为Redis Cluster 的前端,用来屏蔽Redis Cluster 的复杂性。

方案看似简单,实际使用要慎重。大家都知道 Redis Rdb Bgsave 会使线上卡顿,所以需要在低峰期做,并且轮流 Redis Master 同步,千万不能同时用 Redis Port 做 Sync。

在实施过程中,遇到多种问题,现在简要阐述如下:

问题1:还是网卡故障

想起《东京爱情故事》主题曲,突如其来的爱情,不知该从何说起。

\ 

故障的图找不到了,截图一张正常网卡流量图 -_^

千兆网卡在某个周五23:00业务高峰期被打满,导致线上请求失败—如坐针毡的波峰图。

如前文所说,公司集中部署 Redis,此业务是线上 Cache 个人详情页登陆相关的,一共4台机器,每台20实例,无法做到立刻扩容,紧急之下 RD 同学降级,抛掉前端30%的请求。只是恢复后,高峰期已过。

Leader要求周六所有人加班去迁移,But,2点多大家睡了,嗯,就这样睡了ZZZZ~~ 故障暂时解决,但故事依然继续……

周六上午10点,市场运营推送消息,导致人为打造了小高峰,又是如坐针毡的波峰图,服务立马报警,紧急之下立马再次抛掉30%请求。

然后,紧急搭建两套不同功能的 Redis Cluster 集群,采用冷启动的方式,一点点将 Cache 流量打到新集群中,Mysql 几台从库 QPS 一度冲到8K。

针对网卡最后引出两个解决方案:

1.所有Redis 机器做双网卡 Bonding,变成2000Mbps。

2.所有 Redis 产品线散开,混合部署打散。

3.增加网卡流量监控,到达60%报警。

反思:

为什么要睡觉?而不是连夜迁移?做为运维人员,危险意识不够足。

另外:还有一起网卡故障,是应用层 Bug,频繁请求大 Json Key 打满网卡。当时QPS稳定保持在20W左右,千兆网卡被打满。临时解决方案直接干掉这个Key,过后再由 RD 排查。

深度剖析

◆监控报警不到位,对于创业公司比较常见,发生一起解决一起。

◆针对这类问题,有两个想法:QPS 报警,比如阀值定在2W。还有一个在Proxy上做文章,对 Key 的访问做限速或增加 Key 的屏蔽功能。

◆QPS报警后运维人员排查,可能已经产生影响了,在Proxy层做对性能会有影响。

相关热词搜索:Redis Cluster 迁移 解决方案

上一篇:突发重大事故,我们运维这样进行处理(1)
下一篇:基于Ncurses的日志文件阅读器LNAV介绍

分享到: 收藏