歡迎關注“高效運維”公眾號，以免費參加「運維講壇」每月一次的線下交流活動；并搶先賞閱干貨滿滿的各種原創(chuàng)文章（詳見文末）。
董偉-北京（文章整理&發(fā)布）
董澤潤 【高級DBA】
2010—2012年在搜狐暢游，負責游戲Mysql相關的運維2012—2015年在趕集網(wǎng)擔任 DBA，負責整個數(shù)據(jù)庫團隊的建設，主要研究 Mysql、Redis、MongoDB 等技術2015—至今在一家圖片社交公司，專注于 Redis 的運維和自動化研發(fā)工作
這個7月注定不平凡，通過7月連續(xù)的Redis故障，細心如你，一定會對技術、公司、同事、職業(yè)有了更深刻的認識和反思，先回憶下吧……
本文主要涉及到的故障包括：
網(wǎng)卡故障
這該死的連接數(shù)
疑似 Cluster 腦裂？
Bgsave傳統(tǒng)的典型問題
主庫重啟 Flush 掉從庫
好的，敬請欣賞。
我們Redis 部署特點如下：
集中部署，N臺機器專職負責某個產品線。
傳統(tǒng) Twemproxy 方式，額外會有自已定制幾套 Twemproxy 。
可以看出來，非常傳統(tǒng)的方式。開始只有一個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
統(tǒng)計Redis內存分布
……
遷移方案如下:
Redis Master => Redis-Port => Smart Proxy => Redis Cluster 也即，Redis-Port 從原Redis Master 讀取數(shù)據(jù)，再通過Smart Proxy 寫入到 Redis Cluster
修改 PHP Config， Gitlab 發(fā)布上線，使用新集群配置
停掉老 Twemproxy 集群，完成遷移
這種遷移方案下，原Redis 無需停業(yè)務。
注意：
此方案中的Smart Proxy 是我們自己寫的，事實證明很有必要，其作為Redis Cluster 的前端，用來屏蔽Redis Cluster 的復雜性。
方案看似簡單，實際使用要慎重。大家都知道 Redis Rdb Bgsave 會使線上卡頓，所以需要在低峰期做，并且輪流 Redis Master 同步，千萬不能同時用 Redis Port 做 Sync。
在實施過程中，遇到多種問題，現(xiàn)在簡要闡述如下：
想起《東京愛情故事》主題曲，突如其來的愛情，不知該從何說起。
故障的圖找不到了，截圖一張正常網(wǎng)卡流量圖 -_^
千兆網(wǎng)卡在某個周五23:00業(yè)務高峰期被打滿，導致線上請求失敗—如坐針氈的波峰圖。
如前文所說，公司集中部署 Redis，此業(yè)務是線上 Cache 個人詳情頁登陸相關的，一共4臺機器，每臺20實例，無法做到立刻擴容，緊急之下 RD 同學降級，拋掉前端30%的請求。只是恢復后，高峰期已過。
Leader要求周六所有人加班去遷移，But，2點多大家睡了，嗯，就這樣睡了ZZZZ~~ 故障暫時解決，但故事依然繼續(xù)……
周六上午10點，市場運營推送消息，導致人為打造了小高峰，又是如坐針氈的波峰圖，服務立馬報警，緊急之下立馬再次拋掉30%請求。
然后緊急搭建兩套不同功能的 Redis Cluster 集群，采用冷啟動的方式，一點點將 Cache 流量打到新集群中，Mysql 幾臺從庫 QPS 一度沖到8K。
針對網(wǎng)卡最后引出兩個解決方案：
所有Redis 機器做雙網(wǎng)卡 Bonding，變成2000Mbps。
所有 Redis 產品線散開，混合部署打散。
增加網(wǎng)卡流量監(jiān)控，到達60%報警。
為什么要睡覺？而不是連夜遷移？做為運維人員，危險意識不夠足。
另外：還有一起網(wǎng)卡故障，是應用層 Bug，頻繁請求大 Json Key 打滿網(wǎng)卡。當時QPS穩(wěn)定保持在20W左右，千兆網(wǎng)卡被打滿。臨時解決方案直接干掉這個Key，過后再由 RD 排查。
監(jiān)控報警不到位，對于創(chuàng)業(yè)公司比較常見，發(fā)生一起解決一起。
針對這類問題，有兩個想法：QPS 報警，比如閥值定在2W。還有一個在Proxy上做文章，對 Key 的訪問做限速或增加 Key 的屏蔽功能。
QPS報警后運維人員排查，可能已經產生影響了，在Proxy層做對性能會有影響。
某天8點40左右，還在地鐵的我接到電話，Redis 連接報錯，貌似幾個實例的連接數(shù)被打滿。這個故障持續(xù)時間較長，PHP Redis 擴展直連 Redis Cluster，連接持續(xù)增長，直到打滿完全連不上。
后來經過排查，確認是擴展 Bug，導致老連接不釋放。同時 其他原因也很多：
公司使用 Redhat7，所有的應用都是由 systemd 管理，啟動沒有指定Limit NOFILE，導致 Redis maxclients 限制死在4000左右。
PHP Redis 擴展 Bug，連接不釋放，線下穩(wěn)定復現(xiàn)。
這幾次連續(xù)故障很嚴重，Leader 直接決定全部回退到老的 Twemproxy 版本，最后回退了兩個最重要的產品線。
架構改動沒有經過充分測試，線下穩(wěn)定復現(xiàn)的Bug沒有仔細測試直接上線；
運維意識不足，對 systemd 了解不夠深入，沒有對所有配置做嚴格檢查；
做為”世界上最好的語言”，偶爾還是有些問題，最好在 Redis 和 PHP 間隔層 Proxy，將后端 Redis 保護在安全的位置。
腦裂在所謂的分布式系統(tǒng)中很常見，大家也不陌生，做為DBA最怕的就是Mysql keepalived 腦裂，造成主庫雙寫。難道 Redis Cluster中也會有腦裂么？
凌晨5點接到電話，發(fā)現(xiàn)應用看到數(shù)據(jù)不一致，偶爾是無數(shù)據(jù)，偶爾有數(shù)據(jù)，很像讀到了臟數(shù)據(jù)。
Mysql 在多個從庫上做讀負載均衡很常見，Redis Cluster也會么？
登上 Redis， Cluster Nodes, Cluster Config，確實發(fā)現(xiàn)不同 Redis 實例配置了不同的Cluster Nodes。想起了昨天有對該集群遷移，下掉了幾個實例，但是在 PHP 配置端沒有推送配置，導致 PHP 可能讀到了舊實例數(shù)據(jù)，馬上重新推送一遍配置，問題解決。
有任務配置的變更，一定考慮好所有環(huán)境的連動。這也是當前配置無自動發(fā)現(xiàn)的弊端；
屏蔽細節(jié)，在Redis Cluster上層做 Proxy 的重要性再一次得到驗證；
運維意識不足，嚴重的人為故障。
問題很典型了，非常嚴重的故障導致Redis OOM（Out of Memory）。
單臺機器不同端口輪流 Bgsave，內存不足時先釋放 Cache，釋放失敗拒絕再 Bgsave 并報警。
考慮不周，備份時，只在 Slave 上 Bgsave。主庫由于某些原因重啟，立馬被 systemd 拉起，時間遠短于 Cluster 選舉時間。
后面就是普通 Redis Master/Slave 之間的故事了，Master 加載空 dump.rdb，replicate 到 Slave，刷掉 Slave數(shù)據(jù)。
備份的同時，將 dump.rdb rsync 到主庫 datadir 目錄下面一份；
根據(jù) Redis 用途，做存儲使用的 Redis systemd 去掉 Auto Restart 配置。
應用設計問題，部分 hset 過大，一度超過48W條記錄，Redis頻繁卡頓感；
使用 Redis 做計數(shù)器，占用過大內存空間。這個 Redis 官網(wǎng)有解決方案，利用 hash/list 的線性存儲，很有效。但是由于 mget 無法改造，我們沒采用；
混布，導致部份產品線消耗資源過高，影響其它所有實例；
機房IDC故障，單個機柜不通，里面所有混布的產品線無法提供請求，數(shù)據(jù)請求失??；
應用端分不清 Cache/Storage，經常可以做成 Cache 的 Key，不加ttl導致無效內存占用。
雖然寫在最后，但遠沒有結束，征程才剛剛開始。每次故障都是一次反思，但我們拒絕活在過去，生活還要繼續(xù)。
公司重度依賴Redis，除了圖片其它所有數(shù)據(jù)都在Redis中。在穩(wěn)定為主的前提下，還在向Redis Cluster遷移，其中有幾個問題還待解決：
Redis 實例級別高可用，機柜級別高可用。
混布的資源隔離，看了 hunantv CMGS 的分享，Docker是一個方案。
隔離上層語言與 Redis，提供穩(wěn)定的 Smart Proxy接口。
Redis 集群 build 和交付，缺少配置集中管理。
很多集群 QPS 并不高，內存浪費嚴重，急需持久化 Redis 協(xié)議存儲，基于 ardb/ledisdb 的 sharding 是個方案，自已開發(fā)需要同事的信任，這點很重要。
最終公司線上存在兩個版本，Twemproxy 開啟 auto_reject_host 做 Cache 集群，Redis Cluster + Smart Proxy做存儲。
“高效運維”公眾號（如下二維碼）值得您的關注，作為高效運維系列微信群的唯一官方公眾號，每周發(fā)表多篇干貨滿滿的原創(chuàng)好文：來自于系列群的討論精華、運維講壇線上精彩分享及群友原創(chuàng)?！案咝н\維”也是互聯(lián)網(wǎng)專欄《高效運維最佳實踐》及運維2.0官方公眾號。
目前高效運維新群已經建立，歡迎加入。您可添加蕭田國個人微信號xiaotianguo8 為好友（或掃描如下二維碼），進行申請，請備注“申請入群”。
