嘉賓介紹

董澤潤(rùn)　【高級(jí)DBA】

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

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

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

引子

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

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

1.網(wǎng)卡故障

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

3.疑似 Cluster 腦裂?

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

5.主庫(kù)重啟 Flush 掉從庫(kù)

好的，敬請(qǐng)欣賞。

Redis Cluster 的遷移之路

我們Redis 部署特點(diǎn)如下：

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

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

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

5月中旬，我來(lái)到公司，開始推進(jìn) Redis Cluster，爭(zhēng)取替換掉 Twemproxy，制定了如下方案：

Redis Cluster => Smart Proxy => PHP 

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

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

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

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

◆實(shí)時(shí)同步兩套集群

◆跨機(jī)房同步

◆同步部分指定Key

◆刪除指定Key

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

◆……

遷移方案如下：

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

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

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

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

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

注意：

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

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

在實(shí)施過(guò)程中，遇到多種問(wèn)題，現(xiàn)在簡(jiǎn)要闡述如下：

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

想起《東京愛情故事》主題曲，突如其來(lái)的愛情，不知該從何說(shuō)起。

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

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

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

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

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

然后，緊急搭建兩套不同功能的 Redis Cluster 集群，采用冷啟動(dòng)的方式，一點(diǎn)點(diǎn)將 Cache 流量打到新集群中，Mysql 幾臺(tái)從庫(kù) QPS 一度沖到8K。

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

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

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

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

反思：

為什么要睡覺?而不是連夜遷移?做為運(yùn)維人員，危險(xiǎn)意識(shí)不夠足。

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

深度剖析：

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

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

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

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

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

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

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

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

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

反思：

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

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

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

問(wèn)題3：疑似 Cluster 腦裂?

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

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

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

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

反思：

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

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

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

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

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

解決方案：

單臺(tái)機(jī)器不同端口輪流 Bgsave，內(nèi)存不足時(shí)先釋放 Cache，釋放失敗拒絕再 Bgsave 并報(bào)警。

問(wèn)題5：主庫(kù)重啟 Flush 掉從庫(kù)

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

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

解決方案:

1.備份的同時(shí)，將 dump.rdb rsync 到主庫(kù) datadir 目錄下面一份。

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

其它典型故障/問(wèn)題

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

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

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

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

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

寫在最后

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

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

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

1.Redis 實(shí)例級(jí)別高可用，機(jī)柜級(jí)別高可用。

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

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

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

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

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

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

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

提示：目前高效運(yùn)維新群已經(jīng)建立，歡迎加入。您可添加蕭田國(guó)個(gè)人微信號(hào)xiaotianguo8 為好友，進(jìn)行申請(qǐng)，請(qǐng)備注“申請(qǐng)入群”。

重要提示：除非事先獲得授權(quán)，請(qǐng)?jiān)诒竟娞?hào)發(fā)布2天后，才能轉(zhuǎn)載本文。尊重知識(shí)，請(qǐng)必須全文轉(zhuǎn)載，并包括本行。

【編輯推薦】