嘉賓介紹

董澤潤(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—至今在一家圖片社交公司，專(zhuān)注于 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ī)器專(zhuān)職負(fù)責(zé)某個(gè)產(chǎn)品線(xiàn)。

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

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

5月中旬，我來(lái)到公司，開(kā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 玩出各種花樣，如同七巧板一樣，只有你想不到的沒(méi)有他做不到的，可以不夸張的說(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 寫(xiě)入到 Redis Cluster。

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

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

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

注意：

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

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

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

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

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

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

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

如前文所說(shuō)，公司集中部署 Redis，此業(yè)務(wù)是線(xiàn)上 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)品線(xiàn)散開(kāi)，混合部署打散。

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

反思：

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

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

深度剖析：

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

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

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