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

1、引言

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

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

2、關(guān)于作者

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

3、陌陌的主要IM業(yè)務(wù)場(chǎng)景特點(diǎn)

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

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

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

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

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

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

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

在公司的成長(zhǎng)過(guò)程中，存儲(chǔ)選型通常會(huì)經(jīng)歷四個(gè)階段。

4.1初始階段

公司的主要目標(biāo)是能夠運(yùn)行起來(lái)。

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

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

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

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

4.2第二階段

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

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

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

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

4.3第三階段

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

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

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

4.4第四階段

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

這時(shí)，可以通過(guò)引入更穩(wěn)定的架構(gòu)或者采用新的解決思路來(lái)應(yīng)對(duì)挑戰(zhàn)。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

所以，陌陌需要通過(guò)一個(gè)簡(jiǎn)單可靠可擴(kuò)展的 KV 系統(tǒng)來(lái)解決以上問(wèn)題。

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

6.1OceanBase

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

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

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

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

6.2關(guān)于性能

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

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

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

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

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

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

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

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

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

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

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

陌陌與 OceanBase 開(kāi)源團(tuán)隊(duì)共同打造了一個(gè)內(nèi)部代號(hào)為 modis 的項(xiàng)目。

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

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

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

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

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

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

具體是：

• 1）P90 響應(yīng)延遲為 1.9 ms；
• 2）P95 響應(yīng)延遲為 2.2 ms；
• 3）P99響應(yīng)延遲為6.3 ms；

平均計(jì)算下來(lái)，單核讀寫(xiě)比例是 4:1，此時(shí)單核能力接近 6000 QPS。

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

總的來(lái)說(shuō)，OceanBase（OBKV）-Redis 實(shí)現(xiàn)了性能的顯著提升、更少的磁盤(pán)使用以及運(yùn)維管理的極大簡(jiǎn)化。

這主要得益于 OceanBase（OBKV）-Redis 的幾個(gè)優(yōu)勢(shì)：

• 1）多租戶隔離，解決單機(jī)多實(shí)例互相影響的困境；
• 2）存儲(chǔ)成本更低。通過(guò) Encoding 框架 + 通用壓縮 ，進(jìn)行表模型存儲(chǔ)；
• 3）性能更高。將請(qǐng)求過(guò)濾直接下壓存儲(chǔ)，不用序列化以及反序列化，支持服務(wù)端 TTL。

8、相關(guān)文章

[1] 知乎技術(shù)分享：從單機(jī)到2000萬(wàn)QPS并發(fā)的Redis高性能緩存實(shí)踐之路

[2] 微信后臺(tái)基于時(shí)間序的新一代海量數(shù)據(jù)存儲(chǔ)架構(gòu)的設(shè)計(jì)實(shí)踐

[3] 現(xiàn)代IM系統(tǒng)中聊天消息的同步和存儲(chǔ)方案探討

[4] 騰訊TEG團(tuán)隊(duì)原創(chuàng)：基于MySQL的分布式數(shù)據(jù)庫(kù)TDSQL十年鍛造經(jīng)驗(yàn)分享

[5] 社交軟件紅包技術(shù)解密(六)：微信紅包系統(tǒng)的存儲(chǔ)層架構(gòu)演進(jìn)實(shí)踐

[6] 微信技術(shù)分享：揭秘微信后臺(tái)安全特征數(shù)據(jù)倉(cāng)庫(kù)的架構(gòu)設(shè)計(jì)

[7] 阿里技術(shù)分享：深度揭秘阿里數(shù)據(jù)庫(kù)技術(shù)方案的10年變遷史

[8] 阿里技術(shù)分享：阿里自研金融級(jí)數(shù)據(jù)庫(kù)OceanBase的艱辛成長(zhǎng)之路

[9] 阿里IM技術(shù)分享(九)：深度揭密RocketMQ在釘釘IM系統(tǒng)中的應(yīng)用實(shí)踐

[10] 阿里IM技術(shù)分享(七)：閑魚(yú)IM的在線、離線聊天數(shù)據(jù)同步機(jī)制優(yōu)化實(shí)踐

[11] 阿里IM技術(shù)分享(八)：深度解密釘釘即時(shí)消息服務(wù)DTIM的技術(shù)設(shè)計(jì)

[12] IM開(kāi)發(fā)基礎(chǔ)知識(shí)補(bǔ)課(六)：數(shù)據(jù)庫(kù)用NoSQL還是SQL？讀這篇就夠了！

[13] 小紅書(shū)萬(wàn)億級(jí)社交網(wǎng)絡(luò)關(guān)系下的圖存儲(chǔ)系統(tǒng)的架構(gòu)設(shè)計(jì)與實(shí)踐

[14] IM開(kāi)發(fā)基礎(chǔ)知識(shí)補(bǔ)課(三)：快速理解服務(wù)端數(shù)據(jù)庫(kù)讀寫(xiě)分離原理及實(shí)踐建議

[15] 微信后臺(tái)基于時(shí)間序的海量數(shù)據(jù)冷熱分級(jí)架構(gòu)設(shè)計(jì)實(shí)踐

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