本文由小紅書基礎(chǔ)架構(gòu)存儲組空洞和劉備分享，原題“小紅書如何應(yīng)對萬億級社交網(wǎng)絡(luò)關(guān)系挑戰(zhàn)？圖存儲系統(tǒng) REDtao 來了！”，本文有修訂和改動。
1、引言
小紅書是一個社區(qū)屬性為主的產(chǎn)品，它涵蓋了各個領(lǐng)域的生活社區(qū)，并存儲海量的社交網(wǎng)絡(luò)關(guān)系。
為了解決社交場景下超大規(guī)模數(shù)據(jù)的更新與關(guān)聯(lián)讀取問題，并減少數(shù)據(jù)庫壓力和成本，我們自研了面向超大規(guī)模社交網(wǎng)絡(luò)的圖存儲系統(tǒng) REDtao，大大提高了系統(tǒng)穩(wěn)定性。該系統(tǒng)借鑒了 Facebook 的圖存儲系統(tǒng)設(shè)計，將緩存和底層數(shù)據(jù)庫封裝起來，并對外提供統(tǒng)一的圖查詢 API，實(shí)現(xiàn)了訪問收斂，同時在緩存中實(shí)現(xiàn)了高效的邊聚合。
本文將為你分享小紅書面向超大規(guī)模社交網(wǎng)絡(luò)的圖存儲系統(tǒng)REDtao的架構(gòu)設(shè)計與技術(shù)實(shí)踐過程，希望能帶給你啟發(fā)。
2、關(guān)于作者
空洞：小紅書基礎(chǔ)架構(gòu)存儲組，負(fù)責(zé)圖存儲系統(tǒng) REDtao 和分布式緩存的研發(fā)。
劉備：小紅書基礎(chǔ)架構(gòu)存儲組負(fù)責(zé)人，負(fù)責(zé)REDkv / REDtao / REDtable / REDgraph 的整體架構(gòu)和技術(shù)演進(jìn)。
基礎(chǔ)架構(gòu)存儲組是給小紅書的業(yè)務(wù)部門提供穩(wěn)定可靠的存儲和數(shù)據(jù)庫服務(wù)，滿足業(yè)務(wù)對存儲產(chǎn)品的功能、性能、成本和穩(wěn)定性要求。目前負(fù)責(zé)自研分布式 KV、分布式緩存、圖存儲系統(tǒng)、圖數(shù)據(jù)庫和表格存儲。
已上線的存儲產(chǎn)品包括：
- 1）REDkv : 分布式高性能 KV；
- 2）REDtao ：滿足一跳查詢的高性能圖存儲數(shù)據(jù)庫；
- 3） REDtable ：提供 Schema 語義和二級索引的表格存儲；
- 4） REDgraph ：提供兩跳及以上的圖語義查詢數(shù)據(jù)庫。
3、技術(shù)背景
小紅書是以年輕人為主的生活記錄、分享平臺，用戶可以通過短視頻、圖文等形式記錄生活點(diǎn)滴，分享生活方式。
在小紅書的社交領(lǐng)域里，我們有用戶、筆記、商品等實(shí)體，這些實(shí)體之間有各種各樣的關(guān)系。
例如：用戶與筆記之間可能存在“擁有”（發(fā)布）、“點(diǎn)贊”、“收藏”等三種關(guān)系，同時還存在對應(yīng)的反向關(guān)系“被點(diǎn)贊”，“被收藏”等。
小紅書的社交圖譜數(shù)據(jù)已經(jīng)達(dá)到了萬億條邊的規(guī)模，且增長速度非常快。當(dāng)用戶登陸小紅書時，每個用戶都會看到關(guān)注的好友、粉絲、點(diǎn)贊、收藏以及其他為其量身定做的內(nèi)容。
這些信息高度個性化，需要實(shí)時從這些海量社交關(guān)系數(shù)據(jù)中讀取用戶相關(guān)信息。這是一個讀為主的過程，讀取壓力非常大。
過去，我們將這些社交圖譜數(shù)據(jù)都存儲在運(yùn)維成熟的 MySQL 數(shù)據(jù)庫中。
然而，即使我們只有百萬請求每秒的規(guī)模，MySQL 的 CPU 使用率仍然到達(dá)了 55% 。隨著用戶和 DAU 爆發(fā)式的增長，需要不斷擴(kuò)容 MySQL 數(shù)據(jù)庫，這帶來了巨大的成本和穩(wěn)定性壓力。
為了解決這些問題且考慮到?jīng)]有合適的開源方案，2021 年初我們開啟了從 0 到 1 自研 REDtao 的歷程。
4、方案調(diào)研和API設(shè)計
4.1方案調(diào)研
我們充分調(diào)研了業(yè)內(nèi)其他廠商的實(shí)現(xiàn)，發(fā)現(xiàn)有著強(qiáng)社交屬性的公司基本上都有一個自研的圖存儲系統(tǒng)（如下圖所示）。
比如：
- 1）Facebook 實(shí)現(xiàn)了一個叫做 “TAO” 專門的分布式社交圖譜數(shù)據(jù)庫，并將其作為最核心的存儲系統(tǒng)；
- 2）Pinterest 和 Facebook 類似，也實(shí)現(xiàn)了類似的圖存儲系統(tǒng)；
- 3）字節(jié)跳動自研了 ByteGraph 并將其用于存儲核心的社交圖譜數(shù)據(jù)；
- 4）Linkedln 在 KV 之上構(gòu)建了社交圖譜服務(wù)。
考慮到當(dāng)時我們的社交圖譜數(shù)據(jù)已經(jīng)存放在 MySQL 數(shù)據(jù)庫上且規(guī)模巨大，而社交圖譜數(shù)據(jù)服務(wù)是非常重要的服務(wù)，對穩(wěn)定性的要求非常高?；厮?Facebook 當(dāng)年遇到的問題和我們類似，數(shù)據(jù)存儲在 Memcache 和 MySQL 中。因此，參考 Facebook 的 Tao 圖存儲系統(tǒng)更貼合我們的實(shí)際情況和已有的技術(shù)架構(gòu)，風(fēng)險更小。
4.2API設(shè)計
社交圖譜的訪問主要是邊的關(guān)系查詢。
我們的圖模型將關(guān)系表示為一個 <key, value> 對，其中 key 是 ( FromId, AssocType, ToId ) 的三元組，value 是屬性的 JSON 格式。
比如“用戶 A ”關(guān)注“用戶 B ”，映射到 REDtao 的數(shù)據(jù)存儲結(jié)構(gòu)為：
1<FromId:用戶A的ID, AssocType：關(guān)注， ToId：用戶B的ID> -> Value （屬性的json字段）
我們對業(yè)務(wù)方的需求進(jìn)行分析，封裝了 25 個圖語義的 API 給業(yè)務(wù)方使用，滿足了其增刪改查的需求，并收斂業(yè)務(wù)方的使用方式。
相比于 Facebook 的 Tao，我們還補(bǔ)充了社交圖譜所需要的圖語義，為反作弊場景提供了額外的過濾參數(shù)。
同時，在緩存層面，我們支持對不同的字段在緩存中配置局部二級索引。
下面給一些典型的使用場景。
1）場景一：獲取關(guān)注了 A 的所有正常用戶（并且剔除作弊用戶）：
1getAssocs(“被關(guān)注類型”, 用戶A的ID, 分頁偏移量, 最大返回值, 只返回正常用戶，是否按照時間從新到舊)
2）場景二：獲取 A 的粉絲個數(shù)（并且剔除作弊用戶）：
1getAssocCount(“被關(guān)注類型”, 用戶A的ID, 只返回正常用戶)
5、整體架構(gòu)設(shè)計
REDtao 的架構(gòu)設(shè)計考慮了下面這幾個關(guān)鍵的要素：
整體架構(gòu)分為三層：
業(yè)務(wù)方通過 REDtao SDK 接入服務(wù)。
如下圖：
在這個架構(gòu)中：和 Facebook Tao 不一樣的是，我們的緩存層是一個獨(dú)立的分布式集群，和下面的持久層是解耦的。緩存層和下面的持久層可以獨(dú)立的擴(kuò)容縮容，緩存分片和 MySQL 分片不需要一一對應(yīng)，這樣帶來了更好的靈活性，MySQL 集群也變成了一個可以插拔替換的持久存儲。
1）讀流程：客戶端將讀請求發(fā)送給 router，router 接收到 RPC 請求后，根據(jù)邊類型選擇對應(yīng)的 REDtao 集群，根據(jù)三元組 ( FromId, AssocType, ToId ) 通過一致性 Hash 計算出分片所在的 Follower 節(jié)點(diǎn)，將請求轉(zhuǎn)發(fā)到該節(jié)點(diǎn)上。Follower 節(jié)點(diǎn)接收到該請求，首先查詢本地的圖緩存，如果命中則直接返回結(jié)果。如果沒有命中，則將請求轉(zhuǎn)發(fā)給 Leader 節(jié)點(diǎn)。同樣的，Leader 節(jié)點(diǎn)如果命中則返回，如果不命中則查詢底層 MySQL 數(shù)據(jù)庫。
2）寫流程：客戶端將寫請求發(fā)送給 router，和讀流程一樣，會轉(zhuǎn)發(fā)到對應(yīng)的 Follower 節(jié)點(diǎn)上。Follower 節(jié)點(diǎn)會轉(zhuǎn)發(fā)寫請求給 Leader 節(jié)點(diǎn)，Leader 節(jié)點(diǎn)轉(zhuǎn)發(fā)給 MySQL，當(dāng) MySQL 返回寫入成功后，Leader 會清除本地圖緩存對應(yīng)的 Key，并同步給其他所有 Follower 清除掉該 Key，保證數(shù)據(jù)的最終一致性。
6、高可用設(shè)計
REDtao 分為獨(dú)立的兩層：緩存層和持久層。每一層都保證高可用性。
1）自研的分布式緩存：
我們自研了實(shí)現(xiàn)圖語義的分布式 cache 集群，支持故障自動檢測和恢復(fù)、水平擴(kuò)縮容。
它是一個雙層 cache，每個分片都有一個 Leader 和若干個 Follower。所有的請求都先發(fā)給外層的 Follower，再由 Follower 轉(zhuǎn)發(fā)給 Leader。這樣的好處是讀壓力大的時候只需要水平擴(kuò)展 Follower，單點(diǎn) Leader 寫入的方式也降低了復(fù)雜度，更容易實(shí)現(xiàn)數(shù)據(jù)的一致性。
如果一個副本故障，系統(tǒng)會在秒級別內(nèi)進(jìn)行切換。當(dāng)持久層發(fā)生故障時，分布式緩存層仍然可以對外提供讀取服務(wù)。
2）高可用的MySQL集群：
MySQL 集群通過自研的中間件實(shí)現(xiàn)了分庫分表方案，并支持 MySQL 的水平擴(kuò)容。每個 MySQL 數(shù)據(jù)庫有若干從庫，并且與公司內(nèi)部其他的 MySQL 運(yùn)維方案一致，保證高可用性。
3）限流保護(hù)功能：
為防止緩存擊穿導(dǎo)致 MySQL 突發(fā)大量請求，從而導(dǎo)致 MySQL 宕機(jī)，我們通過限制每個主節(jié)點(diǎn)最大 MySQL 并發(fā)請求數(shù)來實(shí)現(xiàn)限流保護(hù) MySQL。達(dá)到最大并發(fā)請求限制之后的請求會被掛起等待，直到已有請求被處理返回，或者達(dá)到等待超時請求被拒絕不會被繼續(xù)請求到 MySQL 。限流閾值在線可調(diào)，根據(jù) MySQL 集群規(guī)模調(diào)整對應(yīng)限制。
為防止爬蟲或者作弊用戶頻繁刷同一條數(shù)據(jù)，我們利用 REDtaoQueue 順序執(zhí)行對寫入或者點(diǎn)查同一條邊的請求，隊列長度會被限制，控制同一時間大量相同的請求執(zhí)行。相比于單個全局的隊列控制所有請求的方式，基于每個請求的隊列可以很好地限制單個同一請求，而不影響其他正常請求。
7、高性能設(shè)計
數(shù)據(jù)結(jié)構(gòu)的設(shè)計是 REDtao 高性能的重要保證。
我們采用了三層嵌套 HashTable 的設(shè)計, 通過根據(jù)某個起點(diǎn) from_id 從第一級 HashTable 中查找到 REDtaoGraph，記錄了所有 type 下對應(yīng)的所有的出邊信息。
接著，在第二級 HashTable 中，根據(jù)某個 type_id 查找到 AssocType 對應(yīng)某個 type 下邊所有出邊的計數(shù)、索引以及其他元數(shù)據(jù)。
最終在最后一級 HashTable ，通過 AssocType 的某個 to_id 查找到最終邊信息。
我們記錄了創(chuàng)建時間、更新時間、版本、數(shù)據(jù)以及 REDtaoQueue，time_index 則對應(yīng)根據(jù)創(chuàng)建時間排序列表。
最后一級 HashTable 以及索引限制存儲最新的 1000 個邊信息，以限制超級點(diǎn)占據(jù)過多內(nèi)存，同時集中提高最新熱數(shù)據(jù)的查詢命中率以及效率。REDtaoQueue 用于排隊當(dāng)前某個關(guān)系的讀寫，只記錄了當(dāng)前最后一個請求的元數(shù)據(jù)。
每次查詢或?qū)懭霑r，首先查詢 REDtaoAssoc：
- 1）若緩存不存在，則會首先創(chuàng)建只包含 REDtaoQueue 的對象；
- 2）若緩存已存在，則會更新隊列元數(shù)據(jù)，將自己設(shè)置為隊列的最后一個請求，并掛起等待被執(zhí)行。
通過這種多層 hash+ 跳表的設(shè)計，我們能高效地組織點(diǎn)、邊、索引、時間序鏈表之間的關(guān)系。內(nèi)存的申請、釋放在同一個線程上完成。
在線上環(huán)境中，我們的系統(tǒng)可以在一臺 16 核的云廠商虛擬機(jī)上跑到 150w 查詢請求/s，同時 CPU 利用率僅有 22.5% 。下方是線上集群的一個監(jiān)控圖，單機(jī)的 QPS 到達(dá) 3w ，每個 RPC 請求聚合了 50 個查詢。
8、易用性設(shè)計
1）豐富的圖語義 API ：
我們在 REDtao 中封裝了 25 個圖語義的 API 給業(yè)務(wù)方使用，滿足了業(yè)務(wù)方的增刪改查的需求。業(yè)務(wù)方無需自行編寫 SQL 語句即可實(shí)現(xiàn)相應(yīng)操作，使用方式更加簡單和收斂。
2）統(tǒng)一的訪問 URL ：
由于社區(qū)后端數(shù)據(jù)太大，我們按照不同的服務(wù)和優(yōu)先級拆分成了幾個 REDtao 集群。
為了讓業(yè)務(wù)方不感知后端的集群拆分邏輯，我們實(shí)現(xiàn)了統(tǒng)一的接入層。
不同的業(yè)務(wù)方只需使用同一個服務(wù) URL ，通過 SDK 將請求發(fā)送到接入層。接入層會接收到不同業(yè)務(wù)方的圖語義的請求，并根據(jù)邊的類型路由到不同的 REDtao 集群。它通過訂閱配置中心，能夠?qū)崟r感知到邊的路由關(guān)系，從而實(shí)現(xiàn)統(tǒng)一的訪問 URL，方便業(yè)務(wù)方使用。
9、數(shù)據(jù)一致性設(shè)計
作為社交圖譜數(shù)據(jù)，數(shù)據(jù)的一致性至關(guān)重要。我們需要嚴(yán)格保證數(shù)據(jù)的最終一致性以及一定場景下的強(qiáng)一致性。為此，我們采取了以下措施：
1）緩存更新沖突的解決：
REDtao 為每個寫入請求生成一個全局遞增的唯一版本號。在使用 MySQL 數(shù)據(jù)更新本地緩存時，需要比較版本號，如果版本號比緩存的數(shù)據(jù)版本低，則會拒絕此更新請求，以避免沖突。
2）寫后讀的一致性：
Proxy 會將同一個 fromId 的點(diǎn)或邊請求路由到同一個讀 cache 節(jié)點(diǎn)上，以保證讀取數(shù)據(jù)一致性。
3）主節(jié)點(diǎn)異常場景：
Leader 節(jié)點(diǎn)收到更新請求后，會將更新請求變?yōu)?invalidate cache 請求異步的發(fā)送給其他 follower，以保證 follower 上的數(shù)據(jù)最終一致。在異常情況下，如果 Leader 發(fā)送的隊列已滿導(dǎo)致 invalidate cache 請求丟失，那么會將其他的 follower cache 全部清除掉。
如果 Leader 故障，新選舉的 Leader 也會通知其他 follower 將 cache 清除。
此外，Leader 會對訪問 MySQL 的請求進(jìn)行限流，從而保證即使個別分片的cache被清除掉也不會將 MySQL 打崩。
4）少量強(qiáng)一致的請求：
由于 MySQL 的從庫也提供讀服務(wù)，對于少量要求強(qiáng)一致的讀請求，客戶端可以將請求染上特殊標(biāo)志，REDtao 會透傳該標(biāo)志，數(shù)據(jù)庫 Proxy 層會根據(jù)該標(biāo)志將讀請求轉(zhuǎn)發(fā)到 MySQL 主庫上，從而保證數(shù)據(jù)的強(qiáng)一致。
10、 跨云多活設(shè)計
跨云多活是公司的重要戰(zhàn)略，也是 REDtao 支持的一個重要特性。
REDtao 的跨云多活架構(gòu)整體如下：
這里不同于 Facebook Tao 的跨云多活實(shí)現(xiàn)，F(xiàn)acebook Tao 的跨云多活實(shí)現(xiàn)如下圖所示。
Facebook 的方案依賴于底層的 MySQL 的主從復(fù)制都通過 DTS Replication 來做。而 MySQL 原生的主從復(fù)制是自身功能，DTS 服務(wù)并不包含 MySQL 的主從復(fù)制。該方案需要對 MySQL 和 DTS 做一定的改造。前面說到，我們的緩存和持久層是解藕的，在架構(gòu)上不一樣。
因此，REDtao 的跨云多活架構(gòu)是我們結(jié)合自身場景下的設(shè)計，它在不改動現(xiàn)有 MySQL 功能的前提下實(shí)現(xiàn)了跨云多活功能。
1）持久層我們通過 MySQL 原生的主從 binlog 同步將數(shù)據(jù)復(fù)制到其他云的從庫上。其他云上的寫請求和少量要求強(qiáng)一致讀將被轉(zhuǎn)發(fā)到主庫上。正常的讀請求將讀取本區(qū)的 MySQL 數(shù)據(jù)庫，滿足讀請求對時延的要求。
2）緩存層的數(shù)據(jù)一致性是通過 MySQL DTS 訂閱服務(wù)實(shí)現(xiàn)的，將 binlog 轉(zhuǎn)換為 invalidate cache 請求，以清理掉本區(qū) REDtao cache 層的 stale 數(shù)據(jù)。由于讀請求會隨機(jī)讀取本區(qū)的任何一個 MySQL 數(shù)據(jù)庫，因此 DTS 訂閱使用了一個延遲訂閱的功能，保證從 binlog 同步最慢的節(jié)點(diǎn)中讀取日志，避免 DTS 的 invalidate cache 請求和本區(qū) read cache miss 的請求發(fā)生沖突從而導(dǎo)致數(shù)據(jù)不一致。
11、云原生實(shí)現(xiàn)
REDtao 的云原生特性重點(diǎn)體現(xiàn)在彈性伸縮、支持多 AZ 和 Region 數(shù)據(jù)分布、產(chǎn)品可以實(shí)現(xiàn)在不同的云廠商間遷移等幾個方面。REDtao 在設(shè)計之初就考慮到支持彈性擴(kuò)縮容、故障自動檢測及恢復(fù)。
隨著 Kubernetes 云原生技術(shù)越來越成熟，我們也在思考如何利用 k8s 的能力將部署和虛擬機(jī)解綁，進(jìn)一步云原生化，方便在不同的云廠商之間部署和遷移。
REDtao 實(shí)現(xiàn)了一個運(yùn)行在 Kubernetes 集群上的 Operator，以實(shí)現(xiàn)更快的部署、擴(kuò)容和壞機(jī)替換。
為了讓 k8s 能感知集群分片的分配并且控制同一分片下的 Pods 調(diào)度在不同宿主機(jī)上，集群分組分片分配由 k8s Operator 渲染并控制創(chuàng)建 DuplicateSet （小紅書自研 k8s 資源對象）。
REDtao 則會創(chuàng)建主從并根據(jù) Operator 渲染出來的分片信息創(chuàng)建集群，單個 Pod 故障重啟會重新加入集群，無需重新創(chuàng)建整個集群。集群升級時，Operator 通過感知主從分配控制先從后主的順序，按照分片分配的順序滾動升級以減少升級期間線上影響。
12、老服務(wù)的平滑升級實(shí)踐
但凡變革，皆屬不易。實(shí)現(xiàn)全新的 REDtao 只是完成了相對容易的那部分工作。
小紅書的社交圖譜數(shù)據(jù)服務(wù)已經(jīng)在 MySQL 上運(yùn)行多年，有很多不同的業(yè)務(wù)跑在上面，任何小的問題都會影響到小紅書的在線用戶。因此，如何保證不停服的情況下讓現(xiàn)有業(yè)務(wù)無感知地遷移到 REDtao 上成為一個非常大的挑戰(zhàn)。
我們的遷移工作關(guān)鍵有兩點(diǎn)：
1）將老的大 MySQL 集群按優(yōu)先級拆分成了四個 REDtao 集群。這樣，我們可以先將優(yōu)先級最低的服務(wù)遷移到一個 REDtao 集群，充分灰度后再遷移高優(yōu)先級的集群；
2）專門開發(fā)了一個 Tao Proxy SDK，支持對原來的 MySQL 集群和 REDtao 集群進(jìn)行雙寫雙讀，數(shù)據(jù)校驗比對。
遷移時：我們首先將低優(yōu)先級的數(shù)據(jù)從 MySQL 通過 DTS 服務(wù)遷移到了一個 REDtao 集群，并升級好業(yè)務(wù)方的 SDK 。DTS 服務(wù)一直對增量數(shù)據(jù)進(jìn)行同步。業(yè)務(wù)方 SDK 會訂閱配置中心的配置變更，我們修改配置讓 Tao Proxy SDK 同時讀寫 MySQL 集群和 REDtao 集群，并關(guān)閉 DTS 服務(wù)。此時會使用 MySQL 集群的結(jié)果返回給用戶。
在停止 DTS 服務(wù)時：有可能會有新的 MySQL 數(shù)據(jù)通過 DTS 同步過來，造成了 REDtao 集群新寫的數(shù)據(jù)被同步過來的老數(shù)據(jù)覆蓋。因此，在關(guān)閉 DTS 服務(wù)后，我們會通過工具讀取開雙寫之后到關(guān)閉 DTS 服務(wù)這個時間段的 binlog 對數(shù)據(jù)進(jìn)行校驗和修復(fù)。
修復(fù)完成之后：Tao Proxy SDK 的雙讀會展示兩邊不一致的數(shù)據(jù)量，并過濾掉因為雙寫時延不一致導(dǎo)致數(shù)據(jù)不一致的請求?；叶纫欢螘r間后觀察到 diff 的數(shù)目基本為 0，將 Tao Proxy SDK 的配置改為只讀寫新的 REDtao 集群。
最終：我們在 22 年初完成小紅書所有核心社交圖譜萬億邊級別數(shù)據(jù)的遷移和正確性校驗，并做到了整個遷移服務(wù)無感知，遷移過程沒有發(fā)生一起故障。
13、新圖存儲系統(tǒng)帶來的結(jié)果和收益
我們的社交圖譜數(shù)據(jù)訪問中，90% 以上的請求都是讀請求，并且社交圖譜的數(shù)據(jù)有非常強(qiáng)的時間局部性（即最近更新的數(shù)據(jù)最容易被訪問）。REDtao 上線后，獲得 90% 以上的 cache 命中率， 對MySQL 的 QPS 降低了 70%+ ，大大降低了 MySQL 的 CPU 使用率。在縮容 MySQL 的副本數(shù)目后，整體成本降低了21.3%。
業(yè)務(wù)的訪問方式都全部收斂到 REDtao 提供的 API 接口上，在遷移過程中，我們還治理了一些老的不合理訪問 MySQL 數(shù)據(jù)庫的方式，以及自定義某些字段賦予特殊含義的不合理做法，通過 REDtao 規(guī)范了數(shù)據(jù)訪問。
對比 2022 年初和 2023 年初，隨著 DAU 的增長，社交圖譜的請求增長了 250% 以上，如果是之前 MySQL 的老架構(gòu)，擴(kuò)容資源基本上和請求增長速度成正比，至少需要擴(kuò)容 1 倍的資源成本（數(shù)萬核）。
而得益于 REDtao 系統(tǒng)的存在，因其 90% 的緩存命中率，實(shí)際上整體成本只增加了 14.7%（數(shù)千核）就能扛下 2.5 倍的請求增長。在成本和穩(wěn)定性上有了較大的提升。
14、未來展望
在較短的時間，我們自研了圖存儲系統(tǒng) REDtao ，解決了社交圖譜關(guān)系數(shù)據(jù)快速增長的問題。
REDtao 借鑒了 FaceBook Tao 的論文，并對整體架構(gòu)、跨云多活做了較多的改進(jìn)，全新實(shí)現(xiàn)了一個高性能的分布式圖緩存，更加貼合我們自身的業(yè)務(wù)特點(diǎn)和提供了更好的彈性。同時，利用 k8s 能力進(jìn)一步實(shí)現(xiàn)了云原生化。
隨著 DAU 的持續(xù)增長，萬億的數(shù)據(jù)規(guī)模也在繼續(xù)增長，我們也面臨著更多的技術(shù)挑戰(zhàn)。
目前公司內(nèi)部的 OLTP 圖場景主要分為三塊：
1）社交圖譜數(shù)據(jù)服務(wù)：通過自研圖存儲系統(tǒng) REDtao 滿足了社交場景超大規(guī)模數(shù)據(jù)的更新與關(guān)聯(lián)讀取問題。目前已經(jīng)存儲了萬億規(guī)模的關(guān)系；
2）風(fēng)控場景：通過自研圖數(shù)據(jù)庫 REDgraph，滿足多跳的實(shí)時在線查詢。目前存儲了千億點(diǎn)和邊的關(guān)系，滿足 2 跳以及 2 跳以上的查詢；
3）社交推薦：這塊主要是兩跳的查詢。每天通過 Hive 批量地導(dǎo)入全量的數(shù)據(jù)，通過 DTS 服務(wù)近實(shí)時的寫入更新數(shù)據(jù)。因為是在線場景，對時延的要求非常高，當(dāng)前的 REDgraph 還無法滿足這么高的要求，因此業(yè)務(wù)方主要是用 REDkv 來存儲。
針對以上場景：為了快速滿足業(yè)務(wù)需求，我們使用了三套不同的自研存儲系統(tǒng)：REDtao 、REDgraph 和 REDkv 。
顯然相對于 3 套存儲系統(tǒng)，用一個統(tǒng)一的架構(gòu)和系統(tǒng)去解決這幾個圖相關(guān)的場景是更加合適的。
未來：我們會將 REDgraph 和 REDtao 融合成一個統(tǒng)一的數(shù)據(jù)庫產(chǎn)品，打造業(yè)內(nèi)頂尖的圖技術(shù)，對公司內(nèi)部更多的場景進(jìn)行賦能。
15、相關(guān)資料
[1] 以微博類應(yīng)用場景為例，總結(jié)海量社交系統(tǒng)的架構(gòu)設(shè)計步驟
[2] 騰訊技術(shù)分享：社交網(wǎng)絡(luò)圖片的帶寬壓縮技術(shù)演進(jìn)之路
[3] 基于社交網(wǎng)絡(luò)的Yelp是如何實(shí)現(xiàn)海量用戶圖片的無損壓縮的？
[4] 社交軟件紅包技術(shù)解密(一)：全面解密QQ紅包技術(shù)方案——架構(gòu)、技術(shù)實(shí)現(xiàn)等
[5] 社交軟件紅包技術(shù)解密(六)：微信紅包系統(tǒng)的存儲層架構(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] 中國互聯(lián)網(wǎng)社交二十年：全民見證的互聯(lián)網(wǎng)創(chuàng)業(yè)演義
[9] 盤點(diǎn)移動互聯(lián)網(wǎng)時代的社交產(chǎn)品進(jìn)化史（上篇）：誰主沉浮
[10] 盤點(diǎn)移動互聯(lián)網(wǎng)時代的社交產(chǎn)品進(jìn)化史（下篇）：大浪淘沙
（本文已同步發(fā)布于：http://www.52im.net/thread-4495-1-1.html）