2024-05-24 115 發(fā)布于浙江

版權(quán)

舉報(bào)

版權(quán)聲明：

本文內(nèi)容由阿里云實(shí)名注冊(cè)用戶自發(fā)貢獻(xiàn)，版權(quán)歸原作者所有，阿里云開發(fā)者社區(qū)不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。具體規(guī)則請(qǐng)查看《 阿里云開發(fā)者社區(qū)用戶服務(wù)協(xié)議》和 《阿里云開發(fā)者社區(qū)知識(shí)產(chǎn)權(quán)保護(hù)指引》。如果您發(fā)現(xiàn)本社區(qū)中有涉嫌抄襲的內(nèi)容，填寫 侵權(quán)投訴表單進(jìn)行舉報(bào)，一經(jīng)查實(shí)，本社區(qū)將立刻刪除涉嫌侵權(quán)內(nèi)容。

簡(jiǎn)介： AutoMQ，新一代云原生 Kafka，解決原 Kafka 的遷移復(fù)制低效、彈性不足和高成本問(wèn)題。本文探討 Kafka 的冷讀（追趕讀）副作用，如硬盤 I/O 爭(zhēng)搶、Page Cache 污染和 Zero Copy 阻塞。Kafka 的冷讀依賴本地存儲(chǔ)，導(dǎo)致性能瓶頸。AutoMQ 通過(guò)對(duì)象存儲(chǔ)實(shí)現(xiàn)冷熱隔離，避免 I/O 爭(zhēng)搶；自主管理內(nèi)存，減少 Page Cache 污染；異步 I/O 響應(yīng)網(wǎng)絡(luò)層，提高效率。此外，AutoMQ 優(yōu)化冷讀性能，確保批處理和故障恢復(fù)時(shí)的高效運(yùn)行。

背景
Apache Kafka （下文簡(jiǎn)稱 Kafka）作為一款成功的流處理平臺(tái)已經(jīng)在各行各業(yè)中有廣泛的應(yīng)用，并且具備極其強(qiáng)大的軟件生態(tài)。但是，其一些缺點(diǎn)也給使用者帶來(lái)了很大的挑戰(zhàn)。AutoMQ 是基于云原生架構(gòu)實(shí)現(xiàn)的新一代 Kafka ，與 Kafka 100% 完全兼容。致力于解決 Kafka 原有的遷移復(fù)制低效、缺乏彈性、成本高昂等缺點(diǎn)，成為新一代云原生 Kafka 解決方案。

為了讓讀者更好地理解 AutoMQ 相比 Kafka 的優(yōu)勢(shì)，我們推出了 《Kafka 痛點(diǎn)專題》 這個(gè)系列，幫助讀者更好地理解當(dāng)前 Kafka 存在的痛點(diǎn)問(wèn)題以及 AutoMQ 是如何解決這些問(wèn)題的。今天主要分享的是 Kafka 中冷讀（也可稱追趕讀，即 Catch-up Read ）副作用的產(chǎn)生原理，以及 AutoMQ 是如何通過(guò)云原生的架構(gòu)設(shè)計(jì)來(lái)避免原 Kafka 冷讀帶來(lái)的副作用的。

冷讀是如何產(chǎn)生的
在消息和流系統(tǒng)中，冷讀是常見且具有重要價(jià)值的場(chǎng)景，包括以下幾點(diǎn)：

保證削峰填谷的效果：消息系統(tǒng)通常用于業(yè)務(wù)解耦和削峰填谷。在削峰填谷場(chǎng)景中，消息隊(duì)列可暫時(shí)保存上游數(shù)據(jù)，以便下游逐步消費(fèi)。這些數(shù)據(jù)通常不在內(nèi)存中，而是需要進(jìn)行冷讀取。因此，優(yōu)化冷讀效率對(duì)于提高削峰填谷的效果至關(guān)重要。 批處理場(chǎng)景廣泛應(yīng)用：在與大數(shù)據(jù)分析場(chǎng)景結(jié)合時(shí)，Kafka 通常用于批處理。在這種情況下，任務(wù)需要從幾個(gè)小時(shí)甚至一天前的數(shù)據(jù)開始掃描計(jì)算。冷讀的效率直接影響了批處理的時(shí)效性。 故障恢復(fù)效率：在實(shí)際生產(chǎn)環(huán)境中，消費(fèi)者由于邏輯問(wèn)題或業(yè)務(wù) BUG 導(dǎo)致故障宕機(jī)是常見問(wèn)題。消費(fèi)者恢復(fù)后，需要快速消費(fèi)堆積的歷史數(shù)據(jù)。提高冷讀效率可以幫助業(yè)務(wù)更快從消費(fèi)者宕機(jī)故障中恢復(fù)，減少中斷時(shí)間。 Kafka 分區(qū)遷移時(shí)數(shù)據(jù)復(fù)制引發(fā)冷讀： Kafka 在擴(kuò)容時(shí)需要遷移分區(qū)數(shù)據(jù)，這時(shí)候也會(huì)引發(fā)冷讀。

冷讀是 Kafka 中實(shí)際應(yīng)用中必然需要面臨的正常需求。對(duì)于 AutoMQ 而言，我們并不會(huì)去嘗試消除冷讀，而是重點(diǎn)在于解決好 Kafka 冷讀本身帶來(lái)的副作用。
冷讀帶來(lái)的副作用
接下來(lái)我們會(huì)分析 Kafka 冷讀具體會(huì)帶來(lái)哪些副作用，以及為什么 Kafka 沒(méi)有辦法解決這些問(wèn)題。
硬盤 I/O 爭(zhēng)搶問(wèn)題
Kafka 運(yùn)維中的一個(gè)重要挑戰(zhàn)是處理冷讀時(shí)對(duì)硬盤 I/O 的大量占用。硬盤或云盤的單盤 IOPS 和吞吐能力有限。冷讀會(huì)導(dǎo)致從硬盤大量讀取數(shù)據(jù)，當(dāng)某些分區(qū)數(shù)據(jù)在節(jié)點(diǎn)上分布不均時(shí)，容易造成熱點(diǎn)訪問(wèn)。對(duì)大量數(shù)據(jù)的分區(qū)進(jìn)行冷讀會(huì)快速占用單盤的 IOPS 和吞吐資源，直接影響節(jié)點(diǎn)上其他 Topic 分區(qū)數(shù)據(jù)的讀寫性能。

Kafka 沒(méi)法解決該副作用的主要原因是其本身存儲(chǔ)實(shí)現(xiàn)強(qiáng)依賴本地存儲(chǔ)。Kafka 的數(shù)據(jù)全部存儲(chǔ)在 Broker 的本地磁盤上，冷讀時(shí)消耗大量磁盤 I/O 導(dǎo)致其他讀寫請(qǐng)求需要訪問(wèn)磁盤時(shí)性能受限。即使像 Kafka 商業(yè)化公司 Confluent 實(shí)現(xiàn)了 KIP-405 所描繪的分層存儲(chǔ)，該問(wèn)題仍然沒(méi)有得到徹底的解決。在 Kafka 分層存儲(chǔ)的實(shí)現(xiàn)中，Kafka 仍然要求分區(qū)的最后一個(gè) LogSegment 必須在本地磁盤上，Broker 和本地存儲(chǔ)仍然是強(qiáng)依賴的。 因此，Kafka 冷讀時(shí)則并不能完全從 S3 或者內(nèi)存從讀取數(shù)據(jù)，其必然有請(qǐng)求需要從分區(qū)的最后一個(gè) LogSegment 中讀取數(shù)據(jù)。當(dāng) LogSegment 的數(shù)據(jù)比較大時(shí)，硬盤 I/O 的爭(zhēng)搶問(wèn)題也將會(huì)更加嚴(yán)重。總的來(lái)說(shuō)，Kafka 采用分層存儲(chǔ)試圖一定程度去降低冷讀副作用的影響，但是并沒(méi)有在根本上解決問(wèn)題。

Page Cache 污染
Kafka 冷讀時(shí)，從磁盤加載大量數(shù)據(jù)經(jīng)過(guò) Page Cache 供消費(fèi)者讀取，會(huì)造成 Page Cache 的數(shù)據(jù)污染。Page Cache 的大小是比較有限的，由于本質(zhì)是個(gè)緩存，當(dāng)新的對(duì)象需要加入 Page Cache 時(shí)，如果其容量不足，就會(huì)驅(qū)逐一些舊的對(duì)象。

Kafka 沒(méi)有做冷熱隔離，當(dāng)冷讀發(fā)生時(shí)，大量冷數(shù)據(jù)的讀取會(huì)迅速搶占 Page Cache 的容量，將其中其他 Topic 的數(shù)據(jù)驅(qū)逐出去。當(dāng)其他 Topic 的消費(fèi)者需要從 Page Cache 讀取數(shù)據(jù)的時(shí)候就會(huì)發(fā)生 Cache Miss，進(jìn)而必須從硬盤中讀取數(shù)據(jù)，此時(shí)讀取的延遲將會(huì)大大增加。在這種情況下，由于從硬盤加載數(shù)據(jù)，整體的吞吐性能也會(huì)快速退化。Kafka 利用 Pache Cache 結(jié)合 sendfile 系統(tǒng)調(diào)用在沒(méi)有發(fā)生冷讀時(shí)有很好的性能表現(xiàn)，但是一旦發(fā)生冷讀，其對(duì)吞吐和讀寫延遲的影響將會(huì)令人非常頭疼。

Kafka 沒(méi)法很好地解決該問(wèn)題主要還是因?yàn)槠渥x寫模型本身設(shè)計(jì)上強(qiáng)依賴 Page Cache 來(lái)兌現(xiàn)其強(qiáng)大的性能和吞吐的。
Zero Copy 在冷讀時(shí)阻塞網(wǎng)絡(luò)請(qǐng)求
Kafka 采用零拷貝技術(shù) sendfile 來(lái)避免內(nèi)核態(tài)和用戶態(tài)交互的開銷來(lái)提升性能一直以來(lái)被大家津津樂(lè)道。但是不可否認(rèn)的是，sendfile 在冷讀時(shí)，會(huì)帶來(lái)額外的副作用。

在 Kafka 的網(wǎng)絡(luò)線程模型中，讀寫請(qǐng)求會(huì)共享一個(gè)網(wǎng)絡(luò)線程池來(lái)處理網(wǎng)絡(luò)請(qǐng)求。在沒(méi)有冷讀的理想場(chǎng)景下，網(wǎng)絡(luò)線程經(jīng)過(guò) Kafka 的處理后，需要向網(wǎng)絡(luò)返回?cái)?shù)據(jù)時(shí)，直接從 Page Cache 加載數(shù)據(jù)返回，整個(gè)請(qǐng)求響應(yīng)在幾微秒內(nèi)可以完成，整個(gè)讀寫流程是非常高效的。

但是如果產(chǎn)生了冷讀，Kafka 網(wǎng)絡(luò)線程向網(wǎng)絡(luò)的內(nèi)核發(fā)送緩沖區(qū)寫數(shù)據(jù)時(shí)，調(diào)用 sendfile 需要先將磁盤加載到 Page Cache 中，然后再寫到網(wǎng)絡(luò)的內(nèi)核發(fā)送緩沖區(qū)。在這個(gè)零拷貝過(guò)程中，Linux 內(nèi)核態(tài)從磁盤加載數(shù)據(jù)到 Page Cache 的過(guò)程中是個(gè)同步的系統(tǒng)調(diào)用，因此網(wǎng)絡(luò)線程只能同步等待其關(guān)聯(lián)的數(shù)據(jù)從磁盤加載數(shù)據(jù)完成，才可以繼續(xù)去處理別的工作。

Kafka 的網(wǎng)絡(luò)線程池是被 Client 的讀寫網(wǎng)絡(luò)請(qǐng)求共享的。冷讀時(shí)，Kafka 網(wǎng)絡(luò)線程池中大量網(wǎng)絡(luò)線程在同步等待系統(tǒng)調(diào)用返回，這會(huì)阻塞新的網(wǎng)絡(luò)請(qǐng)求被處理，同時(shí)也使得消費(fèi)者消費(fèi)的延遲進(jìn)一步增加。下圖演示了冷讀時(shí)，sendfile 是如何影響網(wǎng)絡(luò)線程的處理從而進(jìn)一步拖慢整體的生產(chǎn)和消費(fèi)效率的。

根據(jù)上文的原理分析可知，Kafka 之所以沒(méi)辦法很好的解決這個(gè)問(wèn)題主要還是受限于其線程模型的設(shè)計(jì)。在 Kafka 的讀寫線程模型中，讀寫共享網(wǎng)絡(luò)線程池，冷讀時(shí) sendfile 的慢操作沒(méi)有與讀寫核心流程異步解耦導(dǎo)致了其在冷讀時(shí)網(wǎng)絡(luò)線程成為瓶頸，進(jìn)而造成明顯的吞吐性能下降。

AutoMQ 如何解決冷讀副作用
冷熱隔離
對(duì)象存儲(chǔ)是云上最具規(guī)模化、成本和技術(shù)紅利的云服務(wù)。我們可以看到，像 Confluent， Snowflake 都在基于云對(duì)象存儲(chǔ)重塑自己的軟件服務(wù)來(lái)給用戶提供更低成本、更穩(wěn)定和彈性的存儲(chǔ)能力?；谠茖?duì)象存儲(chǔ)重新設(shè)計(jì)基礎(chǔ)軟件也成為當(dāng)前 Infra 領(lǐng)域軟件設(shè)計(jì)的新風(fēng)尚。 AutoMQ 作為一款真正意義上的云原生軟件，在設(shè)計(jì)之初就確定需要將對(duì)象存儲(chǔ)作為其主存，從而設(shè)計(jì)了流場(chǎng)景中，面向?qū)ο蟠鎯?chǔ)的流存儲(chǔ)庫(kù) S3Stream。該流存儲(chǔ)庫(kù)在 Github 上也已開源，可以搜索 automq-for-kafka 關(guān)注。

AutoMQ 使用對(duì)象存儲(chǔ)作為主存儲(chǔ)，不僅帶來(lái)了極致的成本和彈性優(yōu)勢(shì)，另外一個(gè)非常重要的益處就是有效隔離了冷熱數(shù)據(jù)，從根源上解決了 Kafka 硬盤 I/O 爭(zhēng)搶的問(wèn)題。在 AutoMQ 的讀寫模型中，冷讀時(shí)數(shù)據(jù)會(huì)直接從對(duì)象存儲(chǔ)上加載數(shù)據(jù)，而不是從本地磁盤上讀取數(shù)據(jù)，這樣就天然的隔離了冷讀，自然也就不會(huì)搶占本地磁盤的 I/O 了。

此外，AutoMQ 基于對(duì)象存儲(chǔ)實(shí)現(xiàn)的冷讀隔離是不會(huì)有性能上的副作用的。通過(guò)并發(fā)、預(yù)讀和批量讀取等技術(shù)優(yōu)化措施，在冷讀時(shí)的吞吐性能上可以完全匹敵 Kafka。

自主管理內(nèi)存不依賴 Page Cache
AutoMQ 的讀寫模型中并沒(méi)有依賴 Page Cache，因此也自然不會(huì)有 Kafka Page Cache 污染的副作用。雖然摒棄了使用 Page Cache，但是 AutoMQ 在性能上并沒(méi)有妥協(xié)，主要是因?yàn)椴扇×巳缦乱幌盗械募夹g(shù)手段。
使用 Direct I/O 讀寫裸設(shè)備
AutoMQ 繞過(guò)文件系統(tǒng)，通過(guò) Direct I/O 直接讀寫裸設(shè)備。這帶來(lái)的好處主要是：

避免 Page Cache 污染： 繞過(guò)文件系統(tǒng)自然也就不存在 Page Cache 污染了 減少數(shù)據(jù)復(fù)制：使用 Direct I/O 直接讀取裸設(shè)備，數(shù)據(jù)只有一次復(fù)制，從硬件直接拷貝到應(yīng)用程序的用戶態(tài)。 減少文件系統(tǒng)開銷： 文件系統(tǒng)一般需要寫 Journal，管理 Metadata，在寫入上會(huì)相比實(shí)際寫入消耗更多的帶寬以及 IOPS，寫入路徑也更長(zhǎng)，所以性能上會(huì)比裸設(shè)備差。 更快的容災(zāi)恢復(fù)速度：AutoMQ 的 WAL 數(shù)據(jù)會(huì)保留在云盤上，然后異步刷出到對(duì)象存儲(chǔ)。當(dāng)計(jì)算實(shí)例宕機(jī)時(shí)，云盤會(huì)自動(dòng)漂移掛載到其他可用的機(jī)器上，由 AutoMQ 完成容災(zāi)操作，即將其云盤上剩余的 WAL 刷出到對(duì)象存儲(chǔ)然后再刪除云盤。在這個(gè)容災(zāi)過(guò)程中，由于直接操作的裸設(shè)備，可以避免文件系統(tǒng)恢復(fù)的時(shí)間開銷，提升容災(zāi)的時(shí)效性。 避免 Kafka 數(shù)據(jù)丟失：AutoMQ 需要將數(shù)據(jù)持久化到云盤才返回給客戶端成功響應(yīng)。在 Kafka 的默認(rèn)推薦配置中，為了保證性能一般都是異步持久化數(shù)據(jù)的。當(dāng)機(jī)房斷電這種場(chǎng)景時(shí)，文件系統(tǒng)殘留臟頁(yè)會(huì)丟失導(dǎo)致數(shù)據(jù)丟失。
自主管理堆外內(nèi)存
利用文件系統(tǒng)的 Page Cache 提升性能是一種比較取巧的方式。對(duì)于 Kafka 而言，意味著其無(wú)需自身實(shí)現(xiàn)一套內(nèi)存 Cache，也不用擔(dān)心其 JVM 的對(duì)象開銷和 GC 問(wèn)題。不得不說(shuō)，在非冷讀場(chǎng)景下，這種方式確實(shí)是有著不錯(cuò)的表現(xiàn)。但是一旦出現(xiàn)冷讀，Kafka 用戶態(tài)對(duì) Page Cache 的默認(rèn)行為干預(yù)能力就很有限，沒(méi)法做一些精細(xì)化的管理。因此，像 Kafka 冷讀時(shí) Page Cache 的污染就很難處理。

AutoMQ 在設(shè)計(jì)之初就是充分考慮到了使用 Page Cache 的利弊，在自研的 S3Strean 流存儲(chǔ)庫(kù)中，實(shí)現(xiàn)了 JVM 堆外內(nèi)存的高效自主管理。通過(guò)設(shè)計(jì)冷熱隔離的緩存 BlockCache 和 LogCache，可以保證在各種場(chǎng)景下均可以完成高效的內(nèi)存讀寫。在未來(lái)的迭代中，AutoMQ 也可以根據(jù)流場(chǎng)景對(duì)內(nèi)存讀寫進(jìn)行更加精細(xì)化地管理和優(yōu)化。
異步 I/O 響應(yīng)網(wǎng)絡(luò)層
Kafka 的線程模型本質(zhì)上是圍繞 Page Cache 和零拷貝技術(shù)來(lái)設(shè)計(jì)的。前文也指出了其核心問(wèn)題是在冷讀時(shí)，網(wǎng)絡(luò)線程同步等待磁盤讀取，導(dǎo)致整個(gè)讀寫流程受阻，影響了性能。

AutoMQ 沒(méi)有出現(xiàn)的問(wèn)題也是得益于其自主實(shí)現(xiàn)的內(nèi)存管理機(jī)制。由于沒(méi)有依賴 Page Cache，AutoMQ 存儲(chǔ)層實(shí)現(xiàn)時(shí)會(huì)異步加載完數(shù)據(jù)再響應(yīng)到網(wǎng)絡(luò)層，因此讀寫請(qǐng)求不會(huì)同步等待 磁盤I/O 完成才去處理別的工作。這使得整體的讀寫處理變得更加高效。

冷讀的性能
冷讀是 Kafka 中的常見應(yīng)用場(chǎng)景，AutoMQ 在處理 Kafka 冷讀副作用時(shí)，不僅做到了冷熱隔離，同時(shí)也考慮到了確保冷讀性能不受影響的重要性。

AutoMQ 通過(guò)以下幾種技術(shù)手段保證了冷讀時(shí)的性能：

對(duì)象存儲(chǔ)讀取性能優(yōu)化：通過(guò)預(yù)讀、并發(fā)和緩存等手段直接從對(duì)象存儲(chǔ)讀取數(shù)據(jù)，保證了整體上優(yōu)異的吞吐性能。 云原生的存儲(chǔ)層實(shí)現(xiàn)，減少網(wǎng)絡(luò)開銷：AutoMQ 利用了云盤底層的多副本機(jī)制保證了數(shù)據(jù)的可靠性，因此在 Broker 層面可以減少副本復(fù)制的網(wǎng)絡(luò)延遲開銷。從而相比 Kafka 有更好的延遲、總體吞吐表現(xiàn)。

相關(guān)知識(shí)

如何徹底解決化療藥物的副作用 三種辦法來(lái)解決
Java技能提升：破解“技能冷卻”，高效學(xué)習(xí)攻略揭秘
藥物的副作用要怎么解決
如何緩解藥物副作用
如何減輕化療副作用
決明子的副作用 決明子的食用方法
擺地?cái)側(cè)绾谓鉀Q冰塊冷藏問(wèn)題
藥物副作用肚子疼怎么解決
決明子泡茶喝有副作用嗎？
如何快速解除藥物副作用

網(wǎng)址: 如何解決 Kafka 冷讀副作用 http://www.u1s5d6.cn/newsview846481.html