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

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

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

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

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

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

• Kafka 集群；

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

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

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

• 用于鏡像集群的 Brooklin

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

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

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

上游優(yōu)先

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

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

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

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

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

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

• Apache Kafka 補(bǔ)丁：提交到上游的補(bǔ)丁；

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

• 緊急修復(fù)補(bǔ)丁：先是在內(nèi)部創(chuàng)建，然后提交到上游；

• LinkedIn 獨(dú)有的補(bǔ)丁：不被上游接受的緊急修復(fù)補(bǔ)丁，它們可能只在 LinkedIn 內(nèi)部使用，或者嘗試提交到上游但被開(kāi)源社區(qū)拒絕。

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

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

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

補(bǔ)丁示例

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

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

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

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

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

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

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

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

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

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

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

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

文章名稱：LinkedIn定制Kafka，互聯(lián)網(wǎng)大廠是如何每天處理7萬(wàn)億條消息-創(chuàng)新互聯(lián)
網(wǎng)站路徑：http://chinadenli.net/article46/hgghg.html

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

廣告

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