陌陌技術(shù)分享：陌陌IM在后端KV緩存架構(gòu)上的技術(shù)實踐

Posted on 2024-03-14 12:09 Jack Jiang 閱讀(24) 評論(0) 編輯收藏

本文由冀浩東分享，原題“單核QPS近6000S，陌陌基于OceanBase的持久化緩存探索與實踐”，為了閱讀便利，本文進行了排版和內(nèi)容優(yōu)化等。

1、引言

摯文集團于 2011 年 8 月推出了陌陌，這款立足地理位置服務的開放式移動視頻IM應用在中國社交平臺領(lǐng)域內(nèi)獨樹一幟。陌陌和探探作為陌生人社交領(lǐng)域的主流IM應用，涵蓋了多種核心業(yè)務模塊，包括直播服務、附近動態(tài)功能、即時通訊（IM）業(yè)務以及增值服務等，每個業(yè)務場景都具有其獨特性和挑戰(zhàn)。

在本文中，陌陌數(shù)據(jù)庫負責人冀浩東將聚焦探討陌陌的 KV 系統(tǒng)架構(gòu)選型思路，深入解析如何進行此類系統(tǒng)的甄選決策，同時進一步分享陌陌團隊在采用 OceanBase（OBKV）過程中所經(jīng)歷的探索與實踐經(jīng)驗。

技術(shù)交流：

- 移動端IM開發(fā)入門文章：《新手入門一篇就夠：從零開發(fā)移動端IM》

- 開源IM框架源碼：https://github.com/JackJiang2011/MobileIMSDK（備用地址點此）

（本文已同步發(fā)布于：http://www.52im.net/thread-4627-1-1.html）

2、關(guān)于作者

冀浩東：陌陌（現(xiàn)摯文集團）數(shù)據(jù)庫負責人。目前負責陌陌和探探兩個數(shù)據(jù)庫團隊建設以及集團數(shù)據(jù)庫存儲運營工作。在大規(guī)模數(shù)據(jù)源穩(wěn)定性建設、團隊建設、成本優(yōu)化、機房遷移等方面等領(lǐng)域積累了深厚的專業(yè)經(jīng)驗與實戰(zhàn)心得。

3、陌陌的主要IM業(yè)務場景特點

1）直播業(yè)務：在陌陌眾多業(yè)務場景中，直播業(yè)務占據(jù)了顯著位置，其特點就在于隨時可能出現(xiàn)的流量突發(fā)場景。由于低延時和高并發(fā)的需求，直播場景對數(shù)據(jù)庫系統(tǒng)的實時處理能力提出了較高要求。平臺需要確保在大量用戶同時在線觀看和互動時，數(shù)據(jù)能夠被及時、準確地處理和分發(fā)。

2）附近動態(tài)：此功能則涉及到用戶的地理位置信息、活動軌跡以及社交關(guān)系等復雜數(shù)據(jù)。這類數(shù)據(jù)會迅速積累，并隨著時間的推移形成大規(guī)模的數(shù)據(jù)集。數(shù)據(jù)具有明顯的冷熱分層特性，即某些數(shù)據(jù)在某一時刻可能會成為熱點，如當某用戶發(fā)布的帖子引發(fā)熱議并成為熱門話題時。這要求系統(tǒng)能夠有效管理并快速響應熱點數(shù)據(jù)的訪問需求。

3）IM 業(yè)務：此場景的核心特點是低延遲和高并發(fā)通信。信息的送達時間必須精確，對實時性有極高的要求。為了保證用戶體驗，應用程序需要確保消息能夠即時、可靠地在用戶之間傳遞。

4）增值服務：則主要側(cè)重于數(shù)據(jù)的一致性和實時性。在處理用戶購買、贈送虛擬物品或享受會員特權(quán)等操作時，系統(tǒng)需要確保數(shù)據(jù)的準確性并及時更新用戶賬戶狀態(tài)。同時，為了提供優(yōu)質(zhì)的增值服務，實時性也是不可或缺的因素，例如實時計算用戶的積分、等級或者權(quán)益等。

陌陌和探探在運營這些業(yè)務場景時，都需要強大的數(shù)據(jù)處理和管理系統(tǒng)來應對各種特性和挑戰(zhàn)，以確保為用戶提供高效、穩(wěn)定且滿足個性化需求的社交體驗。

針對以上的業(yè)務場景，我們應該如何選擇 KV 系統(tǒng)呢？

4、陌陌后端KV緩存架構(gòu)的演進階段

在公司的成長過程中，存儲選型通常會經(jīng)歷四個階段。

4.1初始階段

公司的主要目標是能夠運行起來。

在創(chuàng)業(yè)初期，基于新開發(fā)的 App 進行運營工作時，由于業(yè)務能力可能還未成熟，為了應對快速迭代的業(yè)務需求，對系統(tǒng)的期望不會過高。只需要確保技術(shù)層面能夠滿足基本的業(yè)務需求并逐步演進即可。在這個階段，常見的架構(gòu)選擇包括 Redis 主從架構(gòu)和 Redis Cluster 等原生架構(gòu)。

Redis 主從集群架構(gòu)的優(yōu)勢在于可以迅速構(gòu)建主從集群或分片集群，并且許多設計可以直接在客戶端操作。然而，這種簡單的操作方式可能導致設計與客戶端業(yè)務代碼的高度耦合，不利于后期的彈性擴容。

相比之下，Redis Cluster 集群架構(gòu)支持動態(tài)擴容和高可用性。

然而，使用 Redis Cluster 時，業(yè)務依賴客戶端感知節(jié)點變更。如果客戶端未能正確處理節(jié)點變更，可能會導致服務中斷或業(yè)務性能下降，因此對于對錯誤敏感的業(yè)務，Redis Cluster 可能會引入額外的復雜性。盡管 Redis Cluster 具有去中心化、組件少、提供 Smart Client 以及支持水平擴展等優(yōu)點，但也存在批處理功能不友好和缺乏有效流控機制等問題。

4.2第二階段

進入第二階段，隨著公司的發(fā)展和用戶數(shù)量的增長，需要架構(gòu)具備快速擴展的能力。

這一階段的代表性架構(gòu)例如 Codis、Twemproxy 等基礎性 Redis分片架構(gòu)。

其中，Codis提供了服務端分片方案、中心化管理、故障自動轉(zhuǎn)移、節(jié)點水平擴展（1024 槽位）、動態(tài)擴縮容，以及支持 pipeline 和批處理等功能。

然而，Codis的當前版本較為陳舊，官方僅提供 3.2.9 版本，更新版本需要自行修復和適配，且由于組件多、資源消耗大。

4.3第三階段

隨著業(yè)務的進一步發(fā)展和公司進入相對穩(wěn)定期，可能會發(fā)現(xiàn)先前急于擴張時遺留了一些問題。

例如：是否過度使用內(nèi)存，數(shù)據(jù)是否可以冷熱分層等。這些問題需要重新檢驗和優(yōu)化。這個優(yōu)化過程是第三階段的重點。

在這個階段，常見的持久化架構(gòu)選擇包括 oneStore-Pika、Tendis 和 Pika 等。

4.4第四階段

最后，在第四階段，公司業(yè)務和技術(shù)可能已經(jīng)進入了深度復雜的領(lǐng)域，簡單的優(yōu)化調(diào)整可能無法帶來顯著的收益，甚至可能出現(xiàn)無法進一步優(yōu)化的情況。

這時，可以通過引入更穩(wěn)定的架構(gòu)或者采用新的解決思路來應對挑戰(zhàn)。

我們個人推薦考慮多模態(tài)架構(gòu)，它能夠適應多種數(shù)據(jù)類型和工作負載，提供更大的靈活性和優(yōu)化空間。

總的來說，公司在不同發(fā)展階段的存儲選型應根據(jù)業(yè)務需求、技術(shù)成熟度、成本效益以及未來的擴展性和優(yōu)化空間等因素進行綜合考慮和決策。隨著公司的發(fā)展和業(yè)務復雜性的增加，存儲架構(gòu)也需要不斷進化和優(yōu)化，以確保系統(tǒng)的穩(wěn)定、高效和可持續(xù)發(fā)展。

5、陌陌自研的KV緩存“oneStore”

針對當前公司的業(yè)務狀況，陌陌面臨的最顯著挑戰(zhàn)在于集群規(guī)模的不斷增長。

當單集群分片數(shù)量超過 1000 個，數(shù)據(jù)量超過 10TB，以及 QPS 超過 100 萬時，現(xiàn)有的 Codis 架構(gòu)和 Redis Cluster 架構(gòu)已然無法滿足需求，達到了其承載能力的極限。

為了解決這一瓶頸問題，公司自主研發(fā)了一款名為 oneStore 的存儲產(chǎn)品（如下圖所示）。

這一架構(gòu)經(jīng)過了分階段的優(yōu)化和改進過程，旨在突破原有的限制，以適應更高的分片數(shù)量、更大的數(shù)據(jù)量以及更密集的查詢請求。通過 oneStore 架構(gòu)，陌陌力求實現(xiàn)業(yè)務擴展的無縫對接和性能的大幅提升。

1）第一階段：提供服務端 Proxy 方案，并通過自主研發(fā)的 oneStore Watcher 哨兵組件進行架構(gòu)精簡。這樣一來，只需要部署一套哨兵集群，就能有效地管理一個業(yè)務區(qū)域。

2）第二階段：提供客戶端 SDK 方案。雖然服務端 Proxy 方案表現(xiàn)優(yōu)秀，但隨著業(yè)務的穩(wěn)定，公司著眼于降本增效。直接使用客戶端 SDK 方案，感知集群拓撲變化，并且通過 SDK 直連后端 Redis 地址，這樣可以去除服務端 Proxy 組件，節(jié)省技術(shù)資源開銷。然而，我們并沒有完全摒棄服務端 Proxy 方案。因為目前陌陌的客戶端 SDK 方案僅支持 Java 和 C++，對于 PHP、Python 等其他語言的用戶，仍需要通過服務端 Proxy 訪問數(shù)據(jù)源。這兩種方案的成功運用，幫助我們統(tǒng)一了公司層面 Redis 的接入方式，并顯著提升了機房遷移的效率。

隨著業(yè)務的進一步穩(wěn)定，陌陌開始從成本角度進行優(yōu)化，選擇 Pika 替代部分請求量不高的 Redis 集群，再提升架構(gòu)的持久化能力（如下圖所示）的同時降低存儲成本。

然而現(xiàn)階段 Pika 主要用來存儲一些相對較冷數(shù)據(jù)，對于熱數(shù)據(jù)的處理性能仍有待提高，后續(xù)團隊也會持續(xù)關(guān)注并努力提升這一方面的性能。

總的來說，目前陌陌還面臨一些需要解決和優(yōu)化的場景：

1）單機多實例之間互相影響的問題：陌陌迫切需要解決單機多實例之間相互影響的問題，以確保各個實例的穩(wěn)定運行和高效協(xié)作。這涉及到系統(tǒng)的整體穩(wěn)定性和協(xié)同性，需要有針對性的優(yōu)化和調(diào)整。

2）數(shù)據(jù)持久化支持：陌陌計劃增強數(shù)據(jù)持久化的支持能力，以實現(xiàn)完整的數(shù)據(jù)持久化解決方案，以保障數(shù)據(jù)的完整性和可靠性。不僅僅局限于冷數(shù)據(jù)，而是要覆蓋更廣泛的數(shù)據(jù)類型，以確保數(shù)據(jù)的完整性和可靠性。這將是系統(tǒng)長期穩(wěn)定性的一個重要保障。

所以，陌陌需要通過一個簡單可靠可擴展的 KV 系統(tǒng)來解決以上問題。

6、陌陌的分布式KV緩存選型

6.1OceanBase

OBKV 是 OceanBase 數(shù)據(jù)庫提供的通過 API 接口訪問 Table 模型 Hbase 模型的能力。

有關(guān)OceanBase 數(shù)據(jù)庫的來歷，詳見：《阿里技術(shù)分享：阿里自研金融級數(shù)據(jù)庫OceanBase的艱辛成長之路。

之所以選擇 OceanBase（OBKV），主要看中其兩大優(yōu)勢：

1）性能更好；
2）穩(wěn)定性高。

6.2關(guān)于性能

OceanBase（OBKV）基于 Table 模型構(gòu)建，與 Redis 數(shù)據(jù)結(jié)構(gòu)持久化方案這個典型的表模型匹配，且性能比傳統(tǒng)持久化存儲更強，能構(gòu)建更豐富的數(shù)據(jù)結(jié)構(gòu)。

下圖是OceanBase（OBKV）在大量寫數(shù)據(jù)的場景（TPS 17000），由于不同階段都有任務在寫數(shù)據(jù)，可以看出 TPS 非常陡峭，并且響應延時在 2 毫秒以下，事務的響應時間明細與預期是相對應的。

下圖為 CPU 監(jiān)控圖：可以看到 CPU 使用率在 10% 以下，相對穩(wěn)定。MemStore 的使用比例也是正常的，在 24% 以內(nèi)，波動范圍非常小，符合預期。

整體來看：OceanBase（OBKV）生產(chǎn)環(huán)境波動小，資源占用穩(wěn)定。

6.3關(guān)于穩(wěn)定性

OceanBase（OBKV）基于 OceanBase ，存儲引擎經(jīng)過豐富的大規(guī)模 TP 場景驗證，能提供高并發(fā)、低延時的能力。

從下圖OceanBase（OBKV）的多租戶功能可見其穩(wěn)定性。黑色線代表OceanBase（OBKV）租戶，藍色線的租戶是 MySQL 租戶。在 11:30 左右發(fā)起壓測以后，OceanBase（OBKV）租戶的響應正常， MySQL 租戶也沒有受到影響。從服務器層面來看，CPU 負載是因為壓測而上升的，而 MySQL 租戶并不受影響。

因此可以得出：多租戶功能能夠有效解決單機多實例的相互影響問題。下圖展示了是線上 MySQL 生產(chǎn)租戶的表現(xiàn)，TPS 為 5000時，整體表現(xiàn)非常穩(wěn)定。CPU 和內(nèi)存使用波動較小，符合預期。

此外：能夠便捷地通過 KV 接口將數(shù)據(jù)存入數(shù)據(jù)庫，并運用 SQL 進行數(shù)據(jù)查詢。OceanBase（OBKV）進一步增強了這一便捷性，支持二級索引以及服務端TTL功能，這有助于顯著簡化上層服務架構(gòu)的設計。

盡管如此，OceanBase（OBKV）也存在一定的局限性，如僅提供單機事務處理能力；若要開啟分布式事務支持，則可能會影響到系統(tǒng)在高并發(fā)環(huán)境下的性能表現(xiàn)和低延時響應能力。但鑒于當前陌陌業(yè)務的需求，我們認為OceanBase（OBKV）的單機事務能力完全符合要求，并因此共同構(gòu)建了結(jié)合OceanBase（OBKV）- Redis 儲存方案。

7、陌陌的分布式KV集群架構(gòu)改進

陌陌與 OceanBase 開源團隊共同打造了一個內(nèi)部代號為 modis 的項目。

該項目整體架構(gòu)涵蓋了接入層、數(shù)據(jù)結(jié)構(gòu)層、緩沖層、存儲層以及管理平面等多個層次（具體可參考下圖）。

值得注意的是：緩沖層在未來的規(guī)劃中將用于有效解決熱點讀取及大 KEY 問題的挑戰(zhàn)。而在存儲層方面，陌陌將對其進行標準化抽象設計，構(gòu)建出標準的 Storage 結(jié)構(gòu)，以便能夠靈活接入包括但不限于OceanBase（OBKV）在內(nèi)的多種存儲解決方案。

在測試評估過程中，將 Pika 數(shù)據(jù)（總計 158GB）成功遷移到 OceanBase（OBKV）-Redis 集群后，存儲占用空間顯著減少至 95GB，這一舉措帶來了存儲成本的顯著優(yōu)化，總體上節(jié)約了大約 40% 的存儲成本。

為了評估性能表現(xiàn)，特意構(gòu)建了一個專門的測試環(huán)境（具體規(guī)格參見下圖），并在該環(huán)境中模擬了不同并發(fā)線程場景以觀測其峰值性能情況。

基于多租戶管理的思路，不會對單一租戶分配過多資源，而是優(yōu)先觀察各個租戶在使用過程中哪個率先達到性能瓶頸，并據(jù)此計算單核的 QPS。當前，陌陌提供的標準規(guī)格為 12C40G 內(nèi)存。未來，為了更好地適應業(yè)務需求的變化，可能會推出更小規(guī)格的配置方案，例如 4C8G 或 8C16G 等規(guī)格，這些決策將完全取決于實際業(yè)務的具體需要。

下圖展示了 128 個線程數(shù) QPS 70000 情況下 OceanBase（OBKV）-Redis 的性能表現(xiàn)。

具體是：

1）P90 響應延遲為 1.9 ms；
2）P95 響應延遲為 2.2 ms；
3）P99響應延遲為6.3 ms；

平均計算下來，單核讀寫比例是 4:1，此時單核能力接近 6000 QPS。

此外：在運維管理方面，深入對比了 OceanBase（OBKV）、Pika 以及 TiKV 在日常運維操作中的特性差異。目前，只有 OceanBase（OBKV）提供了原生的多租戶支持功能，這一優(yōu)勢有效地解決了在單機部署多實例時所面臨的相互干擾的問題。值得一提的是，OceanBase（OBKV）憑借完備的圖形化界面管理工具和參數(shù)變更即刻生效的特點，對于數(shù)據(jù)庫運維工作來說，無疑是極其貼心且高效的解決方案。