一、認(rèn)識 Kafka

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

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

1. kafka 架構(gòu)

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

Producer（生產(chǎn)者）可以將數(shù)據(jù)發(fā)布到所選擇的 topic（主題）中。生產(chǎn)者負(fù)責(zé)將記錄分配到 topic 的哪一個 partition（分區(qū)）中?？梢允褂醚h(huán)的方式來簡單地實現(xiàn)負(fù)載均衡，也可以根據(jù)某些語義分區(qū)函數(shù)（如記錄中的key）來完成。

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

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

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

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

• at most once：最多一次。消息可能丟失也可能被處理，但最多只會被處理一次。
• at least once：至少一次。消息不會丟失，但可能被處理多次?？赡苤貜?fù)，不會丟失。
• exactly once：精確傳遞一次。消息被處理且只會被處理一次。不丟失不重復(fù)就一次。

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

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

• 生產(chǎn)者發(fā)消息給 Kafka Broker。
• Kafka Broker 消息同步和持久化
• Kafka Broker 將消息傳遞給消費者。

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

三、生產(chǎn)者丟失消息

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

1. 生產(chǎn)者是與 leader 直接交互，所以先從集群獲取 topic 對應(yīng)分區(qū)的 leader 元數(shù)據(jù)；
2. 獲取到 leader 分區(qū)元數(shù)據(jù)后直接將消息發(fā)給過去；
3. Kafka Broker 對應(yīng)的 leader 分區(qū)收到消息后寫入文件持久化；
4. Follower 拉取 Leader 消息與 Leader 的數(shù)據(jù)保持一致；
5. Follower 消息拉取完畢需要給 Leader 回復(fù) ACK 確認(rèn)消息；
6. Kafka Leader 和 Follower 分區(qū)同步完，Leader 分區(qū)會給生產(chǎn)者回復(fù) ACK 確認(rèn)消息。

生產(chǎn)者采用 push 模式將數(shù)據(jù)發(fā)布到 broker，每條消息追加到分區(qū)中，順序?qū)懭氪疟P。消息寫入 Leader 后，F(xiàn)ollower 是主動與 Leader 進行同步。

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

Kafka 通過配置 request.required.acks 屬性來確認(rèn) Producer 的消息：

• 0：表示不進行消息接收是否成功的確認(rèn)；不能保證消息是否發(fā)送成功，生成環(huán)境基本不會用。
• 1：默認(rèn)值，表示當(dāng) Leader 接收成功時確認(rèn)；只要 Leader 存活就可以保證不丟失，保證了吞吐量。所以默認(rèn)的 producer 級別是 at least once。
• all：保證 leader 和 follower 不丟，但是如果網(wǎng)絡(luò)擁塞，沒有收到 ACK，會有重復(fù)發(fā)的問題。

如果 acks 配置為 0，發(fā)生網(wǎng)絡(luò)抖動消息丟了，生產(chǎn)者不校驗 ACK 自然就不知道丟了。

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

如果 acks 配置為 all 保證 leader 和 follower 不丟，但是如果網(wǎng)絡(luò)擁塞，沒有收到 ACK，會有重復(fù)發(fā)的問題。

四、Kafka Broker 丟失消息

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

沒想到是這樣的：

操作系統(tǒng)本身有一層緩存，叫做 Page Cache，當(dāng)往磁盤文件寫入的時候，系統(tǒng)會先將數(shù)據(jù)流寫入緩存中，至于什么時候?qū)⒕彺娴臄?shù)據(jù)寫入文件中是由操作系統(tǒng)自行決定。

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

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

五、消費者丟失消息

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

多個消費者可以組成一個消費者組（consumer group），每個消費者組都有一個組id。同一個消費者組的消費者可以消費同一 topic 下不同分區(qū)的數(shù)據(jù)，但是不會出現(xiàn)多個消費者消費同一分區(qū)的數(shù)據(jù)。

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

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

1. 標(biāo)識消息已被消費，commit offset坐標(biāo)；
2. 處理消息。

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

先處理消息再 commit。如果在 commit 之前發(fā)生異常，下次還會消費到該消息，重復(fù)消費的問題可以通過業(yè)務(wù)保證消息冪等性來解決。

六、總結(jié)

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

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

1. 生產(chǎn)者發(fā)送數(shù)據(jù)；
2. Kafka Broker 存儲數(shù)據(jù)；
3. 消費者消費數(shù)據(jù)；

在生產(chǎn)環(huán)境中嚴(yán)格做到 exactly once 其實是難的，同時也會犧牲效率和吞吐量，最佳實踐是業(yè)務(wù)側(cè)做好補償機制，萬一出現(xiàn)消息丟失可以兜底。

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