我們?nèi)绾卧O(shè)計一個能存儲數(shù)萬億條信息的系統(tǒng)?

Discord 的消息存儲演進(jìn)給我們提供了真實案例參考。

下圖顯示了 Discord 消息存儲的演變過程：MongoDB -> Cassandra -> ScyllaDB

圖片

第一階段

2015 年，Discord 的第一個版本建立在單個 MongoDB 之上。2015 年 11 月左右，MongoDB 存儲了 1 億條消息，其內(nèi)存無法再容納數(shù)據(jù)和索引。延遲變得不可預(yù)測。消息存儲需要轉(zhuǎn)移到另一個數(shù)據(jù)庫。這時 Cassandra 被選中。

第二階段

2017 年，Discord 擁有 12 個 Cassandra 節(jié)點，存儲了數(shù)十億條消息。

2022 年初，Discord 擁有 177 個 Cassandra 節(jié)點，存儲了數(shù)萬億條消息。此時，延遲再次變得難以預(yù)測，維護(hù)的成本也變得過于昂貴。

造成這一問題有幾個原因：

1. Cassandra 使用 LSM 樹作為內(nèi)部數(shù)據(jù)結(jié)構(gòu)。讀取比寫入更昂貴。在一臺擁有數(shù)百名用戶的服務(wù)器上，可能會有很多并發(fā)讀取，從而導(dǎo)致熱點問題。
2. 維護(hù)集群（如壓縮 SSTables）會影響性能。
3. 垃圾回收會導(dǎo)致明顯的延遲

第三階段

這時，Discord 重新設(shè)計了消息存儲的架構(gòu)：

1. 采用集中式的數(shù)據(jù)服務(wù)，其使用單體 API來訪問，并用 Rust 重寫。
2. 采用基于 ScyllaDB 的存儲。ScyllaDB 是用 C++ 編寫的 Cassandra 兼容數(shù)據(jù)庫。

新架構(gòu)的優(yōu)勢在于：

• 用 C++ 而不是 Java 編寫，消除了垃圾回收暫停的干擾。
• 按核分片模型（Shard-per-Core model）提供更好的負(fù)載隔離，防止熱分區(qū)在節(jié)點間產(chǎn)生級聯(lián)延遲。
• 優(yōu)化了反向查詢性能，以滿足 Discord 的需求。
• 節(jié)點減少到 72 個，同時將每個節(jié)點的磁盤空間增加到 9 TB。

為了進(jìn)一步保護(hù) ScyllaDB，Discord 針對數(shù)據(jù)服務(wù)還做了以下優(yōu)化：

• 在 Rust 中構(gòu)建中間數(shù)據(jù)服務(wù)，限制并發(fā)流量峰值。
• 數(shù)據(jù)服務(wù)位于應(yīng)用程序接口和數(shù)據(jù)庫之間，可聚合請求。
• 即使多個用戶請求相同的數(shù)據(jù)，也只需查詢一次數(shù)據(jù)庫。
• Rust 提供了快速、安全的并發(fā)功能，是這種工作負(fù)載的理想選擇。

優(yōu)化后的系統(tǒng)性能大大提高：

• ScyllaDB 的 p99 讀取延遲為 15 毫秒，而 Cassandra 為 40-125 毫秒。
• ScyllaDB 的 p99 的寫延遲為 5 毫秒，而 Cassandra 為 5-70 毫秒。

該系統(tǒng)可輕松應(yīng)對世界杯流量高峰。

本文參考 Discord blog。