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層做對性能會有影響。