kafka 重复消费和数据丢失_刨根问底，Kafka消息中间件到底会不会丢消息
大型互聯(lián)網(wǎng)公司一般都會要求消息傳遞最大限度的不丟失，比如用戶服務(wù)給代金券服務(wù)發(fā)送一個(gè)消息，如果消息丟失會造成用戶未收到應(yīng)得的代金券，最終用戶會投訴。
為避免上面類似情況的發(fā)生，除了做好補(bǔ)償措施，更應(yīng)該在系設(shè)計(jì)的時(shí)候充分考慮各種異常，設(shè)計(jì)一個(gè)穩(wěn)定、高可用的消息系統(tǒng)。
認(rèn)識Kafka
看一下維基百科的定義
Kafka是分布式發(fā)布-訂閱消息系統(tǒng)。它最初由LinkedIn公司開發(fā)，之后成為Apache項(xiàng)目的一部分。Kafka是一個(gè)分布式的，可劃分的，冗余備份的持久性的日志服務(wù)。它主要用于處理活躍的流式數(shù)據(jù)。kafka架構(gòu)
Kafka的整體架構(gòu)非常簡單，是顯式分布式架構(gòu)，主要由producer、broker(kafka)和consumer組成。
Kafka架構(gòu)(精簡版)
Producer(生產(chǎn)者)可以將數(shù)據(jù)發(fā)布到所選擇的topic(主題)中。生產(chǎn)者負(fù)責(zé)將記錄分配到topic的哪一個(gè) partition(分區(qū))中?？梢允褂醚h(huán)的方式來簡單地實(shí)現(xiàn)負(fù)載均衡，也可以根據(jù)某些語義分區(qū)函數(shù)(如記錄中的key)來完成。
Consumer(消費(fèi)者)使用一個(gè)consumer group(消費(fèi)組)名稱來進(jìn)行標(biāo)識，發(fā)布到topic中的每條記錄被分配給訂閱消費(fèi)組中的一個(gè)消費(fèi)者實(shí)例。消費(fèi)者實(shí)例可以分布在多個(gè)進(jìn)程中或者多個(gè)機(jī)器上。
Kafka到底會不會丟失消息？
在討論kafka是否丟消息前先來了解一下什么是 消息傳遞語義 。
消息傳遞語義
message delivery semantic 也就是消息傳遞語義，簡單說就是消息傳遞過程中消息傳遞的保證性。主要分為三種：
- at most once：最多一次。消息可能丟失也可能被處理，但最多只會被處理一次。
- at least once：至少一次。消息不會丟失，但可能被處理多次?？赡苤貜?fù)，不會丟失。
- exactly once：精確傳遞一次。消息被處理且只會被處理一次。不丟失不重復(fù)就一次。
理想情況下肯定是希望系統(tǒng)的消息傳遞是嚴(yán)格exactly once，也就是保證不丟失、只會被處理一次，但是很難做到。
回到主角Kafka，Kafka有三次消息傳遞的過程：
在這三步中每一步都有可能會丟失消息，下面詳細(xì)分析為什么會丟消息，如何最大限度避免丟失消息。
生產(chǎn)者丟失消息
先介紹一下生產(chǎn)者發(fā)送消息的一般流程(部分流程與具體配置項(xiàng)強(qiáng)相關(guān)，這里先忽略)：
生產(chǎn)者發(fā)送數(shù)據(jù)流程
生產(chǎn)者采用push模式將數(shù)據(jù)發(fā)布到broker，每條消息追加到分區(qū)中，順序?qū)懭氪疟P。消息寫入Leader后，Follower是主動與Leader進(jìn)行同步。
Kafka消息發(fā)送有兩種方式：同步(sync)和異步(async)，默認(rèn)是同步方式，可通過producer.type屬性進(jìn)行配置。
Kafka通過配置request.required.acks屬性來確認(rèn)消息的生產(chǎn)：
- 0表示不進(jìn)行消息接收是否成功的確認(rèn)；不能保證消息是否發(fā)送成功，生成環(huán)境基本不會用。
- 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級別是at least once，并不能exactly once。
敲黑板了，這里可能會丟消息的！
- 如果acks配置為0，發(fā)生網(wǎng)絡(luò)抖動消息丟了，生產(chǎn)者不校驗(yàn)ACK自然就不知道丟了。
- 如果acks配置為1保證leader不丟，但是如果leader掛了，恰好選了一個(gè)沒有ACK的follower，那也丟了。
- all：保證leader和follower不丟，但是如果網(wǎng)絡(luò)擁塞，沒有收到ACK，會有重復(fù)發(fā)的問題。
Kafka Broker丟失消息
Kafka Broker 接收到數(shù)據(jù)后會將數(shù)據(jù)進(jìn)行持久化存儲，你以為是下面這樣的：
消息持久化，無cache
沒想到是這樣的：
消息持久化，有cache
操作系統(tǒng)本身有一層緩存，叫做 Page Cache，當(dāng)往磁盤文件寫入的時(shí)候，系統(tǒng)會先將數(shù)據(jù)流寫入緩存中，至于什么時(shí)候?qū)⒕彺娴臄?shù)據(jù)寫入文件中是由操作系統(tǒng)自行決定。
Kafka提供了一個(gè)參數(shù) producer.type 來控制是不是主動flush，如果Kafka寫入到mmap之后就立即 flush 然后再返回 Producer 叫同步 (sync)；寫入mmap之后立即返回 Producer 不夠用 flush 叫異步 (async)。
敲黑板了，這里可能會丟消息的！
Kafka通過多分區(qū)多副本機(jī)制中已經(jīng)能最大限度保證數(shù)據(jù)不會丟失，如果數(shù)據(jù)已經(jīng)寫入系統(tǒng) cache 中但是還沒來得及刷入磁盤，此時(shí)突然機(jī)器宕機(jī)或者掉電那就丟了，當(dāng)然這種情況很極端。
消費(fèi)者丟失消息
消費(fèi)者通過pull模式主動的去 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ù)，但是不會出現(xiàn)多個(gè)消費(fèi)者消費(fèi)同一分區(qū)的數(shù)據(jù)。
消費(fèi)者群組消費(fèi)消息
消費(fèi)者消費(fèi)的進(jìn)度通過offset保存在kafka集群的__consumer_offsets這個(gè)topic中。
消費(fèi)消息的時(shí)候主要分為兩個(gè)階段：
1、標(biāo)識消息已被消費(fèi)，commit offset坐標(biāo)；
2、處理消息。
敲黑板了，這里可能會丟消息的！
場景一：先commit再處理消息。如果在處理消息的時(shí)候異常了，但是offset 已經(jīng)提交了，這條消息對于該消費(fèi)者來說就是丟失了，再也不會消費(fèi)到了。
場景二：先處理消息再commit。如果在commit之前發(fā)生異常，下次還會消費(fèi)到該消息，重復(fù)消費(fèi)的問題可以通過業(yè)務(wù)保證消息冪等性來解決。
總結(jié)
那么問題來了，kafka到底會不會丟消息？答案是：會！
Kafka可能會在三個(gè)階段丟失消息：
(1)生產(chǎn)者發(fā)送數(shù)據(jù)；
(2)Kafka Broker 存儲數(shù)據(jù)；
(3)消費(fèi)者消費(fèi)數(shù)據(jù)；
在生產(chǎn)環(huán)境中嚴(yán)格做到exactly once其實(shí)是難的，同時(shí)也會犧牲效率和吞吐量，最佳實(shí)踐是業(yè)務(wù)側(cè)做好補(bǔ)償機(jī)制，萬一出現(xiàn)消息丟失可以兜底。
原文鏈接：https://mp.weixin.qq.com/s?__biz=MzIwODI1OTk1Nw==&mid=2650321970&idx=1&sn=3a26ed6f0323c945c1eacb05c758cd62
- END -
說兩句：學(xué)習(xí)是一件時(shí)而郁郁寡歡時(shí)而開懷大笑的事情，越過瓶頸又是一片新天地，堅(jiān)持堅(jiān)持堅(jiān)持。如果覺得本文對你有幫助，可以轉(zhuǎn)發(fā)關(guān)注支持一下
總結(jié)
以上是生活随笔為你收集整理的kafka 重复消费和数据丢失_刨根问底，Kafka消息中间件到底会不会丢消息的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： window连接不上linux ftp_
- 下一篇： snipaste滚动截图方法_电脑必备！