<kbd id="afajh"><form id="afajh"></form></kbd>
<strong id="afajh"><dl id="afajh"></dl></strong>
    <del id="afajh"><form id="afajh"></form></del>
        1. <th id="afajh"><progress id="afajh"></progress></th>
          <b id="afajh"><abbr id="afajh"></abbr></b>
          <th id="afajh"><progress id="afajh"></progress></th>

          Kafka消息中間件到底會(huì)不會(huì)丟消息

          共 3070字,需瀏覽 7分鐘

           ·

          2020-11-17 22:10


          本文公眾號(hào)來源:愛笑的架構(gòu)師
          作者:雷架
          本文已收錄至我的GitHub

          前面文章回顧:

          什么是消息隊(duì)列?

          Kafka通俗易懂入門

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

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

          認(rèn)識(shí)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ū))中。可以使用循環(huán)的方式來簡單地實(shí)現(xiàn)負(fù)載均衡,也可以根據(jù)某些語義分區(qū)函數(shù)(如記錄中的key)來完成。

          Consumer(消費(fèi)者)使用一個(gè)consumer group(消費(fè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是否丟消息前先來了解一下什么是消息傳遞語義

          消息傳遞語義

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

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

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

          回到主角Kafka,Kafka有三次消息傳遞的過程:

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

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

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

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

          1. 生產(chǎn)者是與leader直接交互,所以先從集群獲取topic對(duì)應(yīng)分區(qū)的leader元數(shù)據(jù);
          2. 獲取到leader分區(qū)元數(shù)據(jù)后直接將消息發(fā)給過去;
          3. Kafka Broker對(duì)應(yīng)的leader分區(qū)收到消息后寫入文件持久化;
          4. Follower拉取Leader消息與Leader的數(shù)據(jù)保持一致;
          5. Follower消息拉取完畢需要給Leader回復(fù)ACK確認(rèn)消息;
          6. 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。消息寫入Leader后,F(xiàn)ollower是主動(dòng)與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)境基本不會(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è)沒有ACK的follower,那也丟了。
          • all:保證leader和follower不丟,但是如果網(wǎng)絡(luò)擁塞,沒有收到ACK,會(huì)有重復(fù)發(fā)的問題。

          Kafka Broker丟失消息

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

          消息持久化,無cache

          沒想到是這樣的:

          消息持久化,有cache

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

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

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

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

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

          消費(fèi)者通過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ù)。

          消費(fèi)者群組消費(fèi)消息

          消費(fèi)者消費(fèi)的進(jìn)度通過offset保存在kafka集群的__consumer_offsets這個(gè)topic中。

          消費(fèi)消息的時(shí)候主要分為兩個(gè)階段:

          1、標(biāo)識(shí)消息已被消費(fèi),commit offset坐標(biāo);

          2、處理消息。

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

          場景一:先commit再處理消息。如果在處理消息的時(shí)候異常了,但是offset 已經(jīng)提交了,這條消息對(duì)于該消費(fèi)者來說就是丟失了,再也不會(huì)消費(fèi)到了。

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

          總結(jié)

          那么問題來了,kafka到底會(huì)不會(huì)丟消息?答案是:會(huì)!

          Kafka可能會(huì)在三個(gè)階段丟失消息:

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

          (2)Kafka Broker 存儲(chǔ)數(shù)據(jù);

          (3)消費(fèi)者消費(fèi)數(shù)據(jù);

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



          原創(chuàng)電子書

          原創(chuàng)思維導(dǎo)圖

          掃碼或微信搜 Java3y?回復(fù)「888」領(lǐng)取1000+原創(chuàng)電子書和思維導(dǎo)圖。

          瀏覽 136
          點(diǎn)贊
          評(píng)論
          收藏
          分享

          手機(jī)掃一掃分享

          分享
          舉報(bào)
          評(píng)論
          圖片
          表情
          推薦
          點(diǎn)贊
          評(píng)論
          收藏
          分享

          手機(jī)掃一掃分享

          分享
          舉報(bào)
          <kbd id="afajh"><form id="afajh"></form></kbd>
          <strong id="afajh"><dl id="afajh"></dl></strong>
            <del id="afajh"><form id="afajh"></form></del>
                1. <th id="afajh"><progress id="afajh"></progress></th>
                  <b id="afajh"><abbr id="afajh"></abbr></b>
                  <th id="afajh"><progress id="afajh"></progress></th>
                  www色色 | 91精品久久久久 | 黃色一级A片一級片 | 国产精品无码AV无码 | 青青草成人手机在线视频 |