Apache Kafka 是 LinkedIn 基礎(chǔ)設(shè)施的核心組件，最初是作為內(nèi)部流式處理平臺而誕生的，后來被開源出來，并得到了外部的廣泛采用。雖然有很多公司和項(xiàng)目在使用 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+手機(jī)+微官網(wǎng)三網(wǎng)同步一站式服務(wù)解決您的所有建站問題。

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

在這篇文章里，作者將介紹 LinkedIn 定制的 Kafka 版本的更多細(xì)節(jié)、補(bǔ)丁的開發(fā)流程、如何將變更傳回上游，并介紹了一些補(bǔ)丁的大概情況和他們?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 代理；

• 用于維護(hù) Avro schema 的 schema 注冊表；

• 用于鏡像集群的 Brooklin

• 用于維護(hù) Apache Kafka 集群的 Cruise Control

• 一個叫作“Bean Counter”的管道審計(jì)和使用情況監(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，只是要維護(hù)一個盡量與上游保持接近的版本。
因此，LinkedIn 通過兩種方式提交補(bǔ)丁。

上游優(yōu)先

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

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

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

• 嘗試提交到上游，但需要注意的是，提交到上游有可能因?yàn)楦鞣N原因不被接受；

• 因?yàn)樘峤恢罂梢粤⒓窗l(fā)布 LinkedIn 版本，所以一般適合緊急補(bǔ)丁。

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

• Apache Kafka 補(bǔ)?。禾峤坏缴嫌蔚难a(bǔ)丁；

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

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

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

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

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

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

補(bǔ)丁示例

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

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

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

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

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

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

直接提交到上游的新特性

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

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

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

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

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

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

之前已經(jīng)介紹了 LinkedIn 的 Kafka 版本分支包含了哪些補(bǔ)丁和特性，接下來將介紹如何創(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）合并到新的分支上。下圖顯示了這一過程：

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

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

創(chuàng)新互聯(lián)www.cdcxhl.cn，專業(yè)提供香港、美國云服務(wù)器，動態(tài)BGP最優(yōu)骨干路由自動選擇，持續(xù)穩(wěn)定高效的網(wǎng)絡(luò)助力業(yè)務(wù)部署。公司持有工信部辦法的idc、isp許可證， 機(jī)房獨(dú)有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)
網(wǎng)站路徑：http://jinyejixie.com/article46/hgghg.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)頁設(shè)計(jì)公司、網(wǎng)站內(nèi)鏈、標(biāo)簽優(yōu)化、ChatGPT、商城網(wǎng)站、微信公眾號

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)