本文由冀浩東分享，原題“單核QPS近6000S，陌陌基于OceanBase的持久化緩存探索與實踐”，為了閱讀便利，本文進行了排版和內容優化等。
1、引言
摯文集團于 2011 年 8 月推出了陌陌，這款立足地理位置服務的開放式移動視頻IM應用在中國社交平臺領域內獨樹一幟。陌陌和探探作為陌生人社交領域的主流IM應用，涵蓋了多種核心業務模塊，包括直播服務、附近動態功能、即時通訊（IM）業務以及增值服務等，每個業務場景都具有其獨特性和挑戰。
在本文中，陌陌數據庫負責人冀浩東將聚焦探討陌陌的 KV 系統架構選型思路，深入解析如何進行此類系統的甄選決策，同時進一步分享陌陌團隊在采用 OceanBase（OBKV）過程中所經歷的探索與實踐經驗。
2、關于作者
冀浩東：陌陌（現摯文集團）數據庫負責人。目前負責陌陌和探探兩個數據庫團隊建設以及集團數據庫存儲運營工作。在大規模數據源穩定性建設 、團隊建設、成本優化、機房遷移等方面等領域積累了深厚的專業經驗與實戰心得。
3、陌陌的主要IM業務場景特點
1）直播業務：在陌陌眾多業務場景中，直播業務占據了顯著位置，其特點就在于隨時可能出現的流量突發場景。由于低延時和高并發的需求，直播場景對數據庫系統的實時處理能力提出了較高要求。平臺需要確保在大量用戶同時在線觀看和互動時，數據能夠被及時、準確地處理和分發。
2）附近動態：此功能則涉及到用戶的地理位置信息、活動軌跡以及社交關系等復雜數據。這類數據會迅速積累，并隨著時間的推移形成大規模的數據集。數據具有明顯的冷熱分層特性，即某些數據在某一時刻可能會成為熱點，如當某用戶發布的帖子引發熱議并成為熱門話題時。這要求系統能夠有效管理并快速響應熱點數據的訪問需求。
3）IM 業務：此場景的核心特點是低延遲和高并發通信。信息的送達時間必須精確，對實時性有極高的要求。為了保證用戶體驗，應用程序需要確保消息能夠即時、可靠地在用戶之間傳遞。
4）增值服務：則主要側重于數據的一致性和實時性。在處理用戶購買、贈送虛擬物品或享受會員特權等操作時，系統需要確保數據的準確性并及時更新用戶賬戶狀態。同時，為了提供優質的增值服務，實時性也是不可或缺的因素，例如實時計算用戶的積分、等級或者權益等。
陌陌和探探在運營這些業務場景時，都需要強大的數據處理和管理系統來應對各種特性和挑戰，以確保為用戶提供高效、穩定且滿足個性化需求的社交體驗。
針對以上的業務場景，我們應該如何選擇 KV 系統呢？
4、陌陌后端KV緩存架構的演進階段
在公司的成長過程中，存儲選型通常會經歷四個階段。
4.1初始階段
公司的主要目標是能夠運行起來。
在創業初期，基于新開發的 App 進行運營工作時，由于業務能力可能還未成熟，為了應對快速迭代的業務需求，對系統的期望不會過高。只需要確保技術層面能夠滿足基本的業務需求并逐步演進即可。在這個階段，常見的架構選擇包括 Redis 主從架構和 Redis Cluster 等原生架構。
Redis 主從集群架構的優勢在于可以迅速構建主從集群或分片集群，并且許多設計可以直接在客戶端操作。然而，這種簡單的操作方式可能導致設計與客戶端業務代碼的高度耦合，不利于后期的彈性擴容。
相比之下，Redis Cluster 集群架構支持動態擴容和高可用性。
然而，使用 Redis Cluster 時，業務依賴客戶端感知節點變更。如果客戶端未能正確處理節點變更，可能會導致服務中斷或業務性能下降，因此對于對錯誤敏感的業務，Redis Cluster 可能會引入額外的復雜性。盡管 Redis Cluster 具有去中心化、組件少、提供 Smart Client 以及支持水平擴展等優點，但也存在批處理功能不友好和缺乏有效流控機制等問題。
4.2第二階段
進入第二階段，隨著公司的發展和用戶數量的增長，需要架構具備快速擴展的能力。
這一階段的代表性架構例如 Codis、Twemproxy 等基礎性 Redis分片架構。
其中，Codis提供了服務端分片方案、中心化管理、故障自動轉移、節點水平擴展（1024 槽位）、動態擴縮容，以及支持 pipeline 和批處理等功能。
然而，Codis的當前版本較為陳舊，官方僅提供 3.2.9 版本，更新版本需要自行修復和適配，且由于組件多、資源消耗大。
4.3第三階段
隨著業務的進一步發展和公司進入相對穩定期，可能會發現先前急于擴張時遺留了一些問題。
例如：是否過度使用內存，數據是否可以冷熱分層等。這些問題需要重新檢驗和優化。這個優化過程是第三階段的重點。
在這個階段，常見的持久化架構選擇包括 oneStore-Pika、Tendis 和 Pika 等。
4.4第四階段
最后，在第四階段，公司業務和技術可能已經進入了深度復雜的領域，簡單的優化調整可能無法帶來顯著的收益，甚至可能出現無法進一步優化的情況。
這時，可以通過引入更穩定的架構或者采用新的解決思路來應對挑戰。
我們個人推薦考慮多模態架構，它能夠適應多種數據類型和工作負載，提供更大的靈活性和優化空間。
總的來說，公司在不同發展階段的存儲選型應根據業務需求、技術成熟度、成本效益以及未來的擴展性和優化空間等因素進行綜合考慮和決策。隨著公司的發展和業務復雜性的增加，存儲架構也需要不斷進化和優化，以確保系統的穩定、高效和可持續發展。
5、陌陌自研的KV緩存“oneStore”
針對當前公司的業務狀況，陌陌面臨的最顯著挑戰在于集群規模的不斷增長。
當單集群分片數量超過 1000 個，數據量超過 10TB，以及 QPS 超過 100 萬時，現有的 Codis 架構和 Redis Cluster 架構已然無法滿足需求，達到了其承載能力的極限。
為了解決這一瓶頸問題，公司自主研發了一款名為 oneStore 的存儲產品（如下圖所示）。
這一架構經過了分階段的優化和改進過程，旨在突破原有的限制，以適應更高的分片數量、更大的數據量以及更密集的查詢請求。通過 oneStore 架構，陌陌力求實現業務擴展的無縫對接和性能的大幅提升。
1）第一階段：提供服務端 Proxy 方案，并通過自主研發的 oneStore Watcher 哨兵組件進行架構精簡。這樣一來，只需要部署一套哨兵集群，就能有效地管理一個業務區域。
2）第二階段：提供客戶端 SDK 方案。雖然服務端 Proxy 方案表現優秀，但隨著業務的穩定，公司著眼于降本增效。直接使用客戶端 SDK 方案，感知集群拓撲變化，并且通過 SDK 直連后端 Redis 地址，這樣可以去除服務端 Proxy 組件，節省技術資源開銷。然而，我們并沒有完全摒棄服務端 Proxy 方案。因為目前陌陌的客戶端 SDK 方案僅支持 Java 和 C++，對于 PHP、Python 等其他語言的用戶，仍需要通過服務端 Proxy 訪問數據源。這兩種方案的成功運用，幫助我們統一了公司層面 Redis 的接入方式，并顯著提升了機房遷移的效率。
隨著業務的進一步穩定，陌陌開始從成本角度進行優化，選擇 Pika 替代部分請求量不高的 Redis 集群，再提升架構的持久化能力（如下圖所示）的同時降低存儲成本。
然而現階段 Pika 主要用來存儲一些相對較冷數據，對于熱數據的處理性能仍有待提高，后續團隊也會持續關注并努力提升這一方面的性能。
總的來說，目前陌陌還面臨一些需要解決和優化的場景：
1）單機多實例之間互相影響的問題：陌陌迫切需要解決單機多實例之間相互影響的問題，以確保各個實例的穩定運行和高效協作。這涉及到系統的整體穩定性和協同性，需要有針對性的優化和調整。
2）數據持久化支持：陌陌計劃增強數據持久化的支持能力，以實現完整的數據持久化解決方案，以保障數據的完整性和可靠性。不僅僅局限于冷數據，而是要覆蓋更廣泛的數據類型，以確保數據的完整性和可靠性。這將是系統長期穩定性的一個重要保障。
所以，陌陌需要通過一個簡單可靠可擴展的 KV 系統來解決以上問題。
6、陌陌的分布式KV緩存選型
6.1OceanBase
OBKV 是 OceanBase 數據庫提供的通過 API 接口訪問 Table 模型 Hbase 模型的能力。
之所以選擇 OceanBase（OBKV），主要看中其兩大優勢：
6.2關于性能
OceanBase（OBKV）基于 Table 模型構建，與 Redis 數據結構持久化方案這個典型的表模型匹配，且性能比傳統持久化存儲更強 ，能構建更豐富的數據結構。
下圖是OceanBase（OBKV）在大量寫數據的場景（TPS 17000），由于不同階段都有任務在寫數據，可以看出 TPS 非常陡峭，并且響應延時在 2 毫秒以下，事務的響應時間明細與預期是相對應的。
下圖為 CPU 監控圖：可以看到 CPU 使用率在 10% 以下，相對穩定。MemStore 的使用比例也是正常的，在 24% 以內，波動范圍非常小，符合預期。
整體來看：OceanBase（OBKV） 生產環境波動小，資源占用穩定。
6.3關于穩定性
OceanBase（OBKV）基于 OceanBase ，存儲引擎經過豐富的大規模 TP 場景驗證，能提供高并發、低延時的能力。
從下圖OceanBase（OBKV） 的多租戶功能可見其穩定性。黑色線代表OceanBase（OBKV）租戶，藍色線的租戶是 MySQL 租戶。在 11:30 左右發起壓測以后，OceanBase（OBKV） 租戶的響應正常， MySQL 租戶也沒有受到影響。從服務器層面來看，CPU 負載是因為壓測而上升的，而 MySQL 租戶并不受影響。
因此可以得出：多租戶功能能夠有效解決單機多實例的相互影響問題。下圖展示了是線上 MySQL 生產租戶的表現，TPS 為 5000時，整體表現非常穩定。CPU 和內存使用波動較小，符合預期。
此外：能夠便捷地通過 KV 接口將數據存入數據庫，并運用 SQL 進行數據查詢。OceanBase（OBKV）進一步增強了這一便捷性，支持二級索引以及服務端TTL功能，這有助于顯著簡化上層服務架構的設計。
盡管如此，OceanBase（OBKV）也存在一定的局限性，如僅提供單機事務處理能力；若要開啟分布式事務支持，則可能會影響到系統在高并發環境下的性能表現和低延時響應能力。但鑒于當前陌陌業務的需求，我們認為OceanBase（OBKV）的單機事務能力完全符合要求，并因此共同構建了結合OceanBase（OBKV）- Redis 儲存方案。
7、陌陌的分布式KV集群架構改進
陌陌與 OceanBase 開源團隊共同打造了一個內部代號為 modis 的項目。
該項目整體架構涵蓋了接入層、數據結構層、緩沖層、存儲層以及管理平面等多個層次（具體可參考下圖）。
值得注意的是：緩沖層在未來的規劃中將用于有效解決熱點讀取及大 KEY 問題的挑戰。而在存儲層方面，陌陌將對其進行標準化抽象設計，構建出標準的 Storage 結構，以便能夠靈活接入包括但不限于OceanBase（OBKV）在內的多種存儲解決方案。
在測試評估過程中，將 Pika 數據（總計 158GB）成功遷移到 OceanBase（OBKV）-Redis 集群后，存儲占用空間顯著減少至 95GB，這一舉措帶來了存儲成本的顯著優化，總體上節約了大約 40% 的存儲成本。
為了評估性能表現，特意構建了一個專門的測試環境（具體規格參見下圖），并在該環境中模擬了不同并發線程場景以觀測其峰值性能情況。
基于多租戶管理的思路，不會對單一租戶分配過多資源，而是優先觀察各個租戶在使用過程中哪個率先達到性能瓶頸，并據此計算單核的 QPS。當前，陌陌提供的標準規格為 12C40G 內存。未來，為了更好地適應業務需求的變化，可能會推出更小規格的配置方案，例如 4C8G 或 8C16G 等規格，這些決策將完全取決于實際業務的具體需要。
下圖展示了 128 個線程數 QPS 70000 情況下 OceanBase（OBKV）-Redis 的性能表現。
具體是：
- 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）提供了原生的多租戶支持功能，這一優勢有效地解決了在單機部署多實例時所面臨的相互干擾的問題。值得一提的是，OceanBase（OBKV）憑借完備的圖形化界面管理工具和參數變更即刻生效的特點，對于數據庫運維工作來說，無疑是極其貼心且高效的解決方案。
總的來說，OceanBase（OBKV）-Redis 實現了性能的顯著提升、更少的磁盤使用以及運維管理的極大簡化。
這主要得益于 OceanBase（OBKV）-Redis 的幾個優勢：
- 1）多租戶隔離，解決單機多實例互相影響的困境；
- 2）存儲成本更低。通過 Encoding 框架 + 通用壓縮 ，進行表模型存儲；
- 3）性能更高。將請求過濾直接下壓存儲，不用序列化以及反序列化，支持服務端 TTL。
8、相關文章
[1] 知乎技術分享：從單機到2000萬QPS并發的Redis高性能緩存實踐之路
[2] 微信后臺基于時間序的新一代海量數據存儲架構的設計實踐
[3] 現代IM系統中聊天消息的同步和存儲方案探討
[4] 騰訊TEG團隊原創：基于MySQL的分布式數據庫TDSQL十年鍛造經驗分享
[5] 社交軟件紅包技術解密(六)：微信紅包系統的存儲層架構演進實踐
[6] 微信技術分享：揭秘微信后臺安全特征數據倉庫的架構設計
[7] 阿里技術分享：深度揭秘阿里數據庫技術方案的10年變遷史
[8] 阿里技術分享：阿里自研金融級數據庫OceanBase的艱辛成長之路
[9] 阿里IM技術分享(九)：深度揭密RocketMQ在釘釘IM系統中的應用實踐
[10] 阿里IM技術分享(七)：閑魚IM的在線、離線聊天數據同步機制優化實踐
[11] 阿里IM技術分享(八)：深度解密釘釘即時消息服務DTIM的技術設計
[12] IM開發基礎知識補課(六)：數據庫用NoSQL還是SQL？讀這篇就夠了！
[13] 小紅書萬億級社交網絡關系下的圖存儲系統的架構設計與實踐
[14] IM開發基礎知識補課(三)：快速理解服務端數據庫讀寫分離原理及實踐建議
[15] 微信后臺基于時間序的海量數據冷熱分級架構設計實踐
（本文已同步發布于：http://www.52im.net/thread-4627-1-1.html）