作者 | Eran Stiller

譯者 | 劉雅夢

領(lǐng)英（LinkedIn）今天宣布了一個可擴(kuò)展的日志存儲系統(tǒng) Northguard，它取代了 Kafka，以及一個虛擬化的 Pub/Sub 層 Xinfra。Northguard 提供了分片數(shù)據(jù)和元數(shù)據(jù)、日志條帶化、強(qiáng)一致性和自平衡集群，規(guī)模比 Kafka 更大，而 Xinfra 則實(shí)現(xiàn)了在 Kafka 和 Northguard 之間的無縫遷移和統(tǒng)一訪問。

根據(jù) LinkedIn 的工程師表示，Kafka 在 LinkedIn 的規(guī)模下（每天 32T 記錄、17PB 數(shù)據(jù)、400K 主題、150 個集群）變得越來越難以管理。Northguard 的架構(gòu)由共享數(shù)據(jù)和元數(shù)據(jù)、去中心化協(xié)調(diào)和最小全局狀態(tài)組成，消除了 Kafka 的單控制器和基于分區(qū)的限制。

Northguard 的數(shù)據(jù)模型將日志組織成記錄、段、范圍和主題。記錄（鍵、值、頭）被寫入段——不可變的復(fù)制單元。段形成范圍，代表連續(xù)的鍵空間切片，支持動態(tài)分割和合并，以實(shí)現(xiàn)擴(kuò)展和排序。另一方面，主題是覆蓋整個鍵空間的范圍集合，具有靈活的存儲策略，可用于復(fù)制和保留。

包含三個段的 Northguard 范圍（來源）

這種細(xì)粒度結(jié)構(gòu)實(shí)現(xiàn)了平衡負(fù)載、高可用性和無縫擴(kuò)展。當(dāng)生產(chǎn)者產(chǎn)生新的段時，代理自然會自我平衡，從而消除了在添加代理或代理失敗時進(jìn)行昂貴的重新平衡或數(shù)據(jù)移動的需求。

新段被添加到范圍中，并被分配給可能的新代理（來源）

與傳統(tǒng)的 索引分區(qū) 相比，范圍提供了更靈活的擴(kuò)展機(jī)制。范圍分割只中斷客戶端對受影響范圍（而不是整個主題）的寫入，同時保持總排序保證。這種差異減少了中斷，并避免了昂貴的“停止世界”同步。此外，跨主題對齊的范圍通過減少對洗牌的需要來簡化流處理連接。

Northguard 的元數(shù)據(jù)模型使用分片的、基于 Raft) 的 復(fù)制狀態(tài)機(jī)（DS-RSM），分布在虛擬節(jié)點(diǎn)上。每個虛擬節(jié)點(diǎn)管理主題、范圍和段的元數(shù)據(jù)——跟蹤狀態(tài)變化（例如，拆分、合并、密封）、副本集和保留策略。通過使用一致性哈希分片元數(shù)據(jù)和去中心化協(xié)調(diào)，Northguard 避免了 Kafka 的控制器瓶頸，并支持?jǐn)?shù)百萬副本的強(qiáng)一致性和高可用性。

LinkedIn 為性能和持久性優(yōu)化了 Northguard 的協(xié)議。元數(shù)據(jù)操作（如創(chuàng)建、刪除、查詢）使用路由到虛擬節(jié)點(diǎn)領(lǐng)導(dǎo)者的單一請求 / 響應(yīng)調(diào)用。生產(chǎn)、消費(fèi)和復(fù)制流是帶有管道和窗口的會話化流協(xié)議，以最大化吞吐量和最小化延遲。

生產(chǎn)者寫入活躍的段領(lǐng)導(dǎo)者，只有在所有副本上 fsync 后才接收確認(rèn)，確保強(qiáng)持久性。消費(fèi)者使用帶有客戶端控制流的類似流模型，支持高效的高吞吐量讀取?；顒佣螐?fù)制和密封段復(fù)制利用相同的高效流架構(gòu)，從而實(shí)現(xiàn) Northguard 的高性能和自我修復(fù)能力。

在 LinkedIn 的規(guī)模上，從 Kafka 遷移到 Northguard 需要為數(shù)千個關(guān)鍵應(yīng)用程序?qū)崿F(xiàn)無縫、零停機(jī)轉(zhuǎn)換。為了支持這一點(diǎn)，LinkedIn 構(gòu)建了 Xinfra，一個虛擬化的 Pub/Sub 層，抽象了物理集群。Xinfra 通過雙寫機(jī)制使主題能夠跨越 Kafka 和 Northguard，允許在不更改客戶端的情況下進(jìn)行實(shí)時遷移。

一個示例用例，其中消費(fèi)者訂閱了同一虛擬集群下的三個主題，每個主題位于不同的集群中（來源）

Northguard 中的分段存儲是可插拔的，默認(rèn)的“fps-store”實(shí)現(xiàn)針對持久性和延遲進(jìn)行了優(yōu)化。它使用提前寫日志（write-ahead log， WAL），每個段創(chuàng)建一個文件，應(yīng)用 Direct I/O 來繞過 OS 緩沖，并在 RocksDB 中維護(hù)一個稀疏索引。在幾毫秒內(nèi)刷新和跨副本同步成批記錄，即使在故障情況下也能確保持久性。這種設(shè)計(jì)避免了緩存不一致，支持從舊段中高效讀取，并允許隨著集群的增長而預(yù)測性能。

為了確保大規(guī)模的可靠性，Northguard 在確定性模擬下進(jìn)行了嚴(yán)格的測試。整個集群和客戶端在單線程的受控環(huán)境中運(yùn)行，在這種環(huán)境中，故障（如代理關(guān)閉、網(wǎng)絡(luò)分區(qū)、磁盤錯誤和滾動升級）會被注入和重放。這種方法允許 LinkedIn 每天模擬多年的活動，及早捕捉邊緣情況，并在復(fù)雜的故障場景下持續(xù)驗(yàn)證正確性。

LinkedIn 的工程師表示，他們“已經(jīng)成功地將數(shù)千個主題從 Kafka 遷移到 Northguard，每天處理數(shù)萬億條記錄”，并且 LinkedIn 超過 90% 的應(yīng)用程序已經(jīng)在運(yùn)行 Xinfra 客戶端了。

InfoQ 聯(lián)系了 LinkedIn，希望將 Northguard 和 Xinfra 開源。LinkedIn 表示，他們“專注于在我們內(nèi)部系統(tǒng)中完成 Northguard 和 Xinfra 的實(shí)施，并且隨著我們繼續(xù)構(gòu)建、學(xué)習(xí)和迭代這些工具，我們將探索開源它們的可能性?！?/p>

https://www.infoq.com/news/2025/06/linkedin-northguard-xinfra/

聲明：本文由 InfoQ 翻譯，未經(jīng)許可禁止轉(zhuǎn)載。

InfoQ 老友！請留步！極客邦 1 號客服上線工作啦！

后續(xù)我將通過微信視頻號，以視頻的形式持續(xù)更新技術(shù)話題、未來發(fā)展趨勢、創(chuàng)業(yè)經(jīng)驗(yàn)、商業(yè)踩坑教訓(xùn)等精彩內(nèi)容，和大家一同成長，開啟知識交流之旅