Apache Kafka 是 LinkedIn 基礎(chǔ)設(shè)施的核心組件，最初是作為內(nèi)部流式處理平臺而誕生的，后來被開源出來，并得到了外部的廣泛采用。雖然有很多公司和項目在使用 Kafka，但他們的數(shù)據(jù)規(guī)模很少能夠達(dá)到 LinkedIn 這樣。Kafka 被廣泛地應(yīng)用在 LinkedIn 的軟件棧中，用于活動追蹤、消息交換、指標(biāo)收集，等等。LinkedIn 有 100 多個 Kafka 集群，其中包含了 4000 多個 broker，總共有 10 萬多個 topic 和 700 萬個分區(qū)。截止到目前，LinkedIn 的 Kafka 集群每天處理的消息數(shù)量超過了 7 萬億條。

創(chuàng)新互聯(lián)于2013年開始，先為鄆城等服務(wù)建站，鄆城等地企業(yè)，進(jìn)行企業(yè)商務(wù)咨詢服務(wù)。為鄆城企業(yè)網(wǎng)站制作PC+手機+微官網(wǎng)三網(wǎng)同步一站式服務(wù)解決您的所有建站問題。

如此大規(guī)模的處理容量不斷給 LinkedIn 的 Kafka 生態(tài)系統(tǒng)帶來伸縮性和運維方面的挑戰(zhàn)。為了解決這方面的問題，LinkedIn 定制了一個 Kafka 版本。現(xiàn)在，這個分支也正式開源，并托管在 GitHub 上。這個分支的版本號與 Apache Kafka 的區(qū)別是后面加了 -li 后綴。

在這篇文章里，作者將介紹 LinkedIn 定制的 Kafka 版本的更多細(xì)節(jié)、補丁的開發(fā)流程、如何將變更傳回上游，并介紹了一些補丁的大概情況和他們?nèi)绾伟l(fā)布新版本。

LinkedIn 的 Kafka 生態(tài)系統(tǒng)

基于 Apache Kafka 的流式處理生態(tài)系統(tǒng)是 LinkedIn 技術(shù)棧的一個關(guān)鍵組成部分。這個生態(tài)系統(tǒng)包含以下這些組件：

• Kafka 集群；

• 使用了 Kafka 客戶端的應(yīng)用程序；

• 為非 Java 客戶端提供服務(wù)的 REST 代理；

• 用于維護 Avro schema 的 schema 注冊表；

• 用于鏡像集群的 Brooklin

• 用于維護 Apache Kafka 集群的 Cruise Control

• 一個叫作“Bean Counter”的管道審計和使用情況監(jiān)控器。

LinkedIn 的 Kafka 版本分支
正如之前所述，LinkedIn 內(nèi)部的版本分支用于創(chuàng)建被部署在 LinkedIn 生產(chǎn)環(huán)境的 Kafka 版本。每一個版本分支都是從對應(yīng)的 Apache Kafka 上游分支拉取出來的。畢竟，LinkedIn 并不是要對 Apache Kafka 進(jìn)行 fork，只是要維護一個盡量與上游保持接近的版本。
因此，LinkedIn 通過兩種方式提交補丁。

上游優(yōu)先

• 先把補丁提交到上游，如果有必要會創(chuàng)建一個 KIP（Kafka Improvement Proposal）；
• 把補丁加入到當(dāng)前的 LinkedIn 版本分支，或者在創(chuàng)建一個新分支時加入（在提交到上游之后）；
• 因為先提交到上游再加入 LinkedIn 版本分支會讓發(fā)布時間變得更長，所以一般適合低優(yōu)先級或中等優(yōu)先級的版本。

LinkedIn 優(yōu)先（也就是緊急修復(fù)）

• 先提交到 LinkedIn 的版本分支；

• 嘗試提交到上游，但需要注意的是，提交到上游有可能因為各種原因不被接受；

• 因為提交之后可以立即發(fā)布 LinkedIn 版本，所以一般適合緊急補丁。

除了自己創(chuàng)建的補丁，有時候 LinkedIn 也需要從上游擇優(yōu)挑選一些補丁。因此，LinkedIn 的版本分支包含了以下幾種補?。?/p>

• Apache Kafka 補丁：提交到上游的補??；

• 擇優(yōu)挑選的補丁：提交到上游之后再加入當(dāng)前發(fā)布版本，它們可能是內(nèi)部提交到上游的，也可能是來自外部的補?。?/p>

• 緊急修復(fù)補?。合仁窃趦?nèi)部創(chuàng)建，然后提交到上游；

• LinkedIn 獨有的補?。翰槐簧嫌谓邮艿木o急修復(fù)補丁，它們可能只在 LinkedIn 內(nèi)部使用，或者嘗試提交到上游但被開源社區(qū)拒絕。

換句話說，在過了分支點之后，每個 LinkedIn 的發(fā)布版本都會有兩種補丁：優(yōu)選補丁和緊急修復(fù)補丁。緊急修復(fù)補丁又包含只在 LinkedIn 內(nèi)部使用和嘗試提交到上游的補丁。從下圖可以看出，盡管每一個提交補丁都會創(chuàng)建一個內(nèi)部版本，但發(fā)布版本是按需創(chuàng)建的，而且可能包含多個補丁。

開發(fā)流程
LinkedIn 的 Kafka 補丁開發(fā)流程如下圖所示。

這里最關(guān)鍵的地方在于是選擇“上游優(yōu)先”還是“LinkedIn 優(yōu)先”（也就是圖中的“Commit to upstream first?”）。補丁開發(fā)者應(yīng)該根據(jù)緊急程度慎重地做出決定。通常，用于解決生產(chǎn)環(huán)境問題的補丁先是作為緊急修復(fù)補丁，除非可以被快速提交到上游（比如在一周內(nèi)）。有 KIP 的功能補丁應(yīng)該先提交到上游。

補丁示例

下面將給出一些有代表性的補丁示例，有些已經(jīng)提交到上游，有些只在 LinkedIn 內(nèi)部使用。

伸縮性方面的改進(jìn)

LinkedIn 內(nèi)部有一些大集群，單個集群可能包含 140 多 broker 和 1 百萬個副本。因為集群規(guī)模太大，導(dǎo)致控制器速度變慢，或者因為內(nèi)存壓力導(dǎo)致控制器發(fā)生故障。這些問題對生產(chǎn)環(huán)境造成了嚴(yán)重影響，還可能導(dǎo)致控制器級聯(lián)故障。LinkedIn 提供了一些緊急補丁來解決這些問題，例如，使用 UpdateMetadataRequest 對象減少控制器的內(nèi)存使用，并避免打印過多的日志。

因為單個集群包含的 broker 數(shù)量比較多，單個 broker 啟動和關(guān)閉時間變慢也會導(dǎo)致整個集群的部署延遲嚴(yán)重增加。因此，為了保證 Kafka 集群的可用性，在部署時每次只能關(guān)掉一個 broker。為了解決這個部署問題，LinkedIn 提供了一些補丁，用于減少 broker 的啟動和關(guān)閉時間（例如，通過減少鎖競爭來縮短關(guān)閉時間）。

運維方面的改進(jìn)

這些補丁主要用來解決 Kafka 的部署問題。例如，SRE 經(jīng)常需要移除發(fā)生故障的 broker（例如，有些 broker 磁盤壞掉了），并向集群中加入新的 broker。在移除 broker 時需要保持同樣水準(zhǔn)的數(shù)據(jù)冗余，以便確保數(shù)據(jù)不會丟失。SRE 需要先將副本從發(fā)生故障的 broker 中移出，但這樣做其實是很困難的，因為集群一直在創(chuàng)建新的 topic，新的副本有可能會被分配給發(fā)生故障的 broker。為了解決這個問題，LinkedIn 引入了維護模式。一個 broker 在進(jìn)入維護模式后就不會被分配新的 topic 分區(qū)或副本。有了這個特性，就可以很容易地將一個 broker 的所有副本遷移給另一個 broker，然后把發(fā)生故障的 broker 完全關(guān)閉掉。

直接提交到上游的新特性

最近提交到上游的新特性包括 KIP-219、KIP-380、KIP-291 和 KIP-354。

還有一些在原先的 Apache Kafka 中不存在的新特性：

• 支持生產(chǎn)和消費計數(shù)，用于計費。

• 在創(chuàng)建 topic 時強制要求設(shè)定最小的副本系數(shù)，避免因為 broker 發(fā)生故障而丟失數(shù)據(jù)。

• 新的偏移量重置策略，可以將消費者的消費偏移量設(shè)置到最近的一個偏移量。

創(chuàng)建新的版本分支

之前已經(jīng)介紹了 LinkedIn 的 Kafka 版本分支包含了哪些補丁和特性，接下來將介紹如何創(chuàng)建新的版本分支。首先是從 Apache Kafka 版本分支創(chuàng)建新的分支（例如，從 Apache Kafka 的 2.3.0 分支創(chuàng)建 LinkedIn Kafka 的 2.3.0.x 分支），然后將還未提交到上游的緊急修復(fù)從之前的 LinkedIn 版本分支（例如 2.0.0.x）合并到新的分支上。下圖顯示了這一過程：

在這個過程中會在提交注釋里指明一個緊急補丁是否需要被合并到新的分支上。例如，提交注釋里可能會包含 Apache Kafka 的 ticket 號，通過這個 ticket 號就可以知道這個補丁是否已經(jīng)被合并到 Apache Kafka 的分支上了。另外，Apache Kafka 分支上的補丁也會被定期擇優(yōu)合并到當(dāng)前的 LinkedIn Kafka 分支上。

最后，新的版本分支會有一個驗證過程。LinkedIn 使用了一個專門的驗證框架，基于真實的生產(chǎn)流量針對新的版本進(jìn)行各種測試。驗證的項目包括再均衡、部署、回退、穩(wěn)定性和降級。在通過驗證之后，就可以發(fā)布新版本了。簡單地說，LinkedIn 的每一個 Kafka 版本都會經(jīng)過大規(guī)模的性能和正確性測試和驗證。

創(chuàng)新互聯(lián)www.cdcxhl.cn，專業(yè)提供香港、美國云服務(wù)器，動態(tài)BGP最優(yōu)骨干路由自動選擇，持續(xù)穩(wěn)定高效的網(wǎng)絡(luò)助力業(yè)務(wù)部署。公司持有工信部辦法的idc、isp許可證， 機房獨有T級流量清洗系統(tǒng)配攻擊溯源，準(zhǔn)確進(jìn)行流量調(diào)度，確保服務(wù)器高可用性。佳節(jié)活動現(xiàn)已開啟，新人活動云服務(wù)器買多久送多久。

文章名稱：LinkedIn定制Kafka，互聯(lián)網(wǎng)大廠是如何每天處理7萬億條消息-創(chuàng)新互聯(lián)
本文鏈接：http://weahome.cn/article/hgghg.html