如果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呈現...