一、引言

Apache Kafka 無處不在。它是分布式消息傳遞的首選，為全球眾多公司提供各種用例服務(wù)，包括消息傳遞、日志聚合和流處理。

許多公司都在使用它，包括 PayPal、Uber 和 LinkedIn 等大型科技公司。然而，并非所有人都使用 Kafka；他們會(huì)使用其他可用的解決方案，或者……構(gòu)建自己的系統(tǒng)。在今天的文章中，我們將探討 Scribe，這是 Meta 構(gòu)建的一個(gè)消息隊(duì)列服務(wù)，用以支撐全球規(guī)模的流量。

圖片

二、術(shù)語

在繼續(xù)之前，我們首先了解一些 Scribe 的概念：

首先是 Category。它向用戶展示了一個(gè)邏輯流的概念。

圖片

與 Kafka 類似，向 Category 寫入和讀取數(shù)據(jù)的客戶端也被稱為生產(chǎn)者和消費(fèi)者。兩者都以庫的形式實(shí)現(xiàn)。一個(gè)應(yīng)用程序可以根據(jù)需要擁有多個(gè)生產(chǎn)者和消費(fèi)者實(shí)例。

圖片

對(duì)于消費(fèi)消息，一組消費(fèi)者可以共同處理來自一個(gè) Category 的消息。數(shù)據(jù)可以根據(jù)消息的鍵或值被分割成邏輯分片。一個(gè)消費(fèi)者可以只讀取來自一個(gè)邏輯分片的消息。Scribe 允許整個(gè)流量在消費(fèi)者組之間任意分配，而無需依賴分片方案。

圖片

還有一個(gè)物理分片的概念，它們是包含與消息負(fù)載相關(guān)聯(lián)的元數(shù)據(jù)的日志文件。我們將在后面更詳細(xì)地探討。

三、高層架構(gòu)

從寫入路徑來看，生產(chǎn)者實(shí)例接收來自用戶的消息，對(duì)它們進(jìn)行批處理，然后將它們發(fā)送給 ScribeD。在這個(gè)階段，一個(gè)批次可能包含來自不同 Category 的消息。然后，ScribeD 將這些批次發(fā)送給寫入代理。

消息隨后被拆分，使得來自同一 Category 的消息屬于同一批次。寫入代理然后將這些批次路由到批處理服務(wù)。批處理服務(wù)持久化這些批次并提交它們的元數(shù)據(jù)。

圖片

對(duì)于讀取路徑，消費(fèi)者實(shí)例聯(lián)系讀取流服務(wù)，從元數(shù)據(jù)存儲(chǔ)中檢索元數(shù)據(jù)。然后，消費(fèi)者使用元數(shù)據(jù)中的信息（例如，從哪里讀取元數(shù)據(jù)）來形成對(duì)讀取代理的請(qǐng)求。該代理管理所有相關(guān)的數(shù)據(jù)訪問操作。

接下來，我們將更深入地探討寫入/讀取操作的細(xì)節(jié)，以及數(shù)據(jù)是如何存儲(chǔ)的。

四、寫入

生產(chǎn)者庫是入口點(diǎn)。可以在多個(gè)主機(jī)上啟動(dòng)多個(gè)生產(chǎn)者實(shí)例。當(dāng)應(yīng)用程序向生產(chǎn)者庫發(fā)出寫入請(qǐng)求時(shí)，它們將獲得一個(gè)包含寫入操作結(jié)果的對(duì)象。

圖片

為了節(jié)省內(nèi)存占用，生產(chǎn)者將來自多個(gè) Category 的消息在內(nèi)存中批量聚合。生產(chǎn)者將消息批次刷新到 ScribeD，這是一個(gè)本地守護(hù)進(jìn)程，它接收來自主機(jī)上所有生產(chǎn)者實(shí)例的消息，并最終將它們發(fā)送到寫入代理。

圖片

ScribeD 的主要目標(biāo)是通過將生產(chǎn)者刷新（在內(nèi)存中）的消息緩沖到磁盤上，來確保這些消息的容錯(cuò)性。這種方法可以防止在寫入持久化存儲(chǔ)時(shí)發(fā)生故障導(dǎo)致數(shù)據(jù)丟失。

圖片

在接收消息批次后，寫入代理首先對(duì)這些消息執(zhí)行準(zhǔn)入控制檢查，然后將來自同一 Category 的消息拆分到同一批次中。這些批次被路由到批處理服務(wù)。

批處理服務(wù)壓縮批次數(shù)據(jù)并將其刷新到臨時(shí)數(shù)據(jù)存儲(chǔ)和持久化負(fù)載存儲(chǔ)。之后，批處理服務(wù)將這些批次的元數(shù)據(jù)（包括指向批次數(shù)據(jù)的指針）寫入基于日志的元數(shù)據(jù)存儲(chǔ)。這些元數(shù)據(jù)將幫助 Scribe 為消費(fèi)者提供順序的、流式抽象的讀取模式。

五、存儲(chǔ)

如前所述，Meta 將元數(shù)據(jù)和數(shù)據(jù)分離開。消息元數(shù)據(jù)存儲(chǔ)在 LogDevice 中，這是一個(gè)為順序數(shù)據(jù)讀寫操作優(yōu)化的基于日志的存儲(chǔ)系統(tǒng)。

1、元數(shù)據(jù)存儲(chǔ)

對(duì)于每個(gè) Category，LogDevice 將每個(gè)數(shù)據(jù)批次的元數(shù)據(jù)追加到一個(gè)稱為 log 的文件中。每個(gè)日志都是該 Category 的一個(gè)物理分片。日志文件中的每個(gè)記錄都有一個(gè)單調(diào)遞增的序列號(hào)。

圖片

Meta 在 LogDevice 集群中存儲(chǔ)了數(shù)百萬個(gè)日志。每個(gè) LogDevice 集群包含存儲(chǔ)節(jié)點(diǎn)。每個(gè)記錄可以在這些節(jié)點(diǎn)的任意子集上進(jìn)行復(fù)制，確保數(shù)據(jù)冗余。

2、持久化數(shù)據(jù)存儲(chǔ)（DDS）

所有消息負(fù)載都存儲(chǔ)在 Tectonic 中，這是 Meta 構(gòu)建的用于替代 HDFS 的分布式文件系統(tǒng)。這個(gè)文件系統(tǒng)也是其他系統(tǒng)的支柱，例如 Meta 的數(shù)據(jù)倉庫。

Tectonic 不是基于一個(gè)因子完全復(fù)制負(fù)載，而是支持糾刪碼來確保數(shù)據(jù)可靠性。與簡單的復(fù)制相比，存儲(chǔ)占用空間會(huì)更??；然而，在發(fā)生故障需要數(shù)據(jù)重建時(shí)，這種方法將需要更多資源。

圖片

為了控制數(shù)據(jù)塊的數(shù)量，Scribe 可以將來自多個(gè) Category 的數(shù)據(jù)存儲(chǔ)在同一個(gè)塊中。寫入代理累積大小達(dá)到幾十兆字節(jié)級(jí)別的塊，然后執(zhí)行刷新操作到 Tectonic 存儲(chǔ)節(jié)點(diǎn)的磁盤。在一個(gè)塊中，來自同一 Category 的數(shù)據(jù)也會(huì)被累積起來，以更有效地服務(wù)讀取操作，累積大小最高可達(dá) 2 兆字節(jié)。

3、臨時(shí)數(shù)據(jù)存儲(chǔ)（EDS）

除了持久化存儲(chǔ)，消息負(fù)載也存在于區(qū)域性的臨時(shí)數(shù)據(jù)存儲(chǔ)中，這本質(zhì)上是一個(gè)具有兩層結(jié)構(gòu)的緩存：本地緩存和遠(yuǎn)程緩存。

這一點(diǎn)很重要，因?yàn)?DDS 可能位于與讀取用戶不同的區(qū)域。一個(gè) Category 通常從全球運(yùn)行的生產(chǎn)者那里接收輸入數(shù)據(jù)記錄。這導(dǎo)致當(dāng)消費(fèi)者發(fā)出讀取請(qǐng)求時(shí)，它從不同區(qū)域讀取大部分?jǐn)?shù)據(jù)。

EDS 在這里起到了救援作用，因?yàn)樗试S用戶從不同區(qū)域訪問 DDS。其目標(biāo)是盡量減少對(duì)包含實(shí)際負(fù)載數(shù)據(jù)的遠(yuǎn)程存儲(chǔ)的訪問。

除了降低延遲和避免對(duì) Tectonic 的壓力之外，EDS 的其他有趣職責(zé)將在本文后面討論。

圖片

對(duì)于遠(yuǎn)程層，Meta 利用 Memcached 來存儲(chǔ)消息負(fù)載，存儲(chǔ)時(shí)長為 1-2 小時(shí)。Meta 認(rèn)為這段時(shí)間對(duì)于想要消費(fèi)被認(rèn)為是“溫”數(shù)據(jù)的用戶來說已經(jīng)足夠。對(duì)于更“熱”的數(shù)據(jù)，Meta 使用 Cachelib 來管理緩存，它利用讀取代理主機(jī)的空閑內(nèi)存資源。我們將在討論讀取路徑時(shí)更深入地探討 EDS。

六、讀取

讀取路徑的入口點(diǎn)也是一個(gè)名為 Consumers 的庫。應(yīng)用程序通常啟動(dòng)一組消費(fèi)者實(shí)例來從 Category 讀取數(shù)據(jù)。當(dāng)用戶啟動(dòng)一個(gè)消費(fèi)者實(shí)例時(shí)，會(huì)生成一個(gè)到讀取流服務(wù)的有狀態(tài)連接。

Meta 嘗試以確保消費(fèi)者實(shí)例和讀取流服務(wù)位于同一區(qū)域的方式建立連接。該讀取流服務(wù)負(fù)責(zé)（在元數(shù)據(jù)的幫助下）為用戶提供流抽象。

該服務(wù)的一個(gè)實(shí)例擁有一個(gè)到 LogDevice 集群的連接池。當(dāng)它收到消費(fèi)者請(qǐng)求時(shí)，它會(huì)根據(jù)消費(fèi)者的輸入，識(shí)別所有必需的 LogDevice 集群、物理分片以及要讀取的分片范圍。

圖片

一個(gè)不同的實(shí)例（稱為讀取器）將處理從 LogDevice 集群實(shí)際讀取數(shù)據(jù)的操作。這個(gè)讀取流實(shí)例合并來自讀取器的結(jié)果，為消費(fèi)者提供單一的元數(shù)據(jù)流。

消費(fèi)者使用這個(gè)元數(shù)據(jù)（包括數(shù)據(jù)指針）向讀取代理發(fā)出 RPC 請(qǐng)求以獲取負(fù)載。讀取代理的主要工作是處理與訪問負(fù)載存儲(chǔ)相關(guān)的所有事情。

圖片

當(dāng)收到來自消費(fèi)者的請(qǐng)求時(shí)，讀取代理嘗試從區(qū)域臨時(shí)數(shù)據(jù)存儲(chǔ)中獲取數(shù)據(jù)。數(shù)據(jù)可能存在于 Memcached 實(shí)例的內(nèi)存緩存中。

如果讀取代理必須訪問持久化數(shù)據(jù)存儲(chǔ)，則該請(qǐng)求被路由到與 DDS 中存儲(chǔ)的負(fù)載位于同一區(qū)域的讀取代理實(shí)例。

• 如果區(qū)域 A 的讀取代理實(shí)例需要存儲(chǔ)在區(qū)域 B 的負(fù)載，它會(huì)將請(qǐng)求路由到位于區(qū)域 B 的實(shí)例。然后數(shù)據(jù)被填充到區(qū)域 B 的 EDS 中。

圖片

• 之后，來自區(qū)域 C 的讀取代理實(shí)例對(duì)同一數(shù)據(jù)的請(qǐng)求將由區(qū)域 B 的 EDS 提供服務(wù)。雖然仍然需要跨區(qū)域通信，但與直接從區(qū)域 B 的 DDS 讀取相比，延遲較低。

如果消費(fèi)者指定了任何過濾或序列化選項(xiàng)，讀取代理將對(duì)其訪問的消息應(yīng)用這些選項(xiàng)。

圖片

• Meta 將讀取代理設(shè)計(jì)為數(shù)據(jù)暫存區(qū)。在將數(shù)據(jù)填充到 EDS 時(shí)，讀取代理將 Category 的負(fù)載從其原始格式轉(zhuǎn)換為列式格式，以幫助消費(fèi)應(yīng)用程序避免這個(gè)昂貴的過程，特別是當(dāng)它們需要數(shù)據(jù)進(jìn)行分析工作負(fù)載時(shí)。
• 讀取代理還可以應(yīng)用消費(fèi)應(yīng)用程序過濾器的下推；它可以評(píng)估 SQL 查詢的一個(gè)子集。

七、元數(shù)據(jù)如何管理

元數(shù)據(jù)是 Scribe 的核心。許多組件需要訪問元數(shù)據(jù)存儲(chǔ)來支持寫入和讀取操作。盡管 LogDevice 是一個(gè)事務(wù)性的、高可用的數(shù)據(jù)庫，但數(shù)百萬客戶端嘗試查詢?cè)獢?shù)據(jù)則是另一回事。

為了解決這個(gè)問題，Meta 在元數(shù)據(jù)存儲(chǔ)之上構(gòu)建了一個(gè)緩存和分發(fā)層。有一個(gè)后臺(tái)作業(yè)會(huì)掃描整個(gè)元數(shù)據(jù)數(shù)據(jù)庫，并將內(nèi)容填充到一個(gè)配置分發(fā)系統(tǒng)中?？蛻舳丝梢詮拇颂幾x取元數(shù)據(jù)。

圖片

對(duì)于更詳細(xì)的元數(shù)據(jù)，例如包含指向所需數(shù)據(jù)的指針的物理分片，一個(gè)周期性作業(yè)會(huì)輪詢 LogDevice 集群以檢索集群、Category 和物理分片之間的最新映射關(guān)系，并將該映射關(guān)系暴露在一個(gè)高度復(fù)制的數(shù)據(jù)庫中。

圖片

對(duì)于來自消費(fèi)者的請(qǐng)求，讀取流服務(wù)實(shí)例訂閱相關(guān)的映射關(guān)系。當(dāng)在運(yùn)行時(shí)添加或刪除物理分片時(shí)，映射關(guān)系可能會(huì)發(fā)生變化。基于這些信息，服務(wù)可以相應(yīng)地啟動(dòng)或停止讀取器實(shí)例。

八、流量如何管理

為了應(yīng)對(duì)全球規(guī)模的流量，Scribe 在不同層級(jí)利用了多層流量管理系統(tǒng)。

集群內(nèi)流量整形： Scribe 動(dòng)態(tài)調(diào)整其內(nèi)部資源以處理單個(gè) LogDevice 集群內(nèi)的流量。當(dāng)特定 Category 出現(xiàn)流量激增時(shí)，一項(xiàng)服務(wù)會(huì)自動(dòng)將其現(xiàn)有的物理分片拆分成更小的分片，以確保該 Category 的水平可擴(kuò)展性。當(dāng)流量下降時(shí)，系統(tǒng)會(huì)在多余的分片超過保留期后逐漸移除它們。

圖片

集群間流量整形： 控制平面持續(xù)監(jiān)控每個(gè) LogDevice 集群的寫入和讀取工作負(fù)載，以調(diào)整傳入的寫入工作負(fù)載限制，確保集群不會(huì)被壓垮。

圖片

當(dāng)達(dá)到限制時(shí)，寫入代理可以將流量路由到同一區(qū)域內(nèi)的另一個(gè) LogDevice 集群。如果過載是全球性的，則使用優(yōu)雅降級(jí)方法來保護(hù)系統(tǒng)。

主機(jī)級(jí)流量整形： 在單個(gè)服務(wù)器級(jí)別，Scribe 使用 Meta 的服務(wù)網(wǎng)格來路由流量。服務(wù)網(wǎng)格使用主機(jī)暴露的負(fù)載指標(biāo)來將請(qǐng)求路由到負(fù)載最輕的服務(wù)器。

圖片

當(dāng)服務(wù)器接受一個(gè)將在長時(shí)間內(nèi)消耗大量資源的請(qǐng)求時(shí)，它會(huì)立即通告一個(gè)“虛假的”高負(fù)載指標(biāo)。這個(gè)高值告訴系統(tǒng)的其余部分，該服務(wù)器已被“預(yù)留”，即使實(shí)際的資源使用尚未開始。

圖片

然后服務(wù)器指數(shù)級(jí)衰減這個(gè)負(fù)載值。負(fù)載指標(biāo)隨著時(shí)間的推移逐漸降低。等到請(qǐng)求的實(shí)際資源消耗變得明顯時(shí)，人工設(shè)置的值已經(jīng)衰減到能夠反映服務(wù)器實(shí)際負(fù)載的程度。

這個(gè)機(jī)制至關(guān)重要，因?yàn)樗梢苑乐狗?wù)網(wǎng)格將過多請(qǐng)求路由到已經(jīng)在處理繁重工作負(fù)載的服務(wù)器。如果沒有它，服務(wù)網(wǎng)格會(huì)在一個(gè)長時(shí)間請(qǐng)求的最初幾秒內(nèi)認(rèn)為主機(jī)空閑，并假定該服務(wù)器能夠處理新的請(qǐng)求。

對(duì)于特定任務(wù)，Scribe 使用一致性哈希將請(qǐng)求分配給特定主機(jī)，這有助于最大化效率。這在諸如寫入代理將特定數(shù)據(jù) Category 的消息組發(fā)送到同一個(gè)批處理服務(wù)主機(jī)，或者當(dāng)請(qǐng)求需要路由到特定的讀取代理主機(jī)以利用該主機(jī)上的內(nèi)存緩存等用例中很有幫助。

九、臨時(shí)數(shù)據(jù)如何管理

如上所述，Scribe 在臨時(shí)數(shù)據(jù)存儲(chǔ)中管理數(shù)據(jù)副本，目的是：

• 防止頻繁訪問持久化存儲(chǔ)，從而減少跨區(qū)域網(wǎng)絡(luò)流量的延遲
• 為分析應(yīng)用程序以更具讀取效率的格式表示數(shù)據(jù)

Scribe 圍繞資源使用一種約束滿足模型，例如持久化存儲(chǔ) IO 或 Memcached 網(wǎng)絡(luò)利用率，來確定創(chuàng)建哪些副本以及創(chuàng)建在何處。系統(tǒng)的“控制平面”基于幾個(gè)因素做出這些決策，旨在在資源限制內(nèi)最大化收益。考慮的關(guān)鍵因素包括：

• 讀取扇出： 有多少讀取器正在訪問特定的數(shù)據(jù) Category？
• 消息新鮮度： 消費(fèi)者主要是讀取最新的消息還是舊消息？
• 數(shù)據(jù)過濾： 臨時(shí)數(shù)據(jù)存儲(chǔ)中的新副本能否顯著減少需要傳輸?shù)臄?shù)據(jù)量？
• 反序列化成本： 讀取代理是否需要執(zhí)行成本高昂的數(shù)據(jù)格式轉(zhuǎn)換？臨時(shí)數(shù)據(jù)存儲(chǔ)中格式合適的副本可以節(jié)省反序列化過程的成本。

根據(jù)數(shù)據(jù)中心特定的資源限制，Scribe 將采用不同的緩存策略以充分利用可用資源。例如，一個(gè) Memcached 出口流量有限的區(qū)域可能會(huì)使用讀取代理內(nèi)存中的副本作為“盾牌”，以防止過多請(qǐng)求沖擊緩存。

Scribe 的控制平面不斷重新計(jì)算這些策略，以適應(yīng)波動(dòng)的工作負(fù)載。

十、支持的保證

Scribe 支持幾種消息傳遞保證：盡力而為、至少一次和可重復(fù)讀取的至少一次。

1、盡力而為

盡力而為保證的總體思路是優(yōu)先考慮吞吐量和可用性。這是為高容量、“發(fā)射后不管”的數(shù)據(jù)流設(shè)計(jì)的權(quán)衡，在這種情況下，快速傳遞大部分?jǐn)?shù)據(jù)比確保每條消息都恰好傳遞一次且保持嚴(yán)格的順序更重要。

從寫入路徑來看：

• 優(yōu)先考慮寫入可用性： 在此保證下，Scribe 的主要目標(biāo)是以最少的資源消耗持久化海量數(shù)據(jù)。
• 機(jī)會(huì)主義路由： 消息被路由到最近或最可用的寫入代理主機(jī)，甚至可以在需要時(shí)路由到另一個(gè)數(shù)據(jù)中心。這確保了即使路徑擁塞，數(shù)據(jù)也能繼續(xù)流動(dòng)。
• 重試和重復(fù)： 如果寫入請(qǐng)求失敗，客戶端將重試調(diào)用。這可能導(dǎo)致同一條消息被成功傳遞多次，從而導(dǎo)致消息重復(fù)。這是為了最大化可用性而已知且可接受的權(quán)衡。
• 可能存在數(shù)據(jù)丟失： 如果寫入調(diào)用失敗且無法恢復(fù)，客戶必須準(zhǔn)備容忍小程度的數(shù)據(jù)丟失。

從讀取路徑來看：

• 收集： Scribe 的寫入路徑將單個(gè) Category 的消息分散到許多物理分片上。讀取此數(shù)據(jù)的消費(fèi)者必須從所有這些分片收集消息。
• 容忍無序： 在所有分片上強(qiáng)制執(zhí)行嚴(yán)格的順序會(huì)引入顯著的延遲并降低吞吐量。為了避免這種情況，Meta 引入了一種配置，允許用戶在延遲和數(shù)據(jù)排序之間進(jìn)行權(quán)衡。

2、至少一次

其主要目標(biāo)是確保每條消息都成功存儲(chǔ)。Scribe 通過以下方式實(shí)現(xiàn)這一點(diǎn)：

存儲(chǔ)確認(rèn)： 客戶端只有在收到存儲(chǔ)層確認(rèn)消息已成功保存后，才認(rèn)為消息已發(fā)送。

圖片

積極重試： 如果消息沒有收到確認(rèn)，它會(huì)被重新發(fā)送。這個(gè)過程在寫入路徑的每一步重復(fù)，直到確認(rèn)消息已保存。

圖片

然而，積極的重試可能導(dǎo)致數(shù)據(jù)重復(fù)。為了最小化這種情況，Scribe 實(shí)施了多項(xiàng)優(yōu)化：

• 主動(dòng)分片初始化： Scribe 預(yù)測并提前初始化物理分片。這可以防止重試因建立新分片的過程而延遲。
• 分級(jí)超時(shí)： 寫入路徑中的每一步都有一個(gè)比前一步更長的超時(shí)時(shí)間。這確保了一步不會(huì)在下一步仍在處理請(qǐng)求時(shí)過早放棄并重試，從而減少不必要的重試和重復(fù)。
• 保守批處理： 對(duì)于需要“至少一次”傳遞的數(shù)據(jù)，Scribe 以較小的批次發(fā)送消息。這意味著如果發(fā)生重試，潛在的重復(fù)事件涉及的消息數(shù)量較少。

3、可重復(fù)讀取

不可重復(fù)讀： 在一個(gè)事務(wù)過程中，如果事務(wù)在不同時(shí)間點(diǎn)看到同一數(shù)據(jù)具有不同的值，則此行為稱為不可重復(fù)讀。

通過可重復(fù)讀取，Scribe 保證消費(fèi)者讀取數(shù)據(jù)流時(shí)，如果重新讀取，將看到相同順序的相同數(shù)據(jù)。這是比上述兩種保證更強(qiáng)的保證，對(duì)于需要嚴(yán)格數(shù)據(jù)排序和可靠處理的用例（如變更數(shù)據(jù)捕獲）至關(guān)重要。

Scribe 提供了兩種不同的方法來實(shí)現(xiàn)這一點(diǎn)，每種方法都有其自身的權(quán)衡：寫入路徑變體和讀取路徑變體。

寫入路徑變體：

圖片

• 它確保邏輯分片的流量被發(fā)送到單個(gè)、專用的物理分片。
• 然而，這將最大吞吐量限制在單個(gè)物理分片能夠處理的范圍內(nèi)。

讀取路徑變體：

圖片

• 一個(gè)內(nèi)部服務(wù)，稱為順序分片生成器，讀取一個(gè) Category 的所有分散的元數(shù)據(jù)分片。
• 然后，生成器根據(jù)下游應(yīng)用程序所需的批次大小，將消息重新排序到一個(gè)新的元數(shù)據(jù)分片中。
• 這為 Category 中的所有消息提供了單一的、確定性的順序。它還允許下游應(yīng)用程序定義自己的批次大小。
• 然而，它向數(shù)據(jù)流添加了一個(gè)額外的步驟，包括額外的操作，從而給整個(gè)系統(tǒng)引入了延遲。

十一、結(jié)語

在本文中，我們首先探討了 Scribe 的術(shù)語，然后深入研究了其架構(gòu)，該架構(gòu)包含許多在讀寫路徑上職責(zé)清晰的組件。Scribe 還將元數(shù)據(jù)與數(shù)據(jù)分離，并引入了緩存層來改進(jìn)讀取路徑。

然后我們更仔細(xì)地了解了 Scribe 如何管理流量、元數(shù)據(jù)以及緩存系統(tǒng)中的數(shù)據(jù)。最后，我們將通過研究 Scribe 提供的幾種消息傳遞保證來結(jié)束本文。

參考資料

• Meta, Scribe: How Meta transports terabytes per second in real time, (2025)https://www.vldb.org/pvldb/vol18/p4817-karpathiotakis.pdf

作者丨Vu Trinh   編譯丨Rio

來源丨網(wǎng)址：https://vutr.substack.com/p/how-did-meta-move-terabytes-of-data