Kafka消息中間件會丟消息嗎

本篇內容介紹了“Kafka消息中間件會丟消息嗎”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！

認識Kafka

看一下維基百科的定義

Kafka是分布式發布-訂閱消息系統。它最初由LinkedIn公司開發，之后成為Apache項目的一部分。

Kafka是一個分布式的，可劃分的，冗余備份的持久性的日志服務。它主要用于處理活躍的流式數據。

kafka架構

Kafka的整體架構非常簡單，是顯式分布式架構，主要由producer、broker(kafka)和consumer組成。

Kafka架構(精簡版)

Producer(生產者)可以將數據發布到所選擇的topic(主題)中。生產者負責將記錄分配到topic的哪一個  partition(分區)中。可以使用循環的方式來簡單地實現負載均衡，也可以根據某些語義分區函數(如記錄中的key)來完成。

Consumer(消費者)使用一個consumer  group(消費組)名稱來進行標識，發布到topic中的每條記錄被分配給訂閱消費組中的一個消費者實例。消費者實例可以分布在多個進程中或者多個機器上。

Kafka到底會不會丟失消息?

在討論kafka是否丟消息前先來了解一下什么是消息傳遞語義。

消息傳遞語義

message delivery semantic 也就是消息傳遞語義，簡單說就是消息傳遞過程中消息傳遞的保證性。主要分為三種：

• at most once：最多一次。消息可能丟失也可能被處理，但最多只會被處理一次。

• at least once：至少一次。消息不會丟失，但可能被處理多次。可能重復，不會丟失。

• exactly once：精確傳遞一次。消息被處理且只會被處理一次。不丟失不重復就一次。

理想情況下肯定是希望系統的消息傳遞是嚴格exactly once，也就是保證不丟失、只會被處理一次，但是很難做到。

回到主角Kafka，Kafka有三次消息傳遞的過程：

1. 鴻蒙官方戰略合作共建——HarmonyOS技術社區

2. 生產者發消息給Kafka Broker。

3. Kafka Broker 消息同步和持久化

4. Kafka Broker 將消息傳遞給消費者。

在這三步中每一步都有可能會丟失消息，下面詳細分析為什么會丟消息，如何最大限度避免丟失消息。

生產者丟失消息

先介紹一下生產者發送消息的一般流程(部分流程與具體配置項強相關，這里先忽略)：

1. 鴻蒙官方戰略合作共建——HarmonyOS技術社區

2. 生產者是與leader直接交互，所以先從集群獲取topic對應分區的leader元數據;

3. 獲取到leader分區元數據后直接將消息發給過去;

4. Kafka Broker對應的leader分區收到消息后寫入文件持久化;

5. Follower拉取Leader消息與Leader的數據保持一致;

6. Follower消息拉取完畢需要給Leader回復ACK確認消息;

7. Kafka Leader和Follower分區同步完，Leader分區會給生產者回復ACK確認消息。

生產者發送數據流程

生產者采用push模式將數據發布到broker，每條消息追加到分區中，順序寫入磁盤。消息寫入Leader后，Follower是主動與Leader進行同步。

Kafka消息發送有兩種方式：同步(sync)和異步(async)，默認是同步方式，可通過producer.type屬性進行配置。

Kafka通過配置request.required.acks屬性來確認消息的生產：

• 0表示不進行消息接收是否成功的確認;不能保證消息是否發送成功，生成環境基本不會用。

• 1表示當Leader接收成功時確認;只要Leader存活就可以保證不丟失，保證了吞吐量。

• -1或者all表示Leader和Follower都接收成功時確認;可以最大限度保證消息不丟失，但是吞吐量低。

kafka producer 的參數acks 的默認值為1，所以默認的producer級別是at least once，并不能exactly  once。

敲黑板了，這里可能會丟消息的!

如果acks配置為0，發生網絡抖動消息丟了，生產者不校驗ACK自然就不知道丟了。

如果acks配置為1保證leader不丟，但是如果leader掛了，恰好選了一個沒有ACK的follower，那也丟了。

all：保證leader和follower不丟，但是如果網絡擁塞，沒有收到ACK，會有重復發的問題。

Kafka Broker丟失消息

Kafka Broker 接收到數據后會將數據進行持久化存儲，你以為是下面這樣的：

消息持久化，無cache

沒想到是這樣的：

消息持久化，有cache

操作系統本身有一層緩存，叫做 Page  Cache，當往磁盤文件寫入的時候，系統會先將數據流寫入緩存中，至于什么時候將緩存的數據寫入文件中是由操作系統自行決定。

Kafka提供了一個參數 producer.type 來控制是不是主動flush，如果Kafka寫入到mmap之后就立即 flush 然后再返回  Producer 叫同步 (sync);寫入mmap之后立即返回 Producer 不調用 flush 叫異步 (async)。

敲黑板了，這里可能會丟消息的!

Kafka通過多分區多副本機制中已經能最大限度保證數據不會丟失，如果數據已經寫入系統 cache  中但是還沒來得及刷入磁盤，此時突然機器宕機或者掉電那就丟了，當然這種情況很極端。

消費者丟失消息

消費者通過pull模式主動的去 kafka 集群拉取消息，與producer相同的是，消費者在拉取消息的時候也是找leader分區去拉取。

多個消費者可以組成一個消費者組(consumer  group)，每個消費者組都有一個組id。同一個消費組者的消費者可以消費同一topic下不同分區的數據，但是不會出現多個消費者消費同一分區的數據。

消費者群組消費消息

消費者消費的進度通過offset保存在kafka集群的__consumer_offsets這個topic中。

消費消息的時候主要分為兩個階段：

1、標識消息已被消費，commit offset坐標;

2、處理消息。

敲黑板了，這里可能會丟消息的!

場景一：先commit再處理消息。如果在處理消息的時候異常了，但是offset 已經提交了，這條消息對于該消費者來說就是丟失了，再也不會消費到了。

場景二：先處理消息再commit。如果在commit之前發生異常，下次還會消費到該消息，重復消費的問題可以通過業務保證消息冪等性來解決。

總結

那么問題來了，kafka到底會不會丟消息?答案是：會!

Kafka可能會在三個階段丟失消息：

(1)生產者發送數據;

(2)Kafka Broker 存儲數據;

(3)消費者消費數據;

在生產環境中嚴格做到exactly once其實是難的，同時也會犧牲效率和吞吐量，最佳實踐是業務側做好補償機制，萬一出現消息丟失可以兜底。

“Kafka消息中間件會丟消息嗎”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識可以關注億速云網站，小編將為大家輸出更多高質量的實用文章！