作者 | Alex Woodie

編譯 | 沈建苗

審校 | 云昭

再見 Kafka ！因?yàn)樗挠H爸爸都不堪其痛，親自揮刀要放棄了！

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

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

1.干掉親兒子Kafka！

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

圖片

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

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

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

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

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

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

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

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

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

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

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

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

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

圖片

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

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

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

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

圖片

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

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

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

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

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

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

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

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

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

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

參考鏈接：

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