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

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

后來經(jīng)過排查，確認(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)過充分測試，線下穩(wěn)定復(fù)現(xiàn)的Bug沒有仔細(xì)測試直接上線。

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

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

問題3：疑似 Cluster 腦裂?

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

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

Mysql 在多個(gè)從庫上做讀負(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ù)，馬上重新推送一遍配置，問題解決。

反思：

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

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

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

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

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

解決方案：

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

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

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

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

解決方案:

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

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

其它典型故障/問題

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

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

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

4.機(jī)房IDC故障，單個(gè)機(jī)柜不通，里面所有混布的產(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遷移，其中有幾個(gè)問題還待解決：

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

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

3.隔離上層語言與 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)好文：來自于系列群的討論精華、運(yùn)維講壇線上精彩分享及群友原創(chuàng)。“高效運(yùn)維”也是互聯(lián)網(wǎng)專欄《高效運(yùn)維最佳實(shí)踐》及運(yùn)維2.0官方公眾號(hào)。

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

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

【編輯推薦】