刨根問(wèn)底,Kafka消息中間件到底會(huì)不會(huì)丟消息

作者：雷架 2020-11-13 07:14:55

大型互聯(lián)網(wǎng)公司一般都會(huì)要求消息傳遞最大限度的不丟失，比如用戶(hù)服務(wù)給代金券服務(wù)發(fā)送一個(gè)消息，如果消息丟失會(huì)造成用戶(hù)未收到應(yīng)得的代金券，最終用戶(hù)會(huì)投訴。

[[351967]]

本文轉(zhuǎn)載自微信公眾號(hào)「愛(ài)笑的架構(gòu)師」，作者雷架。轉(zhuǎn)載本文請(qǐng)聯(lián)系愛(ài)笑的架構(gòu)師公眾號(hào)。

為避免上面類(lèi)似情況的發(fā)生，除了做好補(bǔ)償措施，更應(yīng)該在系設(shè)計(jì)的時(shí)候充分考慮各種異常，設(shè)計(jì)一個(gè)穩(wěn)定、高可用的消息系統(tǒng)。

認(rèn)識(shí)Kafka

看一下維基百科的定義

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

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

kafka架構(gòu)

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

Kafka架構(gòu)(精簡(jiǎn)版)

Producer(生產(chǎn)者)可以將數(shù)據(jù)發(fā)布到所選擇的topic(主題)中。生產(chǎn)者負(fù)責(zé)將記錄分配到topic的哪一個(gè) partition(分區(qū))中。可以使用循環(huán)的方式來(lái)簡(jiǎn)單地實(shí)現(xiàn)負(fù)載均衡，也可以根據(jù)某些語(yǔ)義分區(qū)函數(shù)(如記錄中的key)來(lái)完成。

Consumer(消費(fèi)者)使用一個(gè)consumer group(消費(fèi)組)名稱(chēng)來(lái)進(jìn)行標(biāo)識(shí)，發(fā)布到topic中的每條記錄被分配給訂閱消費(fèi)組中的一個(gè)消費(fèi)者實(shí)例。消費(fèi)者實(shí)例可以分布在多個(gè)進(jìn)程中或者多個(gè)機(jī)器上。

Kafka到底會(huì)不會(huì)丟失消息?

在討論kafka是否丟消息前先來(lái)了解一下什么是消息傳遞語(yǔ)義。

消息傳遞語(yǔ)義

message delivery semantic 也就是消息傳遞語(yǔ)義，簡(jiǎn)單說(shuō)就是消息傳遞過(guò)程中消息傳遞的保證性。主要分為三種：

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

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

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

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

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

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

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

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

生產(chǎn)者發(fā)送數(shù)據(jù)流程

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

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

Kafka通過(guò)配置request.required.acks屬性來(lái)確認(rèn)消息的生產(chǎn)：

0表示不進(jìn)行消息接收是否成功的確認(rèn);不能保證消息是否發(fā)送成功，生成環(huán)境基本不會(huì)用。
1表示當(dāng)Leader接收成功時(shí)確認(rèn);只要Leader存活就可以保證不丟失，保證了吞吐量。
-1或者all表示Leader和Follower都接收成功時(shí)確認(rèn);可以最大限度保證消息不丟失，但是吞吐量低。

kafka producer 的參數(shù)acks 的默認(rèn)值為1，所以默認(rèn)的producer級(jí)別是at least once，并不能exactly once。

敲黑板了，這里可能會(huì)丟消息的!

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

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

all：保證leader和follower不丟，但是如果網(wǎng)絡(luò)擁塞，沒(méi)有收到ACK，會(huì)有重復(fù)發(fā)的問(wèn)題。

Kafka Broker丟失消息

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

消息持久化，無(wú)cache

沒(méi)想到是這樣的：

消息持久化，有cache

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

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

敲黑板了，這里可能會(huì)丟消息的!

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

消費(fèi)者丟失消息

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

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