作者 | Alex Woodie

編譯 | 沈建苗

審校 | 云昭

再見 Kafka ！因為它的親爸爸都不堪其痛，親自揮刀要放棄了！

近日，LinkedIn宣布一款全新開發(fā)的發(fā)布/訂閱替代系統(tǒng)名為Northguard。目前正通過名為Xinfra的虛擬化發(fā)布/訂閱層，積極將其基于Kafka的數(shù)據(jù)遷移到Northguard。

早在2010 年，Jay Kreps 及其在 LinkedIn 的工程師同事Jun Rao和Neha Narkhede開發(fā) Apache Kafka 時，這家社交媒體網(wǎng)站擁有 9000 萬會員。當時，公司每天要將約10億個文件加載到基于Hadoop的數(shù)據(jù)基礎架構中，面臨嚴重的延遲問題。為了克服這一挑戰(zhàn)，Kreps及其公司開發(fā)了Kafka，這種分布式平臺具有容錯、高吞吐量、易于擴展的特點，用于構建實時數(shù)據(jù)管道。

1.干掉親兒子Kafka！

Kafka在LinkedIn內部大受歡迎，因為它在數(shù)據(jù)的創(chuàng)建者（或發(fā)布者）和消費者（或訂閱者）之間提供了一個虛擬化層。它在LinkedIn內部被廣泛使用，并于次年捐贈給了Apache軟件基金會。Kreps、Rao和Narkhede后離開LinkedIn，于2014年共同創(chuàng)立了Confluent，該公司去年的營收接近10億美元。

圖片

多年來，LinkedIn的業(yè)務不斷擴展，Kafka依然是其內部和面向用戶的系統(tǒng)及應用程序的核心組件。然而，LinkedIn內部生成的數(shù)據(jù)量超過了Kafka的服務能力。如今，LinkedIn擁有12億用戶，其發(fā)布/訂閱系統(tǒng)每天需要提取超過32萬億條記錄，總計17 PB，涉及40萬個主題，這些記錄運行在150多個集群上，涉及超過1萬個獨立節(jié)點。

LinkedIn工程師Onur Karaman和Xiongqi Wu表示，這種規(guī)模的數(shù)據(jù)已經(jīng)超出了Kafka 的能力范圍。這兩位工程師今天在LinkedIn工程博客上發(fā)表的一篇文章中寫道：“隨著LinkedIn發(fā)展壯大，我們的用例要求越來越高，擴展和運行Kafka變得越來越困難。因此，我們決定開發(fā)Northguard這種加強可擴展性和可操作性的日志存儲系統(tǒng)，開啟我們新的征程。”

Karaman和Wu表示，Kafka面臨的挑戰(zhàn)主要集中在五個方面。隨著LinkedIn增添更多的用例，數(shù)據(jù)和元數(shù)據(jù)隨之增加，擴展Kafka集群變得越來越困難。由于需要管理150個 Kafka集群，負載均衡也成了一大問題。

數(shù)據(jù)可用性也是一個挑戰(zhàn)，尤其是因為數(shù)據(jù)復制在單個分區(qū)層面處理。一致性也成為一個問題，尤其是當LinkedIn為了可用性而犧牲一致性時（由于前面提到的分區(qū)復制問題）。最后，數(shù)據(jù)的持久性也因保障不力而受到影響。

Karaman和Wu寫道：“我們需要一個不僅在數(shù)據(jù)方面，而且在元數(shù)據(jù)和集群規(guī)模方面都具備良好擴展性的系統(tǒng)，同時支持無人值守操作，支持負載均衡和集群快速部署，無論規(guī)模大小。此外，我們還需要數(shù)據(jù)和元數(shù)據(jù)都具有高度的一致性，以及高吞吐量、低延遲、高可用性、高耐用性、低成本、兼容各類硬件、可插拔性和可測試性?！?nbsp;

圖1. Northguard是LinkedIn的全新發(fā)布/訂閱系統(tǒng)，將取代Kafka。 圖片來源：LinkedIn

2.新系統(tǒng)，究竟長什么樣？

Karaman和Wu提出的解決方案是名為Northguard的日志存儲系統(tǒng)。工程師描述了新系統(tǒng)的核心特性：

為了實現(xiàn)高可擴展性，Northguard對數(shù)據(jù)和元數(shù)據(jù)進行分片，維護最小全局狀態(tài)，并使用一種去中心化的組成員協(xié)議。其可操作性依賴日志條帶化，從而在設計上將負載均勻地分布在集群中。Northguard作為代理集群運行，這些代理僅與連接到它們的客戶端以及集群內的其他代理進行交互。

Northguard數(shù)據(jù)模型基于記錄這個概念，記錄則由鍵、值和用戶定義的標頭組成。Northguard中的記錄序列名為段（segment），它是系統(tǒng)中最小的復制單位。段可以是活動的，在這種情況下段可以被追加；也可以由于副本故障、達到1GB的最大大小限制或段處于活動狀態(tài)超過一小時而被密封。

同樣，范圍（range）是Northguard中受鍵空間約束的段序列。這些段可以是活動的，也可以是密封的。主題是范圍的命名集合，組合后可覆蓋整個鍵空間。主題的范圍可以拆分為兩個范圍，也可以合并成新的子范圍（但前提是它位于唯一的“伙伴范圍”內）。主題可以被密封或刪除。

工程師們寫道，Northguard是一元的，這意味著一個請求生成一個響應。系統(tǒng)將數(shù)據(jù)存儲在“fps 存儲區(qū)”中，使用預寫日志（WAL），并在RocksDB中維護一個“稀疏索引”。

追加操作按批次累積，直到經(jīng)過足夠的時間（比如10 毫秒）、批次超過可配置的大小或批次超過可配置的追加次數(shù)。一旦準備好刷新批次，存儲內容同步寫入到WAL，將記錄追加到一個或多個段文件，fsync（同步）這些文件，并更新索引。 

圖片

圖2. LinkedIn Northguard的兩位開發(fā)者：Onur Karaman（圖左）和Xiongqu Wu

管理員通過為主題分配存儲策略來處理主題，包括為主題賦予名稱、定義段刪除時間的保留期以及一組約束條件。這些約束條件由表達式以及一組綁定到代理的鍵和值（名為屬性）予以定義。

策略和屬性是一種強大的抽象機制。比如說，Northguard本身并不直接理解機架、數(shù)據(jù)中心等。LinkedIn的管理員只是將這些狀態(tài)編碼到部署的代理上的策略和屬性中，從而使策略和屬性成為根據(jù)機架分配副本的通用解決方案。LinkedIn甚至使用策略和屬性來分發(fā)副本，以便無論集群規(guī)模如何，都能在恒定時間內將構建的組件及配置安全地部署到集群。

Northguard 還實現(xiàn)了日志條帶化這個概念，用來避免集群中出現(xiàn)“資源傾斜”的情況。由于Northguard的復制單元級別很低：單個日志，而不是Kafka中的分區(qū)（這本身導致了一系列問題），因此很容易出現(xiàn)資源傾斜，這很難處理。

圖片

圖3. Kafka與Northguard的區(qū)別 圖片來源：LinkedIn

工程師們寫道，Northguard范圍通過采用日志條帶化來避免這些問題，這意味著它將日志分成更小的塊以均衡IO負載。這些塊有自己的副本集，這與日志不同。范圍和段在Northguard中如同日志和塊。由于段的創(chuàng)建相對頻繁，我們無需將現(xiàn)有段移到新的代理上。新代理自然而然開始成為新段的副本。這也意味著，落在代理上的段的意外組合不是問題，因為當新段創(chuàng)建并分配給其他代理時，它會自行解決。集群實現(xiàn)自行均衡。

工程師們還討論了Northguard的元數(shù)據(jù)模型，該模型用于管理主題、范圍和段。發(fā)布/訂閱系統(tǒng)使用“虛擬節(jié)點”（vnode）這個概念來存儲集群元數(shù)據(jù)的分片。虛擬節(jié)點是一個由Raft支持的容錯復制狀態(tài)機，是Northguard分布式元數(shù)據(jù)存儲和管理的核心構建模塊。

元數(shù)據(jù)的業(yè)務邏輯位于協(xié)調器內部，協(xié)調器是特定虛擬節(jié)點的leader（領導者），狀態(tài)在此持久化。工程師們寫道，協(xié)調器跟蹤虛擬節(jié)點所屬主題的變化，比如密封或刪除主題，以及拆分或合并該主題的范圍。它管理元數(shù)據(jù)的方式使Northguard具有自我修復功能。

組裝成哈希環(huán)的虛擬節(jié)點集合名為動態(tài)分片復制狀態(tài)機（DS-RSM）。通過使用哈希算法在虛擬節(jié)點之間對元數(shù)據(jù)進行分片，它可以避免元數(shù)據(jù)熱點。Northguard使用一種名為SWIM的分布式系統(tǒng)協(xié)議，該協(xié)議采用隨機探測以檢測故障，但采用感染式傳播用于成員變更和播報。

3.遷移會遇到的問題，如何解決？

LinkedIn已開始實施Northguard，并取代Kafka作為某些應用系統(tǒng)的發(fā)布/訂閱系統(tǒng)。由于Northguard用C++編寫，而Kafka用Java編寫，因而存在兼容問題。另一個因素是應用系統(tǒng)的業(yè)務關鍵性以及無法接受停運。

為了解決這些問題，LinkedIn開發(fā)了一個名為Xinfra的虛擬化發(fā)布/訂閱層，它可以同時支持Northguard和Kafka。Kafka客戶端只能與單個Kafka集群聯(lián)系，Xinfra卻不受這種限制，允許使用Xinfra的應用系統(tǒng)同時支持Kafka和Northguard。這意味著在運行時主題在集群之間遷移時，用戶無需更改主題。

LinkedIn已經(jīng)將數(shù)千個主題從Kafka遷移到了Northguard，但仍有數(shù)十萬個主題需要遷移過去。對于LinkedIn來說好消息是，目前其超過90%的應用系統(tǒng)都在運行Xinfra客戶端，這應該會使遷移更容易。

工程師們寫道：“展望未來，我們將專注于推動Northguard和Xinfra得到更廣泛的采用，添加一些功能，比如根據(jù)流量增長情況自動擴展主題，并為虛擬化主題操作增強容錯性?！?/p>

參考鏈接：

https://www.bigdatawire.com/2025/06/25/linkedin-introduces-northguard-its-replacement-for-kafka/