如果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，自己寫起來比較麻煩和困難。
kafka 九 Kafka訊息的可靠性
沒有乙個中介軟體能夠做到百分之百的完全可靠，可靠性更多的還是基於幾個9的衡量指標，比如4個9 5 個9.軟體系統的可靠性只能夠無限去接近100 但不可能達到100 所以kafka如何是實現最大可能的可靠性呢？你可以建立更多的分割槽來提公升可靠性，但是分割槽數過多也會帶來效能上的開銷，一般來說，3個副...
5 Kafka訊息可靠性
在訊息中介軟體裡，有乙個非常重要的問題就是怎麼保證訊息不丟失，而這就是訊息的可靠性問題。1 acks 這個引數用於控制producer生產訊息的永續性。當一條訊息被提交，只要有任何乙個副本儲存了該訊息，並且副本存活，那麼就可以認為該訊息是不可丟失的。當producer傳送一條訊息給kafka集群時，...
Kafka 訊息交付可靠性保障
所謂的訊息交付可靠性保障，是指 kafka 對 producer 和 consumer 要處理的訊息提供什麼樣的承諾。常見的承諾有以下三種 目前，kafka 預設提供的交付可靠性保障是 至少一次。訊息 已提交 的含義為 只有 broker 成功 提交 訊息且 producer 接到 broker 的...