Kafka 是一個(gè)優(yōu)秀的分布式消息中間件，許多系統(tǒng)中都會(huì)使用到 Kafka 來(lái)做消息通信。對(duì)分布式消息系統(tǒng)的了解和使用幾乎成為一個(gè)后臺(tái)開(kāi)發(fā)人員必備的技能。今天就從常見(jiàn)的 Kafka 面試題入手，和大家聊聊 Kafka 的那些事兒。

思維導(dǎo)圖

講一講分布式消息中間件

問(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ì)比：

選擇

答案關(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 是否支持讀寫分離？
• Kafka 如何保證數(shù)據(jù)高可用？
• Kafka 中 zookeeper 的作用？
• 是否支持事務(wù)？
• 分區(qū)數(shù)是否可以減少？

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

架構(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ì)外提供讀寫服務(wù)，當(dāng)主副本所在 broker 崩潰或發(fā)生網(wǎng)絡(luò)一場(chǎng)，Kafka 會(huì)在 Controller 的管理下會(huì)重新選擇新的 Leader 副本對(duì)外提供讀寫服務(wù)。
• Record：實(shí)際寫入 Kafka 中并可以被讀取的消息記錄。每個(gè) record 包含了 key、value 和 timestamp。

Kafka Topic Partitions Layout

主題

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

Kafka Consumer Offset

consumer offset

zookeeper

zookeeper

• 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 是否支持讀寫分離？不支持，只有 Leader 對(duì)外提供讀寫服務(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：啟動(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：啟動(dòng) zk 服務(wù)
• zookeeper-server-stop.sh：停止 zk 服務(wù)
• zookeeper-shell.sh：zk 客戶端

我們通常可以使用kafka-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)寫入它的本地 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：單次拉取數(shù)據(jù)的最大字節(jié)數(shù)量
• max.poll.records：單次 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)在寫入一條數(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)寫入。而這個(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)前寫入的數(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ā)
• 順序讀寫磁盤
• page cache：按頁(yè)讀寫
• 預(yù)讀：Kafka 會(huì)將將要消費(fèi)的消息提前讀入內(nèi)存
• 高性能序列化(二進(jìn)制)
• 內(nèi)存映射
• 無(wú)鎖 offset 管理：提高并發(fā)能力
• Java NIO 模型
• 批量：批量讀寫
• 壓縮：消息壓縮，存儲(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ì)。

順序讀寫

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 是什么？
• Kafka 中的 HW 代表什么？高水位值 (High watermark)。這是控制消費(fèi)者可讀取消息范圍的重要字段。一 個(gè)普通消費(fèi)者只能“看到”Leader 副本上介于 Log Start Offset 和 HW(不含)之間的 所有消息。水位以上的消息是對(duì)消費(fèi)者不可見(jiàn)的。
• Kafka 為保證優(yōu)越的性能做了哪些處理？partition 并發(fā)、順序讀寫磁盤、page cache 壓縮、高性能序列化(二進(jìn)制)、內(nèi)存映射 無(wú)鎖 offset 管理、Java NIO 模型

本文并沒(méi)有深入 Kafka 的實(shí)現(xiàn)細(xì)節(jié)和源碼分析，但 Kafka 確實(shí)是一個(gè) 優(yōu)秀的開(kāi)源系統(tǒng)，很多優(yōu)雅的架構(gòu)設(shè)計(jì)和源碼設(shè)計(jì)都值得我們學(xué)習(xí)，十分建議感興趣的同學(xué)更加深入的去了解一下這個(gè)開(kāi)源系統(tǒng)，對(duì)于自身架構(gòu)設(shè)計(jì)能力，編碼能力，性能優(yōu)化都會(huì)有很大的幫助。

總結(jié)

以上是生活随笔為你收集整理的kafka 削峰_从面试角度一文学完 Kafka的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。