Kafka 會不會丟消息？

1、認識 Kafka

Kafka 是分佈式發佈-訂閱消息系統。它最初由 LinkedIn 公司開發，以後成爲 Apache 項目的一部分。

Kafka 是一個分佈式的，可劃分的，冗餘備份的持久性的日誌服務。它主要用於處理活躍的流式數據。

1. kafka 架構

Kafka 的總體架構很是簡單，是顯式分佈式架構，主要由 producer、broker（kafka）和 consumer 組成。

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

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

2、Kafka 到底會不會丟失消息？

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

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

• at most once：最多一次。消息可能丟失也可能被處理，但最多隻會被處理一次。
• at least once：至少一次。消息不會丟失，但可能被處理屢次。可能重複，不會丟失。
• exactly once：精確傳遞一次。消息被處理且只會被處理一次。不丟失不重複就一次。

理想狀況下確定是但願系統的消息傳遞是嚴格 exactly once，也就是保證不丟失、只會被處理一次，可是很難作到。

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

• 生產者發消息給 Kafka Broker。
• Kafka Broker 消息同步和持久化
• Kafka Broker 將消息傳遞給消費者。

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

3、生產者丟失消息

先介紹一下生產者發送消息的通常流程（部分流程與具體配置項強相關，這裏先忽略）：

1. 生產者是與 leader 直接交互，因此先從集羣獲取 topic 對應分區的 leader 元數據；
2. 獲取到 leader 分區元數據後直接將消息發給過去；
3. Kafka Broker 對應的 leader 分區收到消息後寫入文件持久化；
4. Follower 拉取 Leader 消息與 Leader 的數據保持一致；
5. Follower 消息拉取完畢須要給 Leader 回覆 ACK 確認消息；
6. Kafka Leader 和 Follower 分區同步完，Leader 分區會給生產者回復 ACK 確認消息。

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

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

Kafka 經過配置 request.required.acks 屬性來確認 Producer 的消息：

• 0：表示不進行消息接收是否成功的確認；不能保證消息是否發送成功，生成環境基本不會用。
• 1：默認值，表示當 Leader 接收成功時確認；只要 Leader 存活就能夠保證不丟失，保證了吞吐量。因此默認的 producer 級別是 at least once。
• all：保證 leader 和 follower 不丟，可是若是網絡擁塞，沒有收到 ACK，會有重複發的問題。

若是 acks 配置爲 0，發生網絡抖動消息丟了，生產者不校驗 ACK 天然就不知道丟了。

若是 acks 配置爲 1 保證 leader 不丟，可是若是 leader 掛了，剛好選了一個沒有 ACK 的 follower，那也丟了。

若是 acks 配置爲 all 保證 leader 和 follower 不丟，可是若是網絡擁塞，沒有收到 ACK，會有重複發的問題。

4、Kafka Broker 丟失消息

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

沒想到是這樣的：

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

Kafka 提供了一個參數 producer.type 來控制是否是主動 flush，若是 Kafka 寫入到 mmap 以後就當即 flush 而後再返回 Producer 叫同步 (sync)；寫入 mmap 以後當即返回 Producer 不調用 flush 叫異步 (async)。

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

5、消費者丟失消息

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

多個消費者能夠組成一個消費者組（consumer group），每一個消費者組都有一個組id。同一個消費者組的消費者能夠消費同一 topic 下不一樣分區的數據，可是不會出現多個消費者消費同一分區的數據。

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

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

1. 標識消息已被消費，commit offset座標；
2. 處理消息。

先 commit 再處理消息。若是在處理消息的時候異常了，可是 offset 已經提交了，這條消息對於該消費者來講就是丟失了，不再會消費到了。

先處理消息再 commit。若是在 commit 以前發生異常，下次還會消費到該消息，重複消費的問題能夠經過業務保證消息冪等性來解決。

6、總結

那麼問題來了，kafka到底會不會丟消息？答案是：會！

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

1. 生產者發送數據；
2. Kafka Broker 存儲數據；
3. 消費者消費數據；

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

原文連接：面試被問：Kafka 會不會丟消息？我是這麼答的