Redis Cluster迁移遇到的各种运维坑及解决方案
嘉宾介绍
董泽润 【高级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，制定了如下方案：
- 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层做对性能会有影响。