本文由小紅書基礎(chǔ)架構(gòu)存儲(chǔ)組空洞和劉備分享，原題“小紅書如何應(yīng)對(duì)萬(wàn)億級(jí)社交網(wǎng)絡(luò)關(guān)系挑戰(zhàn)？圖存儲(chǔ)系統(tǒng) REDtao 來(lái)了！”，本文有修訂和改動(dòng)。

1、引言

小紅書是一個(gè)社區(qū)屬性為主的產(chǎn)品，它涵蓋了各個(gè)領(lǐng)域的生活社區(qū)，并存儲(chǔ)海量的社交網(wǎng)絡(luò)關(guān)系。

為了解決社交場(chǎng)景下超大規(guī)模數(shù)據(jù)的更新與關(guān)聯(lián)讀取問題，并減少數(shù)據(jù)庫(kù)壓力和成本，我們自研了面向超大規(guī)模社交網(wǎng)絡(luò)的圖存儲(chǔ)系統(tǒng) REDtao，大大提高了系統(tǒng)穩(wěn)定性。該系統(tǒng)借鑒了 Facebook 的圖存儲(chǔ)系統(tǒng)設(shè)計(jì)，將緩存和底層數(shù)據(jù)庫(kù)封裝起來(lái)，并對(duì)外提供統(tǒng)一的圖查詢 API，實(shí)現(xiàn)了訪問收斂，同時(shí)在緩存中實(shí)現(xiàn)了高效的邊聚合。

本文將為你分享小紅書面向超大規(guī)模社交網(wǎng)絡(luò)的圖存儲(chǔ)系統(tǒng)REDtao的架構(gòu)設(shè)計(jì)與技術(shù)實(shí)踐過程，希望能帶給你啟發(fā)。

?

?

技術(shù)交流：

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

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

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

2、關(guān)于作者

空洞：小紅書基礎(chǔ)架構(gòu)存儲(chǔ)組，負(fù)責(zé)圖存儲(chǔ)系統(tǒng) REDtao 和分布式緩存的研發(fā)。

劉備：小紅書基礎(chǔ)架構(gòu)存儲(chǔ)組負(fù)責(zé)人，負(fù)責(zé)REDkv / REDtao / REDtable / REDgraph 的整體架構(gòu)和技術(shù)演進(jìn)。

基礎(chǔ)架構(gòu)存儲(chǔ)組是給小紅書的業(yè)務(wù)部門提供穩(wěn)定可靠的存儲(chǔ)和數(shù)據(jù)庫(kù)服務(wù)，滿足業(yè)務(wù)對(duì)存儲(chǔ)產(chǎn)品的功能、性能、成本和穩(wěn)定性要求。目前負(fù)責(zé)自研分布式 KV、分布式緩存、圖存儲(chǔ)系統(tǒng)、圖數(shù)據(jù)庫(kù)和表格存儲(chǔ)。

已上線的存儲(chǔ)產(chǎn)品包括：

• 1）REDkv?: 分布式高性能 KV；

• 2）REDtao?：滿足一跳查詢的高性能圖存儲(chǔ)數(shù)據(jù)庫(kù)；

• 3）?REDtable?：提供 Schema 語(yǔ)義和二級(jí)索引的表格存儲(chǔ)；

• 4）?REDgraph?：提供兩跳及以上的圖語(yǔ)義查詢數(shù)據(jù)庫(kù)。

3、技術(shù)背景

小紅書是以年輕人為主的生活記錄、分享平臺(tái)，用戶可以通過短視頻、圖文等形式記錄生活點(diǎn)滴，分享生活方式。

在小紅書的社交領(lǐng)域里，我們有用戶、筆記、商品等實(shí)體，這些實(shí)體之間有各種各樣的關(guān)系。

例如：用戶與筆記之間可能存在“擁有”（發(fā)布）、“點(diǎn)贊”、“收藏”等三種關(guān)系，同時(shí)還存在對(duì)應(yīng)的反向關(guān)系“被點(diǎn)贊”，“被收藏”等。

小紅書的社交圖譜數(shù)據(jù)已經(jīng)達(dá)到了萬(wàn)億條邊的規(guī)模，且增長(zhǎng)速度非常快。當(dāng)用戶登陸小紅書時(shí)，每個(gè)用戶都會(huì)看到關(guān)注的好友、粉絲、點(diǎn)贊、收藏以及其他為其量身定做的內(nèi)容。

這些信息高度個(gè)性化，需要實(shí)時(shí)從這些海量社交關(guān)系數(shù)據(jù)中讀取用戶相關(guān)信息。這是一個(gè)讀為主的過程，讀取壓力非常大。

過去，我們將這些社交圖譜數(shù)據(jù)都存儲(chǔ)在運(yùn)維成熟的 MySQL 數(shù)據(jù)庫(kù)中。

然而，即使我們只有百萬(wàn)請(qǐng)求每秒的規(guī)模，MySQL 的 CPU 使用率仍然到達(dá)了 55% 。隨著用戶和 DAU 爆發(fā)式的增長(zhǎng)，需要不斷擴(kuò)容 MySQL 數(shù)據(jù)庫(kù)，這帶來(lái)了巨大的成本和穩(wěn)定性壓力。

為了解決這些問題且考慮到?jīng)]有合適的開源方案，2021 年初我們開啟了從 0 到 1 自研 REDtao 的歷程。

4、方案調(diào)研和API設(shè)計(jì)

4.1方案調(diào)研

我們充分調(diào)研了業(yè)內(nèi)其他廠商的實(shí)現(xiàn)，發(fā)現(xiàn)有著強(qiáng)社交屬性的公司基本上都有一個(gè)自研的圖存儲(chǔ)系統(tǒng)（如下圖所示）。

比如：

• 1）Facebook 實(shí)現(xiàn)了一個(gè)叫做 “TAO” 專門的分布式社交圖譜數(shù)據(jù)庫(kù)，并將其作為最核心的存儲(chǔ)系統(tǒng)；

• 2）Pinterest 和 Facebook 類似，也實(shí)現(xiàn)了類似的圖存儲(chǔ)系統(tǒng)；

• 3）字節(jié)跳動(dòng)自研了 ByteGraph 并將其用于存儲(chǔ)核心的社交圖譜數(shù)據(jù)；

• 4）Linkedln 在 KV 之上構(gòu)建了社交圖譜服務(wù)。

考慮到當(dāng)時(shí)我們的社交圖譜數(shù)據(jù)已經(jīng)存放在 MySQL 數(shù)據(jù)庫(kù)上且規(guī)模巨大，而社交圖譜數(shù)據(jù)服務(wù)是非常重要的服務(wù)，對(duì)穩(wěn)定性的要求非常高?；厮?Facebook 當(dāng)年遇到的問題和我們類似，數(shù)據(jù)存儲(chǔ)在 Memcache 和 MySQL 中。因此，參考 Facebook 的 Tao 圖存儲(chǔ)系統(tǒng)更貼合我們的實(shí)際情況和已有的技術(shù)架構(gòu)，風(fēng)險(xiǎn)更小。

4.2API設(shè)計(jì)

社交圖譜的訪問主要是邊的關(guān)系查詢。

我們的圖模型將關(guān)系表示為一個(gè)?<key, value>?對(duì)，其中 key 是 (?FromId,??AssocType,??ToId?) 的三元組，value?是屬性的??JSON 格式。

比如“用戶 A ”關(guān)注“用戶 B ”，映射到 REDtao 的數(shù)據(jù)存儲(chǔ)結(jié)構(gòu)為：

1<FromId:用戶A的ID, AssocType：關(guān)注， ToId：用戶B的ID>? ->? Value （屬性的json字段）

我們對(duì)業(yè)務(wù)方的需求進(jìn)行分析，封裝了 25 個(gè)圖語(yǔ)義的 API 給業(yè)務(wù)方使用，滿足了其增刪改查的需求，并收斂業(yè)務(wù)方的使用方式。

相比于 Facebook 的 Tao，我們還補(bǔ)充了社交圖譜所需要的圖語(yǔ)義，為反作弊場(chǎng)景提供了額外的過濾參數(shù)。

同時(shí)，在緩存層面，我們支持對(duì)不同的字段在緩存中配置局部二級(jí)索引。

下面給一些典型的使用場(chǎng)景。

1）場(chǎng)景一：獲取關(guān)注了 A 的所有正常用戶（并且剔除作弊用戶）：

1getAssocs(“被關(guān)注類型”, 用戶A的ID, 分頁(yè)偏移量, 最大返回值, 只返回正常用戶，是否按照時(shí)間從新到舊)

2）場(chǎng)景二：獲取 A 的粉絲個(gè)數(shù)（并且剔除作弊用戶）：

1getAssocCount(“被關(guān)注類型”, 用戶A的ID, 只返回正常用戶)

5、整體架構(gòu)設(shè)計(jì)

REDtao 的架構(gòu)設(shè)計(jì)考慮了下面這幾個(gè)關(guān)鍵的要素：

整體架構(gòu)分為三層：

• 1）接入層；

• 2）緩存層；

• 3）持久層。

業(yè)務(wù)方通過 REDtao SDK 接入服務(wù)。

如下圖：

在這個(gè)架構(gòu)中：和 Facebook Tao 不一樣的是，我們的緩存層是一個(gè)獨(dú)立的分布式集群，和下面的持久層是解耦的。緩存層和下面的持久層可以獨(dú)立的擴(kuò)容縮容，緩存分片和 MySQL 分片不需要一一對(duì)應(yīng)，這樣帶來(lái)了更好的靈活性，MySQL 集群也變成了一個(gè)可以插拔替換的持久存儲(chǔ)。

1）讀流程：客戶端將讀請(qǐng)求發(fā)送給 router，router 接收到 RPC 請(qǐng)求后，根據(jù)邊類型選擇對(duì)應(yīng)的 REDtao 集群，根據(jù)三元組 (?FromId,??AssocType,??ToId?) 通過一致性 Hash 計(jì)算出分片所在的 Follower 節(jié)點(diǎn)，將請(qǐng)求轉(zhuǎn)發(fā)到該節(jié)點(diǎn)上。Follower 節(jié)點(diǎn)接收到該請(qǐng)求，首先查詢本地的圖緩存，如果命中則直接返回結(jié)果。如果沒有命中，則將請(qǐng)求轉(zhuǎn)發(fā)給 Leader 節(jié)點(diǎn)。同樣的，Leader 節(jié)點(diǎn)如果命中則返回，如果不命中則查詢底層 MySQL 數(shù)據(jù)庫(kù)。

2）寫流程：客戶端將寫請(qǐng)求發(fā)送給 router，和讀流程一樣，會(huì)轉(zhuǎn)發(fā)到對(duì)應(yīng)的 Follower 節(jié)點(diǎn)上。Follower 節(jié)點(diǎn)會(huì)轉(zhuǎn)發(fā)寫請(qǐng)求給 Leader 節(jié)點(diǎn)，Leader 節(jié)點(diǎn)轉(zhuǎn)發(fā)給 MySQL，當(dāng) MySQL 返回寫入成功后，Leader 會(huì)清除本地圖緩存對(duì)應(yīng)的 Key，并同步給其他所有 Follower 清除掉該 Key，保證數(shù)據(jù)的最終一致性。

6、高可用設(shè)計(jì)

REDtao 分為獨(dú)立的兩層：緩存層和持久層。每一層都保證高可用性。

1）自研的分布式緩存：

我們自研了實(shí)現(xiàn)圖語(yǔ)義的分布式 cache 集群，支持故障自動(dòng)檢測(cè)和恢復(fù)、水平擴(kuò)縮容。

它是一個(gè)雙層 cache，每個(gè)分片都有一個(gè) Leader 和若干個(gè) Follower。所有的請(qǐng)求都先發(fā)給外層的 Follower，再由 Follower 轉(zhuǎn)發(fā)給 Leader。這樣的好處是讀壓力大的時(shí)候只需要水平擴(kuò)展 Follower，單點(diǎn) Leader 寫入的方式也降低了復(fù)雜度，更容易實(shí)現(xiàn)數(shù)據(jù)的一致性。

如果一個(gè)副本故障，系統(tǒng)會(huì)在秒級(jí)別內(nèi)進(jìn)行切換。當(dāng)持久層發(fā)生故障時(shí)，分布式緩存層仍然可以對(duì)外提供讀取服務(wù)。

2）高可用的MySQL集群：

MySQL 集群通過自研的中間件實(shí)現(xiàn)了分庫(kù)分表方案，并支持 MySQL 的水平擴(kuò)容。每個(gè) MySQL 數(shù)據(jù)庫(kù)有若干從庫(kù)，并且與公司內(nèi)部其他的 MySQL 運(yùn)維方案一致，保證高可用性。

3）限流保護(hù)功能：

為防止緩存擊穿導(dǎo)致 MySQL 突發(fā)大量請(qǐng)求，從而導(dǎo)致 MySQL 宕機(jī)，我們通過限制每個(gè)主節(jié)點(diǎn)最大 MySQL 并發(fā)請(qǐng)求數(shù)來(lái)實(shí)現(xiàn)限流保護(hù) MySQL。達(dá)到最大并發(fā)請(qǐng)求限制之后的請(qǐng)求會(huì)被掛起等待，直到已有請(qǐng)求被處理返回，或者達(dá)到等待超時(shí)請(qǐng)求被拒絕不會(huì)被繼續(xù)請(qǐng)求到 MySQL 。限流閾值在線可調(diào)，根據(jù) MySQL 集群規(guī)模調(diào)整對(duì)應(yīng)限制。

為防止爬蟲或者作弊用戶頻繁刷同一條數(shù)據(jù)，我們利用 REDtaoQueue 順序執(zhí)行對(duì)寫入或者點(diǎn)查同一條邊的請(qǐng)求，隊(duì)列長(zhǎng)度會(huì)被限制，控制同一時(shí)間大量相同的請(qǐng)求執(zhí)行。相比于單個(gè)全局的隊(duì)列控制所有請(qǐng)求的方式，基于每個(gè)請(qǐng)求的隊(duì)列可以很好地限制單個(gè)同一請(qǐng)求，而不影響其他正常請(qǐng)求。

7、高性能設(shè)計(jì)

數(shù)據(jù)結(jié)構(gòu)的設(shè)計(jì)是 REDtao 高性能的重要保證。

我們采用了三層嵌套 HashTable 的設(shè)計(jì), 通過根據(jù)某個(gè)起點(diǎn) from_id 從第一級(jí) HashTable 中查找到 REDtaoGraph，記錄了所有 type 下對(duì)應(yīng)的所有的出邊信息。

接著，在第二級(jí) HashTable 中，根據(jù)某個(gè) type_id 查找到 AssocType 對(duì)應(yīng)某個(gè) type 下邊所有出邊的計(jì)數(shù)、索引以及其他元數(shù)據(jù)。

最終在最后一級(jí) HashTable ，通過 AssocType 的某個(gè) to_id 查找到最終邊信息。

我們記錄了創(chuàng)建時(shí)間、更新時(shí)間、版本、數(shù)據(jù)以及 REDtaoQueue，time_index 則對(duì)應(yīng)根據(jù)創(chuàng)建時(shí)間排序列表。

最后一級(jí) HashTable 以及索引限制存儲(chǔ)最新的 1000 個(gè)邊信息，以限制超級(jí)點(diǎn)占據(jù)過多內(nèi)存，同時(shí)集中提高最新熱數(shù)據(jù)的查詢命中率以及效率。REDtaoQueue 用于排隊(duì)當(dāng)前某個(gè)關(guān)系的讀寫，只記錄了當(dāng)前最后一個(gè)請(qǐng)求的元數(shù)據(jù)。

每次查詢或?qū)懭霑r(shí)，首先查詢 REDtaoAssoc：

• 1）若緩存不存在，則會(huì)首先創(chuàng)建只包含 REDtaoQueue 的對(duì)象；

• 2）若緩存已存在，則會(huì)更新隊(duì)列元數(shù)據(jù)，將自己設(shè)置為隊(duì)列的最后一個(gè)請(qǐng)求，并掛起等待被執(zhí)行。

通過這種多層 hash+ 跳表的設(shè)計(jì)，我們能高效地組織點(diǎn)、邊、索引、時(shí)間序鏈表之間的關(guān)系。內(nèi)存的申請(qǐng)、釋放在同一個(gè)線程上完成。

在線上環(huán)境中，我們的系統(tǒng)可以在一臺(tái) 16 核的云廠商虛擬機(jī)上跑到 150w 查詢請(qǐng)求/s，同時(shí) CPU 利用率僅有 22.5% 。下方是線上集群的一個(gè)監(jiān)控圖，單機(jī)的 QPS 到達(dá) 3w ，每個(gè) RPC 請(qǐng)求聚合了 50 個(gè)查詢。

?

8、易用性設(shè)計(jì)

1）豐富的圖語(yǔ)義 API ：

我們?cè)?REDtao 中封裝了 25 個(gè)圖語(yǔ)義的 API 給業(yè)務(wù)方使用，滿足了業(yè)務(wù)方的增刪改查的需求。業(yè)務(wù)方無(wú)需自行編寫 SQL 語(yǔ)句即可實(shí)現(xiàn)相應(yīng)操作，使用方式更加簡(jiǎn)單和收斂。

2）統(tǒng)一的訪問 URL ：

由于社區(qū)后端數(shù)據(jù)太大，我們按照不同的服務(wù)和優(yōu)先級(jí)拆分成了幾個(gè) REDtao 集群。

為了讓業(yè)務(wù)方不感知后端的集群拆分邏輯，我們實(shí)現(xiàn)了統(tǒng)一的接入層。

不同的業(yè)務(wù)方只需使用同一個(gè)服務(wù) URL ，通過 SDK 將請(qǐng)求發(fā)送到接入層。接入層會(huì)接收到不同業(yè)務(wù)方的圖語(yǔ)義的請(qǐng)求，并根據(jù)邊的類型路由到不同的 REDtao 集群。它通過訂閱配置中心，能夠?qū)崟r(shí)感知到邊的路由關(guān)系，從而實(shí)現(xiàn)統(tǒng)一的訪問 URL，方便業(yè)務(wù)方使用。

9、數(shù)據(jù)一致性設(shè)計(jì)

作為社交圖譜數(shù)據(jù)，數(shù)據(jù)的一致性至關(guān)重要。我們需要嚴(yán)格保證數(shù)據(jù)的最終一致性以及一定場(chǎng)景下的強(qiáng)一致性。為此，我們采取了以下措施：

1）緩存更新沖突的解決：

REDtao 為每個(gè)寫入請(qǐng)求生成一個(gè)全局遞增的唯一版本號(hào)。在使用 MySQL 數(shù)據(jù)更新本地緩存時(shí)，需要比較版本號(hào)，如果版本號(hào)比緩存的數(shù)據(jù)版本低，則會(huì)拒絕此更新請(qǐng)求，以避免沖突。

2）寫后讀的一致性：

Proxy 會(huì)將同一個(gè) fromId 的點(diǎn)或邊請(qǐng)求路由到同一個(gè)讀 cache 節(jié)點(diǎn)上，以保證讀取數(shù)據(jù)一致性。

3）主節(jié)點(diǎn)異常場(chǎng)景：

Leader 節(jié)點(diǎn)收到更新請(qǐng)求后，會(huì)將更新請(qǐng)求變?yōu)?invalidate cache 請(qǐng)求異步的發(fā)送給其他 follower，以保證 follower 上的數(shù)據(jù)最終一致。在異常情況下，如果 Leader 發(fā)送的隊(duì)列已滿導(dǎo)致 invalidate cache 請(qǐng)求丟失，那么會(huì)將其他的 follower cache 全部清除掉。

如果 Leader 故障，新選舉的 Leader 也會(huì)通知其他 follower 將 cache 清除。

此外，Leader 會(huì)對(duì)訪問 MySQL 的請(qǐng)求進(jìn)行限流，從而保證即使個(gè)別分片的cache被清除掉也不會(huì)將 MySQL 打崩。

4）少量強(qiáng)一致的請(qǐng)求：

由于 MySQL 的從庫(kù)也提供讀服務(wù)，對(duì)于少量要求強(qiáng)一致的讀請(qǐng)求，客戶端可以將請(qǐng)求染上特殊標(biāo)志，REDtao 會(huì)透?jìng)髟摌?biāo)志，數(shù)據(jù)庫(kù) Proxy 層會(huì)根據(jù)該標(biāo)志將讀請(qǐng)求轉(zhuǎn)發(fā)到 MySQL 主庫(kù)上，從而保證數(shù)據(jù)的強(qiáng)一致。

10、 跨云多活設(shè)計(jì)

跨云多活是公司的重要戰(zhàn)略，也是 REDtao 支持的一個(gè)重要特性。

REDtao 的跨云多活架構(gòu)整體如下：

這里不同于 Facebook Tao 的跨云多活實(shí)現(xiàn)，F(xiàn)acebook Tao 的跨云多活實(shí)現(xiàn)如下圖所示。

Facebook 的方案依賴于底層的 MySQL 的主從復(fù)制都通過 DTS Replication 來(lái)做。而 MySQL 原生的主從復(fù)制是自身功能，DTS 服務(wù)并不包含 MySQL 的主從復(fù)制。該方案需要對(duì) MySQL 和 DTS 做一定的改造。前面說到，我們的緩存和持久層是解藕的，在架構(gòu)上不一樣。

因此，REDtao 的跨云多活架構(gòu)是我們結(jié)合自身場(chǎng)景下的設(shè)計(jì)，它在不改動(dòng)現(xiàn)有 MySQL 功能的前提下實(shí)現(xiàn)了跨云多活功能。

1）持久層我們通過 MySQL 原生的主從 binlog 同步將數(shù)據(jù)復(fù)制到其他云的從庫(kù)上。其他云上的寫請(qǐng)求和少量要求強(qiáng)一致讀將被轉(zhuǎn)發(fā)到主庫(kù)上。正常的讀請(qǐng)求將讀取本區(qū)的 MySQL 數(shù)據(jù)庫(kù)，滿足讀請(qǐng)求對(duì)時(shí)延的要求。

2）緩存層的數(shù)據(jù)一致性是通過 MySQL DTS 訂閱服務(wù)實(shí)現(xiàn)的，將 binlog 轉(zhuǎn)換為 invalidate cache 請(qǐng)求，以清理掉本區(qū) REDtao cache 層的 stale 數(shù)據(jù)。由于讀請(qǐng)求會(huì)隨機(jī)讀取本區(qū)的任何一個(gè) MySQL 數(shù)據(jù)庫(kù)，因此 DTS 訂閱使用了一個(gè)延遲訂閱的功能，保證從 binlog 同步最慢的節(jié)點(diǎn)中讀取日志，避免 DTS 的 invalidate cache 請(qǐng)求和本區(qū) read cache miss 的請(qǐng)求發(fā)生沖突從而導(dǎo)致數(shù)據(jù)不一致。

11、云原生實(shí)現(xiàn)

REDtao 的云原生特性重點(diǎn)體現(xiàn)在彈性伸縮、支持多 AZ 和 Region 數(shù)據(jù)分布、產(chǎn)品可以實(shí)現(xiàn)在不同的云廠商間遷移等幾個(gè)方面。REDtao 在設(shè)計(jì)之初就考慮到支持彈性擴(kuò)縮容、故障自動(dòng)檢測(cè)及恢復(fù)。

隨著 Kubernetes 云原生技術(shù)越來(lái)越成熟，我們也在思考如何利用 k8s 的能力將部署和虛擬機(jī)解綁，進(jìn)一步云原生化，方便在不同的云廠商之間部署和遷移。

REDtao 實(shí)現(xiàn)了一個(gè)運(yùn)行在 Kubernetes 集群上的 Operator，以實(shí)現(xiàn)更快的部署、擴(kuò)容和壞機(jī)替換。

為了讓 k8s 能感知集群分片的分配并且控制同一分片下的 Pods 調(diào)度在不同宿主機(jī)上，集群分組分片分配由 k8s Operator 渲染并控制創(chuàng)建 DuplicateSet （小紅書自研 k8s 資源對(duì)象）。

REDtao 則會(huì)創(chuàng)建主從并根據(jù) Operator 渲染出來(lái)的分片信息創(chuàng)建集群，單個(gè) Pod 故障重啟會(huì)重新加入集群，無(wú)需重新創(chuàng)建整個(gè)集群。集群升級(jí)時(shí)，Operator 通過感知主從分配控制先從后主的順序，按照分片分配的順序滾動(dòng)升級(jí)以減少升級(jí)期間線上影響。

12、老服務(wù)的平滑升級(jí)實(shí)踐

但凡變革，皆屬不易。實(shí)現(xiàn)全新的 REDtao 只是完成了相對(duì)容易的那部分工作。

小紅書的社交圖譜數(shù)據(jù)服務(wù)已經(jīng)在 MySQL 上運(yùn)行多年，有很多不同的業(yè)務(wù)跑在上面，任何小的問題都會(huì)影響到小紅書的在線用戶。因此，如何保證不停服的情況下讓現(xiàn)有業(yè)務(wù)無(wú)感知地遷移到 REDtao 上成為一個(gè)非常大的挑戰(zhàn)。

我們的遷移工作關(guān)鍵有兩點(diǎn)：

1）將老的大 MySQL 集群按優(yōu)先級(jí)拆分成了四個(gè) REDtao 集群。這樣，我們可以先將優(yōu)先級(jí)最低的服務(wù)遷移到一個(gè) REDtao 集群，充分灰度后再遷移高優(yōu)先級(jí)的集群；

2）專門開發(fā)了一個(gè) Tao Proxy SDK，支持對(duì)原來(lái)的 MySQL 集群和 REDtao 集群進(jìn)行雙寫雙讀，數(shù)據(jù)校驗(yàn)比對(duì)。

遷移時(shí)：我們首先將低優(yōu)先級(jí)的數(shù)據(jù)從 MySQL 通過 DTS 服務(wù)遷移到了一個(gè) REDtao 集群，并升級(jí)好業(yè)務(wù)方的 SDK 。DTS 服務(wù)一直對(duì)增量數(shù)據(jù)進(jìn)行同步。業(yè)務(wù)方 SDK 會(huì)訂閱配置中心的配置變更，我們修改配置讓 Tao Proxy SDK 同時(shí)讀寫 MySQL 集群和 REDtao 集群，并關(guān)閉 DTS 服務(wù)。此時(shí)會(huì)使用 MySQL 集群的結(jié)果返回給用戶。

在停止 DTS 服務(wù)時(shí)：有可能會(huì)有新的 MySQL 數(shù)據(jù)通過 DTS 同步過來(lái)，造成了 REDtao 集群新寫的數(shù)據(jù)被同步過來(lái)的老數(shù)據(jù)覆蓋。因此，在關(guān)閉 DTS 服務(wù)后，我們會(huì)通過工具讀取開雙寫之后到關(guān)閉 DTS 服務(wù)這個(gè)時(shí)間段的 binlog 對(duì)數(shù)據(jù)進(jìn)行校驗(yàn)和修復(fù)。

修復(fù)完成之后：Tao Proxy SDK 的雙讀會(huì)展示兩邊不一致的數(shù)據(jù)量，并過濾掉因?yàn)殡p寫時(shí)延不一致導(dǎo)致數(shù)據(jù)不一致的請(qǐng)求。灰度一段時(shí)間后觀察到 diff 的數(shù)目基本為 0，將 Tao Proxy SDK 的配置改為只讀寫新的 REDtao 集群。

最終：我們?cè)?22 年初完成小紅書所有核心社交圖譜萬(wàn)億邊級(jí)別數(shù)據(jù)的遷移和正確性校驗(yàn)，并做到了整個(gè)遷移服務(wù)無(wú)感知，遷移過程沒有發(fā)生一起故障。

13、新圖存儲(chǔ)系統(tǒng)帶來(lái)的結(jié)果和收益

我們的社交圖譜數(shù)據(jù)訪問中，90% 以上的請(qǐng)求都是讀請(qǐng)求，并且社交圖譜的數(shù)據(jù)有非常強(qiáng)的時(shí)間局部性（即最近更新的數(shù)據(jù)最容易被訪問）。REDtao 上線后，獲得 90% 以上的 cache 命中率， 對(duì)MySQL 的 QPS 降低了 70%+ ，大大降低了 MySQL 的 CPU 使用率。在縮容 MySQL 的副本數(shù)目后，整體成本降低了21.3%。?

業(yè)務(wù)的訪問方式都全部收斂到 REDtao 提供的 API 接口上，在遷移過程中，我們還治理了一些老的不合理訪問 MySQL 數(shù)據(jù)庫(kù)的方式，以及自定義某些字段賦予特殊含義的不合理做法，通過 REDtao 規(guī)范了數(shù)據(jù)訪問。

對(duì)比 2022 年初和 2023 年初，隨著 DAU 的增長(zhǎng)，社交圖譜的請(qǐng)求增長(zhǎng)了 250% 以上，如果是之前 MySQL 的老架構(gòu)，擴(kuò)容資源基本上和請(qǐng)求增長(zhǎng)速度成正比，至少需要擴(kuò)容 1 倍的資源成本（數(shù)萬(wàn)核）。

而得益于 REDtao 系統(tǒng)的存在，因其 90% 的緩存命中率，實(shí)際上整體成本只增加了 14.7%（數(shù)千核）就能扛下 2.5 倍的請(qǐng)求增長(zhǎng)。在成本和穩(wěn)定性上有了較大的提升。

14、未來(lái)展望

在較短的時(shí)間，我們自研了圖存儲(chǔ)系統(tǒng) REDtao ，解決了社交圖譜關(guān)系數(shù)據(jù)快速增長(zhǎng)的問題。

REDtao 借鑒了 FaceBook Tao 的論文，并對(duì)整體架構(gòu)、跨云多活做了較多的改進(jìn)，全新實(shí)現(xiàn)了一個(gè)高性能的分布式圖緩存，更加貼合我們自身的業(yè)務(wù)特點(diǎn)和提供了更好的彈性。同時(shí)，利用 k8s 能力進(jìn)一步實(shí)現(xiàn)了云原生化。

隨著 DAU 的持續(xù)增長(zhǎng)，萬(wàn)億的數(shù)據(jù)規(guī)模也在繼續(xù)增長(zhǎng)，我們也面臨著更多的技術(shù)挑戰(zhàn)。

目前公司內(nèi)部的 OLTP 圖場(chǎng)景主要分為三塊：

1）社交圖譜數(shù)據(jù)服務(wù)：通過自研圖存儲(chǔ)系統(tǒng) REDtao 滿足了社交場(chǎng)景超大規(guī)模數(shù)據(jù)的更新與關(guān)聯(lián)讀取問題。目前已經(jīng)存儲(chǔ)了萬(wàn)億規(guī)模的關(guān)系；

2）風(fēng)控場(chǎng)景：通過自研圖數(shù)據(jù)庫(kù) REDgraph，滿足多跳的實(shí)時(shí)在線查詢。目前存儲(chǔ)了千億點(diǎn)和邊的關(guān)系，滿足 2 跳以及 2 跳以上的查詢；

3）社交推薦：這塊主要是兩跳的查詢。每天通過 Hive 批量地導(dǎo)入全量的數(shù)據(jù)，通過 DTS 服務(wù)近實(shí)時(shí)的寫入更新數(shù)據(jù)。因?yàn)槭窃诰€場(chǎng)景，對(duì)時(shí)延的要求非常高，當(dāng)前的 REDgraph 還無(wú)法滿足這么高的要求，因此業(yè)務(wù)方主要是用 REDkv 來(lái)存儲(chǔ)。

針對(duì)以上場(chǎng)景：為了快速滿足業(yè)務(wù)需求，我們使用了三套不同的自研存儲(chǔ)系統(tǒng)：REDtao 、REDgraph 和 REDkv 。

顯然相對(duì)于 3 套存儲(chǔ)系統(tǒng)，用一個(gè)統(tǒng)一的架構(gòu)和系統(tǒng)去解決這幾個(gè)圖相關(guān)的場(chǎng)景是更加合適的。

未來(lái)：我們會(huì)將 REDgraph 和 REDtao 融合成一個(gè)統(tǒng)一的數(shù)據(jù)庫(kù)產(chǎn)品，打造業(yè)內(nèi)頂尖的圖技術(shù)，對(duì)公司內(nèi)部更多的場(chǎng)景進(jìn)行賦能。

15、相關(guān)資料

[1]?以微博類應(yīng)用場(chǎng)景為例，總結(jié)海量社交系統(tǒng)的架構(gòu)設(shè)計(jì)步驟

[2]?騰訊技術(shù)分享：社交網(wǎng)絡(luò)圖片的帶寬壓縮技術(shù)演進(jìn)之路

[3]?基于社交網(wǎng)絡(luò)的Yelp是如何實(shí)現(xiàn)海量用戶圖片的無(wú)損壓縮的？

[4]?社交軟件紅包技術(shù)解密(一)：全面解密QQ紅包技術(shù)方案——架構(gòu)、技術(shù)實(shí)現(xiàn)等

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

[6]?社交軟件紅包技術(shù)解密(九)：談?wù)勈諵紅包的功能邏輯、容災(zāi)、運(yùn)維、架構(gòu)等

[7]?漸行漸遠(yuǎn)的人人網(wǎng)：十年親歷者的互聯(lián)網(wǎng)社交產(chǎn)品復(fù)盤和反思

[8]?中國(guó)互聯(lián)網(wǎng)社交二十年：全民見證的互聯(lián)網(wǎng)創(chuàng)業(yè)演義

[9]?盤點(diǎn)移動(dòng)互聯(lián)網(wǎng)時(shí)代的社交產(chǎn)品進(jìn)化史（上篇）：誰(shuí)主沉浮

[10]?盤點(diǎn)移動(dòng)互聯(lián)網(wǎng)時(shí)代的社交產(chǎn)品進(jìn)化史（下篇）：大浪淘沙

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