Apache Kafka訊息傳遞可靠性分析

2021-09-12 02:58:20 字數 1109 閱讀 1713

如果mq沒有類似資料庫事務結構和保證,是不可能達到訊息投遞100%可靠的,極端情況下訊息投遞要麼丟失或重複。

下面咋們從producer,broker,consumer的角度分析一下kafka中會出現哪些情況:

目前生產者傳送訊息(request.required.acks)有三種方式。

acks = 0: producer不會等待broker傳送ack ,因為傳送訊息網路超時或broker crash(1.partition的leader還沒有commit訊息 2.leader與follower資料不同步),既有可能丟失也可能會重發。

acks = 1: 當leader接收到訊息之後傳送ack,丟會重發,丟的概率很小

acks = -1: 當所有的follower都同步訊息成功後傳送ack.  丟失訊息可能性比較低。

kafka中有兩種consumer介面,分別為low-level api和high-levelapi

(1). low-level api  ******consumer

這套介面比較複雜的,使用者必須要考慮很多事情,優點就是對kafka可以有完全的控制。

(2).  high-level api zookeeperconsumerconnector

high-level api使用比較簡單,已經封裝了對partition和offset的管理,預設是會定期自動commit offset,這樣可能會丟資料的,因為consumer可能拿到資料沒有處理完crash。 high-level api介面的特點,自動管理,使用簡單,但是對kafka的控制不夠靈活。

(1). 對於broker,落盤的資料,除非磁碟壞了,一般不會丟的。總結

kafka只是能保證at-least once訊息語義,即資料是可能重複的,這個在應用上需要可以容忍, 

對於kafka consumer,一般情況下推薦使用high-level api介面,最好不要直接使用low-level api,自己寫起來比較麻煩和困難。

Apache Kafka訊息傳遞可靠性分析

如果mq沒有類似資料庫事務結構和保證,是不可能達到訊息投遞100 可靠的,極端情況下訊息投遞要麼丟失或重複。下面咋們從producer,broker,consumer的角度分析一下kafka中會出現哪些情況 目前生產者傳送訊息 request.required.acks 有三種方式。acks 0 p...

Android訊息傳遞之元件間傳遞訊息

前言 上篇學習總結了android通過handler訊息機制實現了工作執行緒與ui執行緒之間的通訊,今天來學習一下如何實現元件之間的通訊。本文依然是為學習eventbus做鋪墊,有對比才能進步,今天主要介紹在eventbus出現之前的實現方式,通過intent方式這裡不做介紹。需求場景 方式一 通過...

mfc 訊息傳遞

訊息分類 windows的訊息都是以wm 為名,wm 的意思是 windows message mfc把訊息分為三大類 命令訊息 wm command 命令訊息意味著 使用者命令程式做某些操作 凡是ui物件產生的訊息都是這種命令訊息,可能來自選單或加速鍵或工具欄按鈕,並且都以wm command呈現...