注：陌陌爭霸的數(shù)據(jù)庫部分我沒有參與具體設(shè)計，只是參與了一些討論和提出一些意見。 在出現(xiàn)問題的時候，也都是由肥龍、曉靖、Aply 同學(xué)判斷研究解決的。所以我對 Redis 的判斷大多也從他們的討論中聽來，加上自己的一些猜測，并沒有去仔細(xì)閱讀 Redis 文檔和閱讀 Redis 代碼。

雖然我們最終都解決了問題，但本文中說描述的技術(shù)細(xì)節(jié)還是很有可能與事實相悖，請閱讀的同學(xué)自行甄別。

在陌陌爭霸之前，我們并沒有大規(guī)模使用過 Redis 。只是直覺上感覺 Redis 很適合我們的架構(gòu)：我們這個游戲不依賴數(shù)據(jù)庫幫我們處理任何數(shù)據(jù)，總的數(shù)據(jù)量雖然較大，但增長速度有限。由于單臺服務(wù)機處理能力有限，而游戲又不能分服， 玩家在任何時間地點登陸，都只會看到一個世界。

所以我們需要有一個數(shù)據(jù)中心獨立于游戲系統(tǒng)。而這個數(shù)據(jù)中心只負(fù)責(zé)數(shù)據(jù)中轉(zhuǎn)和數(shù)據(jù)落地就可以了。Redis 看起來就是最佳選擇，游戲系統(tǒng)對它只有按玩家 ID 索引出玩家的數(shù)據(jù)這一個需求。

我們將數(shù)據(jù)中心分為 32 個庫，按玩家 ID 分開。不同的玩家之間數(shù)據(jù)是完全獨立的。在設(shè)計時，我堅決反對了從一個單點訪問數(shù)據(jù)中心的做法，堅持每個游戲服務(wù)器節(jié)點都要多每個數(shù)據(jù)倉庫直接連接。因為在這里制造一個單點毫無必要。

根據(jù)我們事前對游戲數(shù)據(jù)量的估算，前期我們只需要把 32 個數(shù)據(jù)倉庫部署到 4 臺物理機上即可，每臺機器上啟動 8 個 Redis 進程。一開始我們使用 64G 內(nèi)存的機器，后來增加到了 96G 內(nèi)存。實測每個 Redis 服務(wù)會占到 4~5 G 內(nèi)存，看起來是綽綽有余的。

由于我們僅僅是從文檔上了解的 Redis 數(shù)據(jù)落地機制，不清楚會踏上什么坑，為了保險起見，還配備了 4 臺物理機做為從機，對主機進行數(shù)據(jù)同步備份。

Redis 支持兩種 BGSAVE 的策略，一種是快照方式，在發(fā)起落地指令時，fork 出一個進程把整個內(nèi)存 dump 到硬盤上；另一種喚作 AOF 方式，把所有對數(shù)據(jù)庫的寫操作記錄下來。我們的游戲不適合用 AOF 方式，因為我們的寫入操作實在的太頻繁了，且數(shù)據(jù)量巨大。

第一次事故出在 2 月 3 日，新年假期還沒有過去。由于整個假期都相安無事，運維也相對懈怠。

中午的時候，有一臺數(shù)據(jù)服務(wù)主機無法被游戲服務(wù)器訪問到，影響了部分用戶登陸。在線嘗試修復(fù)連接無果，只好開始了長達 2 個小時的停機維護。

在維護期間，初步確定了問題。是由于上午一臺從機的內(nèi)存耗盡，導(dǎo)致了從機的數(shù)據(jù)庫服務(wù)重啟。在從機重新對主機連接，8 個 Redis 同時發(fā)送 SYNC 的沖擊下，把主機擊毀了。

這里存在兩個問題，我們需要分別討論：

問題一：從機的硬件配置和主機是相同的，為什么從機會先出現(xiàn)內(nèi)存不足。

問題二：為何重新進行 SYNC 操作會導(dǎo)致主機過載。

問題一當(dāng)時我們沒有深究，因為我們沒有估算準(zhǔn)確過年期間用戶增長的速度，而正確部署數(shù)據(jù)庫。數(shù)據(jù)庫的內(nèi)存需求增加到了一個臨界點，所以感覺內(nèi)存不足 的意外發(fā)生在主機還是從機都是很有可能的。從機先掛掉或許只是碰巧而已（現(xiàn)在反思恐怕不是這樣, 冷備腳本很可能是罪魁禍?zhǔn)祝Ｔ缙谖覀兪嵌〞r輪流 BGSAVE 的，當(dāng)數(shù)據(jù)量增長時，應(yīng)該適當(dāng)調(diào)大 BGSAVE 間隔，避免同一臺物理機上的 redis 服務(wù)同時做 BGSAVE ，而導(dǎo)致 fork 多個進程需要消耗太多內(nèi)存。由于過年期間都回家過年去了，這件事情也被忽略了。

問題二是因為我們對主從同步的機制了解不足：

仔細(xì)想想，如果你來實現(xiàn)同步會怎么做？由于達到同步狀態(tài)需要一定的時間。同步最好不要干涉正常服務(wù)，那么保證同步的一致性用鎖肯定是不好的。所以 Redis 在同步時也觸發(fā)了 fork 來保證從機連上來發(fā)出 SYNC 后，能夠順利到達一個正確的同步點。當(dāng)我們的從機重啟后，8 個 slave redis 同時開啟同步，等于瞬間在主機上 fork 出 8 個 redis 進程，這使得主機 redis 進程進入交換分區(qū)的概率大大提高了。

在這次事故后，我們?nèi)∠?slave 機。因為這使系統(tǒng)部署更復(fù)雜了，增加了許多不穩(wěn)定因素，且未必提高了數(shù)據(jù)安全性。同時，我們改進了 bgsave 的機制，不再用定時器觸發(fā)，而是由一個腳本去保證同一臺物理機上的多個 redis 的 bgsave 可以輪流進行。另外，以前在從機上做冷備的機制也移到了主機上。好在我們可以用腳本控制冷備的時間，以及錯開 BGSAVE 的 IO 高峰期。

第二次事故最出現(xiàn)在最近（ 2 月 27 日）。

我們已經(jīng)多次調(diào)整了 Redis 數(shù)據(jù)庫的部署，保證數(shù)據(jù)服務(wù)器有足夠的內(nèi)存。但還是出了次事故。事故最終的發(fā)生還是因為內(nèi)存不足而導(dǎo)致某個 Redis 進程使用了交換分區(qū)而處理能力大大下降。在大量數(shù)據(jù)擁入的情況下，發(fā)生了雪崩效應(yīng)：曉靖在原來控制 BGSAVE 的腳本中加了行保底規(guī)則，如果 30 分鐘沒有收到 BGSAVE 指令，就強制執(zhí)行一次保障數(shù)據(jù)最終可以落地（對這條規(guī)則我個人是有異議的）。結(jié)果數(shù)據(jù)服務(wù)器在對外部失去響應(yīng)之后的半小時，多個 redis 服務(wù)同時進入 BGSAVE 狀態(tài)，吃光了內(nèi)存。

花了一天時間追查事故的元兇。我們發(fā)現(xiàn)是冷備機制惹的禍。我們會定期把 redis 數(shù)據(jù)庫文件復(fù)制一份打包備份。而操作系統(tǒng)在拷貝文件時，似乎利用了大量的內(nèi)存做文件 cache 而沒有及時釋放。這導(dǎo)致在一次 BGSAVE 發(fā)生的時候，系統(tǒng)內(nèi)存使用量大大超過了我們原先預(yù)期的上限。

這次我們調(diào)整了操作系統(tǒng)的內(nèi)核參數(shù)，關(guān)掉了 cache ，暫時解決了問題。

經(jīng)過這次事故之后，我反思了數(shù)據(jù)落地策略。我覺得定期做 BGSAVE 似乎并不是好的方案。至少它是浪費的。因為每次 BGSAVE 都會把所有的數(shù)據(jù)存盤，而實際上，內(nèi)存數(shù)據(jù)庫中大量的數(shù)據(jù)是沒有變更過的。一目前 10 到 20 分鐘的保存周期，數(shù)據(jù)變更的只有這個時間段內(nèi)上線的玩家以及他們攻擊過的玩家（每 20 分鐘大約發(fā)生 1 到 2 次攻擊），這個數(shù)字遠遠少于全部玩家數(shù)量。

我希望可以只備份變更的數(shù)據(jù)，但又不希望用內(nèi)建的 AOF 機制，因為 AOF 會不斷追加同一份數(shù)據(jù)，導(dǎo)致硬盤空間太快增長。

我們也不希望給游戲服務(wù)和數(shù)據(jù)庫服務(wù)之間增加一個中間層，這白白犧牲了讀性能，而讀性能是整個系統(tǒng)中至關(guān)重要的。僅僅對寫指令做轉(zhuǎn)發(fā)也是不可靠的。因為失去和讀指令的時序，有可能使數(shù)據(jù)版本錯亂。

如果在游戲服務(wù)器要寫數(shù)據(jù)時同時向 Redis 和另一個數(shù)據(jù)落地服務(wù)同時各發(fā)一份數(shù)據(jù)怎樣？首先，我們需要增加版本機制，保證能識別出不同位置收到的寫操作的先后（我記得在狂刃中，就發(fā)生過數(shù)據(jù)版本錯 亂的 Bug ）；其次，這會使游戲服務(wù)器和數(shù)據(jù)服務(wù)器間的寫帶寬加倍。

最后我想了一個簡單的方法：在數(shù)據(jù)服務(wù)器的物理機上啟動一個監(jiān)護服務(wù)。當(dāng)游戲服務(wù)器向數(shù)據(jù)服務(wù)推送數(shù)據(jù)并確認(rèn)成功后，再把這組數(shù)據(jù)的 ID 同時發(fā)送給這個監(jiān)護服務(wù)。它再從 Redis 中把數(shù)據(jù)讀回來，并保存在本地。

因為這個監(jiān)護服務(wù)和 Redis 1 比 1 配置在同一臺機器上，而硬盤寫速度是大于網(wǎng)絡(luò)帶寬的，它一定不會過載。至于 Redis ，就成了一個純粹的內(nèi)存數(shù)據(jù)庫，不再運行 BGSAVE 。

這個監(jiān)護進程同時也做數(shù)據(jù)落地。對于數(shù)據(jù)落地，我選擇的是 unqlite ，幾行代碼就可以做好它的 Lua 封裝。它的數(shù)據(jù)庫文件只有一個，更方便做冷備。當(dāng)然 levelDB 也是個不錯的選擇，如果它是用 C 而不是 C++ 實現(xiàn)的話，我會考慮后者的。

和游戲服務(wù)器的對接，我在數(shù)據(jù)庫機器上啟動了一個獨立的 skynet 進程，監(jiān)聽同步 ID 的請求。因為它只需要處理很簡單幾個 Redis 操作，我特地手寫了 Redis 指令。最終這個服務(wù) 只有一個 lua 腳本 ，其實它是由三個 skynet 服務(wù)構(gòu)成的，一個監(jiān)聽外部端口，一個處理連接上的 Redis 同步指令，一個單點寫入數(shù)據(jù)到 unqlite 。為了使得數(shù)據(jù)恢復(fù)高效，我特地在保存玩家數(shù)據(jù)的時候，把恢復(fù)用的 Redis 指令拼好。這樣一旦需要恢復(fù)，只用從 unqlite 中讀出玩家數(shù)據(jù)，直接發(fā)送給 Redis 即可。

有了這個東西，就一并把 Redis 中的冷熱數(shù)據(jù)解決了。長期不登陸的玩家，我們可以定期從 Redis 中清掉，萬一這個玩家登陸回來，只需要讓它幫忙恢復(fù)。

曉靖不喜歡我依賴 skynet 的實現(xiàn)。他一開始想用 python 實現(xiàn)一個同樣的東西，后來他又對 Go 語言產(chǎn)生了興趣，想借這個需求玩一下 Go 語言。所以到今天，我們還沒有把這套新機制部署到生產(chǎn)環(huán)境。

原文地址。51CTO獲作者授權(quán)轉(zhuǎn)載。