Kafka的相關(guān)知識(shí)點(diǎn)有哪些

這篇文章主要介紹“Kafka的相關(guān)知識(shí)點(diǎn)有哪些”，在日常操作中，相信很多人在Kafka的相關(guān)知識(shí)點(diǎn)有哪些問(wèn)題上存在疑惑，小編查閱了各式資料，整理出簡(jiǎn)單好用的操作方法，希望對(duì)大家解答”Kafka的相關(guān)知識(shí)點(diǎn)有哪些”的疑惑有所幫助！接下來(lái)，請(qǐng)跟著小編一起來(lái)學(xué)習(xí)吧！

講一講分布式消息中間件

面試問(wèn)題：

• 什么是分布式消息中間件?

• 消息中間件的作用是什么?

• 消息中間件的使用場(chǎng)景是什么?

• 消息中間件選型?

消息隊(duì)列

分布式消息是一種通信機(jī)制，和 RPC、HTTP、RMI 等不一樣，消息中間件采用分布式中間代理的方式進(jìn)行通信。

如圖所示，采用了消息中間件之后，上游業(yè)務(wù)系統(tǒng)發(fā)送消息，先存儲(chǔ)在消息中間件，然后由消息中間件將消息分發(fā)到對(duì)應(yīng)的業(yè)務(wù)模塊應(yīng)用(分布式生產(chǎn)者 -  消費(fèi)者模式)。

這種異步的方式，減少了服務(wù)之間的耦合程度。

架構(gòu)

定義消息中間件：

• 利用高效可靠的消息傳遞機(jī)制進(jìn)行平臺(tái)無(wú)關(guān)的數(shù)據(jù)交流。

• 基于數(shù)據(jù)通信，來(lái)進(jìn)行分布式系統(tǒng)的集成。

• 通過(guò)提供消息傳遞和消息排隊(duì)模型，可以在分布式環(huán)境下擴(kuò)展進(jìn)程間的通信。

在系統(tǒng)架構(gòu)中引用額外的組件，必然提高系統(tǒng)的架構(gòu)復(fù)雜度和運(yùn)維的難度，那么在系統(tǒng)中使用分布式消息中間件有什么優(yōu)勢(shì)呢?

消息中間件在系統(tǒng)中起的作用又是什么呢?

• 解耦

• 冗余(存儲(chǔ))

• 擴(kuò)展性

• 削峰

• 可恢復(fù)性

• 順序保證

• 緩沖

• 異步通信

面試時(shí)，面試官經(jīng)常會(huì)關(guān)心面試者對(duì)開(kāi)源組件的選型能力，這既可以考驗(yàn)面試者知識(shí)的廣度，也可以考驗(yàn)面試者對(duì)某類系統(tǒng)的知識(shí)的認(rèn)識(shí)深度，而且也可以看出面試者對(duì)系統(tǒng)整體把握和系統(tǒng)架構(gòu)設(shè)計(jì)的能力。

開(kāi)源分布式消息系統(tǒng)有很多，不同的消息系統(tǒng)的特性也不一樣，選擇怎樣的消息系統(tǒng)，不僅需要對(duì)各消息系統(tǒng)有一定的了解，也需要對(duì)自身系統(tǒng)需求有清晰的認(rèn)識(shí)。

下面是常見(jiàn)的幾種分布式消息系統(tǒng)的對(duì)比：

消息隊(duì)列選擇

答案關(guān)鍵字：

• 什么是分布式消息中間件?通信，隊(duì)列，分布式，生產(chǎn)消費(fèi)者模式。

• 消息中間件的作用是什么?解耦、峰值處理、異步通信、緩沖。

• 消息中間件的使用場(chǎng)景是什么?異步通信，消息存儲(chǔ)處理。

• 消息中間件選型?語(yǔ)言，協(xié)議、HA、數(shù)據(jù)可靠性、性能、事務(wù)、生態(tài)、簡(jiǎn)易、推拉模式。

Kafka 基本概念和架構(gòu)

面試問(wèn)題：

• 簡(jiǎn)單講下 Kafka 的架構(gòu)?

• Kafka 是推模式還是拉模式，推拉的區(qū)別是什么?

• Kafka 如何廣播消息?

• Kafka 的消息是否是有序的?

• Kafka 是否支持讀寫(xiě)分離?

• Kafka 如何保證數(shù)據(jù)高可用?

• Kafka 中 Zookeeper 的作用?

• 是否支持事務(wù)?

• 分區(qū)數(shù)是否可以減少?

架構(gòu)圖

Kafka 架構(gòu)中的一般概念：

• Producer：生產(chǎn)者，也就是發(fā)送消息的一方。生產(chǎn)者負(fù)責(zé)創(chuàng)建消息，然后將其發(fā)送到 Kafka。

• Consumer：消費(fèi)者，也就是接受消息的一方。消費(fèi)者連接到 Kafka 上并接收消息，進(jìn)而進(jìn)行相應(yīng)的業(yè)務(wù)邏輯處理。

• Consumer Group：一個(gè)消費(fèi)者組可以包含一個(gè)或多個(gè)消費(fèi)者。使用多分區(qū)+多消費(fèi)者方式可以極大提高數(shù)據(jù)下游的處理速度。

同一消費(fèi)組中的消費(fèi)者不會(huì)重復(fù)消費(fèi)消息，同樣的，不同消費(fèi)組中的消費(fèi)者消息消息時(shí)互不影響。Kafka 就是通過(guò)消費(fèi)組的方式來(lái)實(shí)現(xiàn)消息 P2P  模式和廣播模式。

• Broker：服務(wù)代理節(jié)點(diǎn)。Broker 是 Kafka 的服務(wù)節(jié)點(diǎn)，即 Kafka 的服務(wù)器。

• Topic：Kafka 中的消息以 Topic 為單位進(jìn)行劃分，生產(chǎn)者將消息發(fā)送到特定的 Topic，而消費(fèi)者負(fù)責(zé)訂閱 Topic  的消息并進(jìn)行消費(fèi)。

• Partition：Topic 是一個(gè)邏輯的概念，它可以細(xì)分為多個(gè)分區(qū)，每個(gè)分區(qū)只屬于單個(gè)主題。

同一個(gè)主題下不同分區(qū)包含的消息是不同的，分區(qū)在存儲(chǔ)層面可以看作一個(gè)可追加的日志(Log)文件，消息在被追加到分區(qū)日志文件的時(shí)候都會(huì)分配一個(gè)特定的偏移量(Offset)。

• Offset：Offset 是消息在分區(qū)中的唯一標(biāo)識(shí)，Kafka 通過(guò)它來(lái)保證消息在分區(qū)內(nèi)的順序性，不過(guò) Offset 并不跨越分區(qū)，也就是說(shuō)，Kafka  保證的是分區(qū)有序性而不是主題有序性。

• Replication：副本，是 Kafka 保證數(shù)據(jù)高可用的方式，Kafka 同一 Partition 的數(shù)據(jù)可以在多 Broker  上存在多個(gè)副本，通常只有主副本對(duì)外提供讀寫(xiě)服務(wù)，當(dāng)主副本所在 Broker 崩潰或發(fā)生網(wǎng)絡(luò)一場(chǎng)，Kafka 會(huì)在 Controller 的管理下會(huì)重新選擇新的  Leader 副本對(duì)外提供讀寫(xiě)服務(wù)。

• Record：實(shí)際寫(xiě)入 Kafka 中并可以被讀取的消息記錄。每個(gè) Record 包含了 key、value 和 timestamp。

Kafka Topic Partitions Layout，如下圖：

主題

Kafka 將 Topic 進(jìn)行分區(qū)，分區(qū)可以并發(fā)讀寫(xiě)。

Kafka Consumer Offset，如下圖：

Consumer Offset

Zookeeper 架構(gòu)如下圖：

• Broker 注冊(cè)：Broker 是分布式部署并且之間相互獨(dú)立，Zookeeper 用來(lái)管理注冊(cè)到集群的所有 Broker 節(jié)點(diǎn)。

• Topic 注冊(cè)：在 Kafka 中，同一個(gè) Topic 的消息會(huì)被分成多個(gè)分區(qū)并將其分布在多個(gè) Broker 上，這些分區(qū)信息及與 Broker  的對(duì)應(yīng)關(guān)系也都是由 Zookeeper 在維護(hù)

• 生產(chǎn)者負(fù)載均衡：由于同一個(gè) Topic 消息會(huì)被分區(qū)并將其分布在多個(gè) Broker 上，因此，生產(chǎn)者需要將消息合理地發(fā)送到這些分布式的 Broker  上。

• 消費(fèi)者負(fù)載均衡：與生產(chǎn)者類似，Kafka 中的消費(fèi)者同樣需要進(jìn)行負(fù)載均衡來(lái)實(shí)現(xiàn)多個(gè)消費(fèi)者合理地從對(duì)應(yīng)的 Broker  服務(wù)器上接收消息，每個(gè)消費(fèi)者分組包含若干消費(fèi)者，每條消息都只會(huì)發(fā)送給分組中的一個(gè)消費(fèi)者，不同的消費(fèi)者分組消費(fèi)自己特定的 Topic  下面的消息，互不干擾。

答案關(guān)鍵字：

• 簡(jiǎn)單講下 Kafka 的架構(gòu)?Producer、Consumer、Consumer Group、Topic、Partition。

• Kafka 是推模式還是拉模式，推拉的區(qū)別是什么?Kafka Producer 向 Broker 發(fā)送消息使用 Push 模式，Consumer  消費(fèi)采用的 Pull 模式。拉取模式，讓 consumer 自己管理 offset，可以提供讀取性能。

• Kafka 如何廣播消息?Consumer group。

• Kafka 的消息是否是有序的?Topic 級(jí)別無(wú)序，Partition 有序。

• Kafka 是否支持讀寫(xiě)分離?不支持，只有 Leader 對(duì)外提供讀寫(xiě)服務(wù)。

• Kafka 如何保證數(shù)據(jù)高可用?副本，Ack，HW。

• Kafka 中 zookeeper 的作用?集群管理，元數(shù)據(jù)管理。

• 是否支持事務(wù)?0.11 后支持事務(wù)，可以實(shí)現(xiàn)“exactly once”。

• 分區(qū)數(shù)是否可以減少?不可以，會(huì)丟失數(shù)據(jù)。

Kafka 使用

面試問(wèn)題：

• Kafka 有哪些命令行工具?你用過(guò)哪些?

• Kafka Producer 的執(zhí)行過(guò)程?

• Kafka Producer 有哪些常見(jiàn)配置?

• 如何讓 Kafka 的消息有序?

• Producer 如何保證數(shù)據(jù)發(fā)送不丟失?

• 如何提升 Producer 的性能?

• 如果同一 Group 下 Consumer 的數(shù)量大于 part 的數(shù)量，kafka 如何處理?

• Kafka Consumer 是否是線程安全的?

• 講一下你使用 Kafka Consumer 消費(fèi)消息時(shí)的線程模型，為何如此設(shè)計(jì)?

• Kafka Consumer 的常見(jiàn)配置?

• Consumer 什么時(shí)候會(huì)被踢出集群?

• 當(dāng)有 Consumer 加入或退出時(shí)，Kafka 會(huì)作何反應(yīng)?

• 什么是 Rebalance，何時(shí)會(huì)發(fā)生 Rebalance?

命令行工具

Kafka 的命令行工具在 Kafka 包的 /bin 目錄下，主要包括服務(wù)和集群管理腳本，配置腳本，信息查看腳本，Topic  腳本，客戶端腳本等。

• kafka-configs.sh：配置管理腳本。

• kafka-console-consumer.sh：kafka 消費(fèi)者控制臺(tái)。

• kafka-console-producer.sh：kafka 生產(chǎn)者控制臺(tái)。

• kafka-consumer-groups.sh：kafka 消費(fèi)者組相關(guān)信息。

• kafka-delete-records.sh：刪除低水位的日志文件。

• kafka-log-dirs.sh：kafka 消息日志目錄信息。

• kafka-mirror-maker.sh：不同數(shù)據(jù)中心 kafka 集群復(fù)制工具。

• kafka-preferred-replica-election.sh：觸發(fā) preferred replica 選舉。

• kafka-producer-perf-test.sh：kafka 生產(chǎn)者性能測(cè)試腳本。

• kafka-reassign-partitions.sh：分區(qū)重分配腳本。

• kafka-replica-verification.sh：復(fù)制進(jìn)度驗(yàn)證腳本。

• kafka-server-start.sh：?jiǎn)?dòng) kafka 服務(wù)。

• kafka-server-stop.sh：停止 kafka 服務(wù)。

• kafka-topics.sh：topic 管理腳本。

• kafka-verifiable-consumer.sh：可檢驗(yàn)的 kafka 消費(fèi)者。

• kafka-verifiable-producer.sh：可檢驗(yàn)的 kafka 生產(chǎn)者。

• zookeeper-server-start.sh：?jiǎn)?dòng) zk 服務(wù)。

• zookeeper-server-stop.sh：停止 zk 服務(wù)。

• zookeeper-shell.sh：zk 客戶端。

我們通?？梢允褂胟afka-console-consumer.sh和kafka-console-producer.sh腳本來(lái)測(cè)試 Kafka  生產(chǎn)和消費(fèi)。

kafka-consumer-groups.sh 可以查看和管理集群中的 Topic，kafka-topics.sh 通常用于查看 Kafka  的消費(fèi)組情況。

Kafka Producer

Kafka producer 的正常生產(chǎn)邏輯包含以下幾個(gè)步驟：

• 配置生產(chǎn)者客戶端參數(shù)常見(jiàn)生產(chǎn)者實(shí)例。

• 構(gòu)建待發(fā)送的消息。

• 發(fā)送消息。

• 關(guān)閉生產(chǎn)者實(shí)例。

Producer 發(fā)送消息的過(guò)程如下圖所示，需要經(jīng)過(guò)攔截器，序列化器和分區(qū)器，最終由累加器批量發(fā)送至 Broker。

Producer

Kafka Producer 需要以下必要參數(shù)：

• bootstrap.server：指定 Kafka 的 Broker 的地址。

• key.serializer：key 序列化器。

• value.serializer：value 序列化器。

常見(jiàn)參數(shù)：

• batch.num.messages，默認(rèn)值：200，每次批量消息的數(shù)量，只對(duì) asyc 起作用。

• request.required.acks，默認(rèn)值：0，0 表示 producer 毋須等待 leader 的確認(rèn)，1 代表需要 leader  確認(rèn)寫(xiě)入它的本地 log 并立即確認(rèn)，-1 代表所有的備份都完成后確認(rèn)。

只對(duì) async 模式起作用，這個(gè)參數(shù)的調(diào)整是數(shù)據(jù)不丟失和發(fā)送效率的 tradeoff，如果對(duì)數(shù)據(jù)丟失不敏感而在乎效率的場(chǎng)景可以考慮設(shè)置為  0，這樣可以大大提高 producer 發(fā)送數(shù)據(jù)的效率。

• request.timeout.ms，默認(rèn)值：10000，確認(rèn)超時(shí)時(shí)間。

• partitioner.class，默認(rèn)值：kafka.producer.DefaultPartitioner，必須實(shí)現(xiàn)  kafka.producer.Partitioner，根據(jù) Key 提供一個(gè)分區(qū)策略。

有時(shí)候我們需要相同類型的消息必須順序處理，這樣我們就必須自定義分配策略，從而將相同類型的數(shù)據(jù)分配到同一個(gè)分區(qū)中。

• producer.type，默認(rèn)值：sync，指定消息發(fā)送是同步還是異步。異步 asyc 成批發(fā)送用  kafka.producer.AyncProducer， 同步 sync 用  kafka.producer.SyncProducer。同步和異步發(fā)送也會(huì)影響消息生產(chǎn)的效率。

• compression.topic，默認(rèn)值：none，消息壓縮，默認(rèn)不壓縮。其余壓縮方式還有，"gzip"、"snappy"和"lz4"。對(duì)消息的壓縮可以極大地減少網(wǎng)絡(luò)傳輸量、降低網(wǎng)絡(luò)  IO，從而提高整體性能。

• compressed.topics，默認(rèn)值：null，在設(shè)置了壓縮的情況下，可以指定特定的 topic 壓縮，未指定則全部壓縮。

• message.send.max.retries，默認(rèn)值：3，消息發(fā)送最大嘗試次數(shù)。

• retry.backoff.ms，默認(rèn)值：300，每次嘗試增加的額外的間隔時(shí)間。

• topic.metadata.refresh.interval.ms，默認(rèn)值：600000，定期的獲取元數(shù)據(jù)的時(shí)間。

當(dāng)分區(qū)丟失，leader 不可用時(shí) producer 也會(huì)主動(dòng)獲取元數(shù)據(jù)，如果為  0，則每次發(fā)送完消息就獲取元數(shù)據(jù)，不推薦。如果為負(fù)值，則只有在失敗的情況下獲取元數(shù)據(jù)。

• queue.buffering.max.ms，默認(rèn)值：5000，在 producer queue 的緩存的數(shù)據(jù)最大時(shí)間，僅僅 for asyc。

• queue.buffering.max.message，默認(rèn)值：10000，producer 緩存的消息的最大數(shù)量，僅僅 for asyc。

• queue.enqueue.timeout.ms，默認(rèn)值：-1，0 當(dāng) queue 滿時(shí)丟掉，負(fù)值是 queue 滿時(shí) block, 正值是 queue  滿時(shí) block 相應(yīng)的時(shí)間，僅僅 for asyc。

Kafka Consumer

Kafka  有消費(fèi)組的概念，每個(gè)消費(fèi)者只能消費(fèi)所分配到的分區(qū)的消息，每一個(gè)分區(qū)只能被一個(gè)消費(fèi)組中的一個(gè)消費(fèi)者所消費(fèi)，所以同一個(gè)消費(fèi)組中消費(fèi)者的數(shù)量如果超過(guò)了分區(qū)的數(shù)量，將會(huì)出現(xiàn)有些消費(fèi)者分配不到消費(fèi)的分區(qū)。

消費(fèi)組與消費(fèi)者關(guān)系如下圖所示：

Consumer Group

Kafka Consumer Client 消費(fèi)消息通常包含以下步驟：

• 配置客戶端，創(chuàng)建消費(fèi)者

• 訂閱主題

• 拉去消息并消費(fèi)

• 提交消費(fèi)位移

• 關(guān)閉消費(fèi)者實(shí)例

過(guò)程

因?yàn)?Kafka 的 Consumer 客戶端是線程不安全的，為了保證線程安全，并提升消費(fèi)性能，可以在 Consumer 端采用類似 Reactor  的線程模型來(lái)消費(fèi)數(shù)據(jù)。

消費(fèi)模型

Kafka Consumer 參數(shù)：

• bootstrap.servers：連接 broker 地址，host：port 格式。

• group.id：消費(fèi)者隸屬的消費(fèi)組。

• key.deserializer：與生產(chǎn)者的key.serializer對(duì)應(yīng)，key 的反序列化方式。

• value.deserializer：與生產(chǎn)者的value.serializer對(duì)應(yīng)，value 的反序列化方式。

• session.timeout.ms：coordinator 檢測(cè)失敗的時(shí)間。默認(rèn) 10s 該參數(shù)是 Consumer Group 主動(dòng)檢測(cè) (組內(nèi)成員  comsummer) 崩潰的時(shí)間間隔，類似于心跳過(guò)期時(shí)間。

• auto.offset.reset：該屬性指定了消費(fèi)者在讀取一個(gè)沒(méi)有偏移量后者偏移量無(wú)效(消費(fèi)者長(zhǎng)時(shí)間失效當(dāng)前的偏移量已經(jīng)過(guò)時(shí)并且被刪除了)的分區(qū)的情況下，應(yīng)該作何處理，默認(rèn)值是  latest，也就是從最新記錄讀取數(shù)據(jù)(消費(fèi)者啟動(dòng)之后生成的記錄)，另一個(gè)值是  earliest，意思是在偏移量無(wú)效的情況下，消費(fèi)者從起始位置開(kāi)始讀取數(shù)據(jù)。

• enable.auto.commit：否自動(dòng)提交位移，如果為false，則需要在程序中手動(dòng)提交位移。對(duì)于精確到一次的語(yǔ)義，最好手動(dòng)提交位移。

• fetch.max.bytes：?jiǎn)未卫?shù)據(jù)的最大字節(jié)數(shù)量。

• max.poll.records：?jiǎn)未?poll  調(diào)用返回的最大消息數(shù)，如果處理邏輯很輕量，可以適當(dāng)提高該值。但是max.poll.records條數(shù)據(jù)需要在在 session.timeout.ms  這個(gè)時(shí)間內(nèi)處理完 。默認(rèn)值為 500。

• request.timeout.ms：一次請(qǐng)求響應(yīng)的最長(zhǎng)等待時(shí)間。如果在超時(shí)時(shí)間內(nèi)未得到響應(yīng)，kafka  要么重發(fā)這條消息，要么超過(guò)重試次數(shù)的情況下直接置為失敗。

Kafka Rebalance

Rebalance 本質(zhì)上是一種協(xié)議，規(guī)定了一個(gè) Consumer Group 下的所有 Consumer 如何達(dá)成一致來(lái)分配訂閱 Topic  的每個(gè)分區(qū)。

比如某個(gè) Group 下有 20 個(gè) Consumer，它訂閱了一個(gè)具有 100 個(gè)分區(qū)的 Topic。

正常情況下，Kafka 平均會(huì)為每個(gè) Consumer 分配 5 個(gè)分區(qū)。這個(gè)分配的過(guò)程就叫 Rebalance。

①什么時(shí)候 Rebalance?這也是經(jīng)常被提及的一個(gè)問(wèn)題。

Rebalance 的觸發(fā)條件有三種：

• 組成員發(fā)生變更(新 Consumer 加入組、已有 Consumer 主動(dòng)離開(kāi)組或已有 Consumer 崩潰了——這兩者的區(qū)別后面會(huì)談到)

• 訂閱主題數(shù)發(fā)生變更

• 訂閱主題的分區(qū)數(shù)發(fā)生變更

②如何進(jìn)行組內(nèi)分區(qū)分配?

Kafka 默認(rèn)提供了兩種分配策略：Range 和 Round-Robin。當(dāng)然 Kafka  采用了可插拔式的分配策略，你可以創(chuàng)建自己的分配器以實(shí)現(xiàn)不同的分配策略。

答案關(guān)鍵字：

• Kafka 有哪些命令行工具?你用過(guò)哪些?/bin目錄，管理 Kafka 集群、管理 Topic、生產(chǎn)和消費(fèi) Kafka。

• Kafka Producer 的執(zhí)行過(guò)程?攔截器，序列化器，分區(qū)器和累加器。

• Kafka Producer 有哪些常見(jiàn)配置?Broker 配置，Ack 配置，網(wǎng)絡(luò)和發(fā)送參數(shù)，壓縮參數(shù)，Ack 參數(shù)。

• 如何讓 Kafka 的消息有序?Kafka 在 Topic 級(jí)別本身是無(wú)序的，只有 Partition  上才有序，所以為了保證處理順序，可以自定義分區(qū)器，將需順序處理的數(shù)據(jù)發(fā)送到同一個(gè) Partition。

• Producer 如何保證數(shù)據(jù)發(fā)送不丟失?Ack 機(jī)制，重試機(jī)制。

• 如何提升 Producer 的性能?批量，異步，壓縮。

• 如果同一 group 下 consumer 的數(shù)量大于 part 的數(shù)量，kafka 如何處理?多余的 Part 將處于無(wú)用狀態(tài)，不消費(fèi)數(shù)據(jù)。

• Kafka Consumer 是否是線程安全的?不安全，單線程消費(fèi)，多線程處理

• 講一下你使用 Kafka Consumer 消費(fèi)消息時(shí)的線程模型，為何如此設(shè)計(jì)?拉取和處理分離。

• Kafka Consumer 的常見(jiàn)配置?Broker, 網(wǎng)絡(luò)和拉取參數(shù)，心跳參數(shù)。

• Consumer 什么時(shí)候會(huì)被踢出集群?奔潰，網(wǎng)絡(luò)異常，處理時(shí)間過(guò)長(zhǎng)提交位移超時(shí)。

• 當(dāng)有 Consumer 加入或退出時(shí)，Kafka 會(huì)作何反應(yīng)?進(jìn)行 Rebalance。

• 什么是 Rebalance，何時(shí)會(huì)發(fā)生 Rebalance?Topic 變化，Consumer 變化。

高可用和性能

面試問(wèn)題：

• Kafka 如何保證高可用?

• Kafka 的交付語(yǔ)義?

• Replic 的作用?

• 什么事 AR，ISR?

• Leader 和 Flower 是什么?

• Kafka 中的 HW、LEO、LSO、LW 等分別代表什么?

• Kafka 為保證優(yōu)越的性能做了哪些處理?

分區(qū)與副本

分區(qū)副本

在分布式數(shù)據(jù)系統(tǒng)中，通常使用分區(qū)來(lái)提高系統(tǒng)的處理能力，通過(guò)副本來(lái)保證數(shù)據(jù)的高可用性。

多分區(qū)意味著并發(fā)處理的能力，這多個(gè)副本中，只有一個(gè)是 Leader，而其他的都是 Follower 副本。

僅有 Leader 副本可以對(duì)外提供服務(wù)。多個(gè) Follower 副本通常存放在和 Leader 副本不同的 Broker 中。

通過(guò)這樣的機(jī)制實(shí)現(xiàn)了高可用，當(dāng)某臺(tái)機(jī)器掛掉后，其他 Follower 副本也能迅速“轉(zhuǎn)正”，開(kāi)始對(duì)外提供服務(wù)。

①為什么 Follower 副本不提供讀服務(wù)?

這個(gè)問(wèn)題本質(zhì)上是對(duì)性能和一致性的取舍。試想一下，如果 Follower 副本也對(duì)外提供服務(wù)那會(huì)怎么樣呢?

首先，性能是肯定會(huì)有所提升的。但同時(shí)，會(huì)出現(xiàn)一系列問(wèn)題。類似數(shù)據(jù)庫(kù)事務(wù)中的幻讀，臟讀。

比如你現(xiàn)在寫(xiě)入一條數(shù)據(jù)到 Kafka 主題 a，消費(fèi)者 b 從主題 a 消費(fèi)數(shù)據(jù)，卻發(fā)現(xiàn)消費(fèi)不到，因?yàn)橄M(fèi)者 b  去讀取的那個(gè)分區(qū)副本中，最新消息還沒(méi)寫(xiě)入。

而這個(gè)時(shí)候，另一個(gè)消費(fèi)者 c 卻可以消費(fèi)到最新那條數(shù)據(jù)，因?yàn)樗M(fèi)了 Leader 副本。

Kafka 通過(guò) WH 和 Offset 的管理來(lái)決定 Consumer 可以消費(fèi)哪些數(shù)據(jù)，已經(jīng)當(dāng)前寫(xiě)入的數(shù)據(jù)。

Watermark

②只有 Leader 可以對(duì)外提供讀服務(wù)，那如何選舉 Leader

Kafka 會(huì)將與 Leader 副本保持同步的副本放到 ISR 副本集合中。當(dāng)然，Leader 副本是一直存在于 ISR  副本集合中的，在某些特殊情況下，ISR 副本中甚至只有 Leader 一個(gè)副本。

當(dāng) Leader 掛掉時(shí)，Kakfa 通過(guò) Zookeeper 感知到這一情況，在 ISR 副本中選取新的副本成為 Leader，對(duì)外提供服務(wù)。

但這樣還有一個(gè)問(wèn)題，前面提到過(guò)，有可能 ISR 副本集合中，只有 Leader，當(dāng) Leader 副本掛掉后，ISR 集合就為空，這時(shí)候怎么辦呢?

這時(shí)候如果設(shè)置 unclean.leader.election.enable 參數(shù)為 true，那么 Kafka 會(huì)在非同步，也就是不在 ISR  副本集合中的副本中，選取出副本成為 Leader。

③副本的存在就會(huì)出現(xiàn)副本同步問(wèn)題

Kafka 在所有分配的副本 (AR) 中維護(hù)一個(gè)可用的副本列表 (ISR)，Producer 向 Broker 發(fā)送消息時(shí)會(huì)根據(jù) ACK  配置來(lái)確定需要等待幾個(gè)副本已經(jīng)同步了消息才相應(yīng)成功。

Broker 內(nèi)部會(huì) ReplicaManager 服務(wù)來(lái)管理 Flower 與 Leader 之間的數(shù)據(jù)同步。

Sync

性能優(yōu)化:

• Partition 并發(fā)。

• 順序讀寫(xiě)磁盤。

• Page Cache：按頁(yè)讀寫(xiě)。

• 預(yù)讀：Kafka 會(huì)將將要消費(fèi)的消息提前讀入內(nèi)存。

• 高性能序列化(二進(jìn)制)。

• 內(nèi)存映射。

• 無(wú)鎖 Offset 管理：提高并發(fā)能力。

• Java NIO 模型。

• 批量：批量讀寫(xiě)。

• 壓縮：消息壓縮，存儲(chǔ)壓縮，減小網(wǎng)絡(luò)和 IO 開(kāi)銷。

Partition 并發(fā)

一方面，由于不同 Partition 可位于不同機(jī)器，因此可以充分利用集群優(yōu)勢(shì)，實(shí)現(xiàn)機(jī)器間的并行處理。

另一方面，由于 Partition 在物理上對(duì)應(yīng)一個(gè)文件夾，即使多個(gè) Partition 位于同一個(gè)節(jié)點(diǎn)，也可通過(guò)配置讓同一節(jié)點(diǎn)上的不同  Partition 置于不同的 disk drive 上，從而實(shí)現(xiàn)磁盤間的并行處理，充分發(fā)揮多磁盤的優(yōu)勢(shì)。

順序讀寫(xiě)

Kafka 每一個(gè) Partition 目錄下的文件被平均切割成大小相等(默認(rèn)一個(gè)文件是 500 兆，可以手動(dòng)去設(shè)置)的數(shù)據(jù)文件。

每一個(gè)數(shù)據(jù)文件都被稱為一個(gè)段(segment file), 每個(gè) segment 都采用 append 的方式追加數(shù)據(jù)。

追加數(shù)據(jù)

答案關(guān)鍵字：

• Kafka 如何保證高可用?通過(guò)副本來(lái)保證數(shù)據(jù)的高可用，Producer Ack、重試、自動(dòng) Leader 選舉，Consumer 自平衡。

• Kafka 的交付語(yǔ)義?交付語(yǔ)義一般有 at least once、at most once 和 exactly once。Kafka 通過(guò) Ack  的配置來(lái)實(shí)現(xiàn)前兩種。

• Replic 的作用?實(shí)現(xiàn)數(shù)據(jù)的高可用。

• 什么是 AR，ISR?AR：Assigned Replicas。AR 是主題被創(chuàng)建后，分區(qū)創(chuàng)建時(shí)被分配的副本集合，副本個(gè) 數(shù)由副本因子決定。

ISR：In-Sync Replicas。Kafka 中特別重要的概念，指代的是 AR 中那些與 Leader 保 持同步的副本集合。

在 AR 中的副本可能不在 ISR 中，但 Leader 副本天然就包含在 ISR 中。關(guān)于 ISR，還有一個(gè)常見(jiàn)的面試題目是如何判斷副本是否應(yīng)該屬于  ISR。

目前的判斷依據(jù)是：Follower 副本的 LEO 落后 Leader LEO 的時(shí)間，是否超過(guò)了 Broker 端參數(shù)  replica.lag.time.max.ms 值。如果超過(guò)了，副本就會(huì)被從 ISR 中移除。

• Leader 和 Flower 是什么?見(jiàn)上文。

• Kafka 中的 HW 代表什么?高水位值 (High watermark)。這是控制消費(fèi)者可讀取消息范圍的重要字段。

一個(gè)普通消費(fèi)者只能“看到”Leader 副本上介于 Log Start Offset 和 HW(不含)之間的  所有消息。水位以上的消息是對(duì)消費(fèi)者不可見(jiàn)的。

• Kafka 為保證優(yōu)越的性能做了哪些處理?Partition 并發(fā)、順序讀寫(xiě)磁盤、Page Cache 壓縮、高性能序列化(二進(jìn)制)、內(nèi)存映射、無(wú)鎖  Offset 管理、Java NIO 模型。

到此，關(guān)于“Kafka的相關(guān)知識(shí)點(diǎn)有哪些”的學(xué)習(xí)就結(jié)束了，希望能夠解決大家的疑惑。理論與實(shí)踐的搭配能更好的幫助大家學(xué)習(xí)，快去試試吧！若想繼續(xù)學(xué)習(xí)更多相關(guān)知識(shí)，請(qǐng)繼續(xù)關(guān)注億速云網(wǎng)站，小編會(huì)繼續(xù)努力為大家?guī)?lái)更多實(shí)用的文章！