[[157959]]

       嘉賓介紹

董澤潤　【高級DBA】

　　2010—2012年在搜狐暢游，負(fù)責(zé)游戲Mysql相關(guān)的運維。

　　2012—2015年在趕集網(wǎng)擔(dān)任DBA，負(fù)責(zé)整個數(shù)據(jù)庫團隊的建設(shè)，主要研究 Mysql、Redis、MongoDB 等技術(shù)。

　　2015—至今在一家圖片社交公司，專注于 Redis 的運維和自動化研發(fā)工作。

　　引子

　　這個7月注定不平凡，通過7月連續(xù)的Redis故障，細(xì)心如你，一定會對技術(shù)、公司、同事、職業(yè)有了更深刻的認(rèn)識和反思，先回憶下吧……

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

　　1.網(wǎng)卡故障

　　2.這該死的連接數(shù)

　　3.疑似 Cluster 腦裂?

　　4.Bgsave傳統(tǒng)的典型問題

　　5.主庫重啟 Flush 掉從庫

　　好的，敬請欣賞。

　　Redis Cluster 的遷移之路

　　我們Redis 部署特點如下：

　　◆集中部署，N臺機器專職負(fù)責(zé)某個產(chǎn)品線。

　　◆傳統(tǒng) Twemproxy 方式，額外會有自己定制幾套 Twemproxy 。

　　可以看出來，非常傳統(tǒng)的方式。開始只有一個Default集群，PHP 所有功能獲取Redis句柄都是這個，流量增長后開始按功能劃分。

　　5月中旬，我來到公司，開始推進 Redis Cluster，爭取替換掉 Twemproxy，制定了如下方案：　　

Redis Cluster => Smart Proxy => PHP 

　　集群模式能夠做到自動擴容，可以把機器當(dāng)成資源池使用

　　在 PHP 前面部署基于 Cluster 的 Smart Proxy，這是非常必要的，后文會說到。由于公司有自定義 Redis 和 Twemproxy 版本，所以為了做到無縫遷移，必須使用實時同步工具。

　　好在有@goroutine Redis-Port，非常感謝原 Codis 作者劉奇大大。

　　基于Redis-Port，修改代碼可以把 Redis 玩出各種花樣，如同七巧板一樣，只有你想不到的沒有他做不到的，可以不夸張的說是 Redis 界的瑞士軍刀：

　　◆實時同步兩套集群

　　◆跨機房同步

　　◆同步部分指定Key

　　◆刪除指定Key

　　◆統(tǒng)計Redis內(nèi)存分布

　　◆……

　　遷移方案如下：

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

　　也即，Redis-Port 從原Redis Master 讀取數(shù)據(jù)，再通過Smart Proxy 寫入到 Redis Cluster。

　　2.修改 PHP Config， Gitlab 發(fā)布上線，使用新集群配置。

　　3.停掉老 Twemproxy 集群，完成遷移。

　　這種遷移方案下，原Redis 無需停業(yè)務(wù)。

　　注意：

　　此方案中的Smart Proxy 是我們自己寫的，事實證明很有必要，其作為Redis Cluster 的前端，用來屏蔽Redis Cluster 的復(fù)雜性。

　　方案看似簡單，實際使用要慎重。大家都知道 Redis Rdb Bgsave 會使線上卡頓，所以需要在低峰期做，并且輪流 Redis Master 同步，千萬不能同時用 Redis Port 做 Sync。

　　在實施過程中，遇到多種問題，現(xiàn)在簡要闡述如下：

　　問題1：還是網(wǎng)卡故障

　　想起《東京愛情故事》主題曲，突如其來的愛情，不知該從何說起。

　　故障的圖找不到了，截圖一張正常網(wǎng)卡流量圖 -_^

　　千兆網(wǎng)卡在某個周五23:00業(yè)務(wù)高峰期被打滿，導(dǎo)致線上請求失敗—如坐針氈的波峰圖。

　　如前文所說，公司集中部署 Redis，此業(yè)務(wù)是線上 Cache 個人詳情頁登陸相關(guān)的，一共4臺機器，每臺20實例，無法做到立刻擴容，緊急之下 RD 同學(xué)降級，拋掉前端30%的請求。只是恢復(fù)后，高峰期已過。

　　Leader要求周六所有人加班去遷移，But，2點多大家睡了，嗯，就這樣睡了ZZZZ~~ 故障暫時解決，但故事依然繼續(xù)……

　　周六上午10點，市場運營推送消息，導(dǎo)致人為打造了小高峰，又是如坐針氈的波峰圖，服務(wù)立馬報警，緊急之下立馬再次拋掉30%請求。

　　然后，緊急搭建兩套不同功能的 Redis Cluster 集群，采用冷啟動的方式，一點點將 Cache 流量打到新集群中，Mysql 幾臺從庫 QPS 一度沖到8K。

　　針對網(wǎng)卡最后引出兩個解決方案：

　　1.所有Redis 機器做雙網(wǎng)卡 Bonding，變成2000Mbps。

　　2.所有 Redis 產(chǎn)品線散開，混合部署打散。

　　3.增加網(wǎng)卡流量監(jiān)控，到達(dá)60%報警。

　　反思：

　　為什么要睡覺?而不是連夜遷移?做為運維人員，危險意識不夠足。

　　另外：還有一起網(wǎng)卡故障，是應(yīng)用層 Bug，頻繁請求大 Json Key 打滿網(wǎng)卡。當(dāng)時QPS穩(wěn)定保持在20W左右，千兆網(wǎng)卡被打滿。臨時解決方案直接干掉這個Key，過后再由 RD 排查。

　　深度剖析：

　　◆監(jiān)控報警不到位，對于創(chuàng)業(yè)公司比較常見，發(fā)生一起解決一起。

　　◆針對這類問題，有兩個想法：QPS 報警，比如閥值定在2W。還有一個在Proxy上做文章，對 Key 的訪問做限速或增加 Key 的屏蔽功能。

　　◆QPS報警后運維人員排查，可能已經(jīng)產(chǎn)生影響了，在Proxy層做對性能會有影響。

#p#

　　問題2：你這該死的連接數(shù)

　　某天8點40左右，還在地鐵的我接到電話，Redis 連接報錯，貌似幾個實例的連接數(shù)被打滿。這個故障持續(xù)時間較長，PHP Redis 擴展直連 Redis Cluster，連接持續(xù)增長，直到打滿完全連不上。

　　后來經(jīng)過排查，確認(rèn)是擴展 Bug，導(dǎo)致老連接不釋放。同時，其他原因也很多：

　　1.公司使用 Redhat7，所有的應(yīng)用都是由 systemd 管理，啟動沒有指定Limit NOFILE，導(dǎo)致 Redis maxclients 限制死在4000左右。

　　2.PHP Redis 擴展 Bug，連接不釋放，線下穩(wěn)定復(fù)現(xiàn)。

　　這幾次連續(xù)故障很嚴(yán)重，Leader 直接決定全部回退到老的 Twemproxy 版本，最后回退了兩個最重要的產(chǎn)品線。

　　反思：

　　1.架構(gòu)改動沒有經(jīng)過充分測試，線下穩(wěn)定復(fù)現(xiàn)的Bug沒有仔細(xì)測試直接上線。

　　2.運維意識不足，對 systemd 了解不夠深入，沒有對所有配置做嚴(yán)格檢查。

　　3.做為”世界上最好的語言”，偶爾還是有些問題，最好在 Redis 和 PHP 間隔層 Proxy，將后端 Redis 保護在安全的位置。

　　問題3：疑似 Cluster 腦裂?

　　腦裂在所謂的分布式系統(tǒng)中很常見，大家也不陌生，做為DBA最怕的就是Mysql keepalived 腦裂，造成主庫雙寫。難道 Redis Cluster中也會有腦裂么?

　　凌晨5點接到電話，發(fā)現(xiàn)應(yīng)用看到數(shù)據(jù)不一致，偶爾是無數(shù)據(jù)，偶爾有數(shù)據(jù)，很像讀到了臟數(shù)據(jù)。

　　Mysql 在多個從庫上做讀負(fù)載均衡很常見，Redis Cluster也會么?

　　登上Redis，Cluster Nodes，Cluster Config，確實發(fā)現(xiàn)不同 Redis 實例配置了不同的Cluster Nodes。想起了昨天有對該集群遷移，下掉了幾個實例，但是在 PHP 配置端沒有推送配置，導(dǎo)致 PHP 可能讀到了舊實例數(shù)據(jù)，馬上重新推送一遍配置，問題解決。

　　反思：

　　1.有任務(wù)配置的變更，一定考慮好所有環(huán)境的連動。這也是當(dāng)前配置無自動發(fā)現(xiàn)的弊端。

　　2.屏蔽細(xì)節(jié)，在Redis Cluster上層做 Proxy 的重要性再一次得到驗證。

　　3.運維意識不足，嚴(yán)重的人為故障。

　　問題4：Bgsave傳統(tǒng)的典型問題

　　問題很典型了，非常嚴(yán)重的故障導(dǎo)致Redis OOM(Out of Memory)。

　　解決方案：

　　單臺機器不同端口輪流 Bgsave，內(nèi)存不足時先釋放 Cache，釋放失敗拒絕再 Bgsave 并報警。

　　問題5：主庫重啟 Flush 掉從庫

　　考慮不周，備份時，只在 Slave 上 Bgsave。主庫由于某些原因重啟，立馬被 systemd 拉起，時間遠(yuǎn)短于 Cluster 選舉時間。

　　后面就是普通 Redis Master/Slave 之間的故事了，Master 加載空 dump.rdb，replicate 到 Slave，刷掉 Slave數(shù)據(jù)。

　　解決方案:

　　1.備份的同時，將 dump.rdb rsync 到主庫 datadir 目錄下面一份。

　　2.根據(jù) Redis 用途，做存儲使用的 Redis systemd 去掉 Auto Restart 配置。

　　其它典型故障/問題

　　1.應(yīng)用設(shè)計問題，部分 hset 過大，一度超過48W條記錄，Redis頻繁卡頓感。

　　2.使用 Redis 做計數(shù)器，占用過大內(nèi)存空間。這個 Redis 官網(wǎng)有解決方案，利用 hash/list 的線性存儲，很有效。但是由于 mget 無法改造，我們沒采用。

　　3.混布，導(dǎo)致部份產(chǎn)品線消耗資源過高，影響其它所有實例。

　　4.機房IDC故障，單個機柜不通，里面所有混布的產(chǎn)品線無法提供請求，數(shù)據(jù)請求失敗。

　　5.應(yīng)用端分不清 Cache/Storage，經(jīng)常可以做成 Cache 的 Key，不加ttl導(dǎo)致無效內(nèi)存占用。

　　寫在最后

　　雖然寫在最后，但遠(yuǎn)沒有結(jié)束，征程才剛剛開始。

　　每次故障都是一次反思，但我們拒絕活在過去，生活還要繼續(xù)。

　　公司重度依賴Redis，除了圖片其它所有數(shù)據(jù)都在Redis中。在穩(wěn)定為主的前提下，還在向Redis Cluster遷移，其中有幾個問題還待解決：

　　1.Redis 實例級別高可用，機柜級別高可用。

　　2.混布的資源隔離，看了 hunantv CMGS 的分享，Docker是一個方案。

　　3.隔離上層語言與 Redis，提供穩(wěn)定的 Smart Proxy接口。

　　4.Redis 集群 build 和交付，缺少配置集中管理。

　　5.很多集群 QPS 并不高，內(nèi)存浪費嚴(yán)重，急需持久化 Redis 協(xié)議存儲，基于 ardb/ledisdb 的 sharding 是個方案，自己開發(fā)需要同事的信任，這點很重要。

　　最終公司線上存在兩個版本，Twemproxy 開啟 auto_reject_host 做 Cache 集群，Redis Cluster + Smart Proxy做存儲。

如何一起愉快地發(fā)展

“高效運維”公眾號（如下二維碼）值得您的關(guān)注，作為高效運維系列微信群的唯一官方公眾號，每周發(fā)表多篇干貨滿滿的原創(chuàng)好文：來自于系列群的討論精華、運維講壇線上精彩分享及群友原創(chuàng)。“高效運維”也是互聯(lián)網(wǎng)專欄《高效運維最佳實踐》及運維2.0官方公眾號。

提示：目前高效運維新群已經(jīng)建立，歡迎加入。您可添加蕭田國個人微信號xiaotianguo8 為好友，進行申請，請備注“申請入群”。

重要提示：除非事先獲得授權(quán)，請在本公眾號發(fā)布2天后，才能轉(zhuǎn)載本文。尊重知識，請必須全文轉(zhuǎn)載，并包括本行。