引言

Hey, 小伙伴們！今天小米給大家?guī)硪黄P(guān)于Kafka生產(chǎn)消費基本流程的揭秘，內(nèi)容超干貨！讓我們一起揭開Kafka神秘的面紗，探索它的工作原理吧！

圖片

Producer創(chuàng)建及其內(nèi)部結(jié)構(gòu)

當我們創(chuàng)建一個Kafka Producer時，Kafka會為我們創(chuàng)建一個叫做Sender的線程，并將其設(shè)置為守護線程（Daemon Thread）。這個線程的主要工作就是不斷地從緩沖區(qū)中取出消息并發(fā)送給Kafka Broker。守護線程的好處在于，它會隨著主線程的結(jié)束而自動結(jié)束，不需要我們手動去管理它的生命周期。

消息的處理流程

在Producer發(fā)送消息的過程中，消息會依次經(jīng)過以下幾個步驟：

1. 攔截器（Interceptor）：首先，消息會通過一系列的攔截器進行處理。攔截器可以用來在消息發(fā)送之前或之后做一些額外的操作，比如修改消息內(nèi)容、統(tǒng)計日志等。
2. 序列化器（Serializer）：然后，消息會經(jīng)過序列化器，將消息對象轉(zhuǎn)換為字節(jié)數(shù)組，以便于網(wǎng)絡(luò)傳輸。
3. 分區(qū)器（Partitioner）：接下來，分區(qū)器會根據(jù)消息的Key或者其他策略將消息分配到指定的分區(qū)上。
4. 緩沖區(qū)（Buffer Pool）：最后，消息會被放入到Producer的緩沖區(qū)中等待發(fā)送。

批次發(fā)送的條件

Kafka的Producer會將消息進行批量發(fā)送，以提高傳輸效率和吞吐量。具體的批次發(fā)送條件如下：

• 當緩沖區(qū)中的數(shù)據(jù)大小達到batch.size時，Producer會將這些消息組成一個批次進行發(fā)送。
• 當消息在緩沖區(qū)中的等待時間超過linger.ms時，即使緩沖區(qū)中的數(shù)據(jù)大小沒有達到batch.size，Producer也會將這些消息組成一個批次進行發(fā)送。

消息發(fā)送及落盤

當批次發(fā)送的條件滿足時，Producer會將消息發(fā)往指定的分區(qū)，然后落盤到Kafka Broker中。消息發(fā)送的可靠性可以通過acks參數(shù)進行控制：

• acks=0：當acks設(shè)置為0時，Producer只要將消息放到緩沖區(qū)，就認為消息已經(jīng)發(fā)送完成。這個模式下的消息發(fā)送速度最快，但可靠性最低，因為Producer不會等待任何確認，消息有可能會丟失。
• acks=1：當acks設(shè)置為1時，消息只需要寫到主分區(qū)（Leader Partition）即可。在這種情況下，如果主分區(qū)收到消息確認之后就宕機了，而副本分區(qū)（Follower Partition）還沒來得及同步該消息，則該消息會丟失。
• acks=all（默認）：當acks設(shè)置為all（默認值）時，Leader分區(qū)會等待所有的ISR副本分區(qū)（In-Sync Replica）確認記錄。這種模式下，只要有一個ISR副本分區(qū)存活，消息就不會丟失，是可靠性最高的一種設(shè)置。

消息重試機制

如果生產(chǎn)者配置了retries參數(shù)大于0，并且未收到消息的確認，那么Producer客戶端會對該消息進行重試。重試機制能夠有效提高消息發(fā)送的可靠性，避免由于網(wǎng)絡(luò)波動或臨時故障導(dǎo)致的消息丟失。

消息落盤及元數(shù)據(jù)返回

當消息成功落盤到Kafka Broker后，Broker會返回生產(chǎn)元數(shù)據(jù)給Producer。這個元數(shù)據(jù)包含了消息的主題、分區(qū)、偏移量等信息。Producer可以通過這些信息進行消息的追蹤和管理。

END

好了，以上就是Kafka生產(chǎn)消費基本流程的詳細揭秘啦！希望小伙伴們通過這篇文章對Kafka的工作原理有更深入的了解。如果你對Kafka還有其他疑問或者想要了解更多技術(shù)干貨，歡迎在評論區(qū)留言，小米會及時回復(fù)大家哦！

圖片