[[157959]]

       嘉賓介紹

董澤潤　【高級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層做對性能會有影響。

#p#

　　問題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天后，才能轉載本文。尊重知識，請必須全文轉載，并包括本行。