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

下面咋們從producer，broker，consumer的角度分析一下Kafka中會出現哪些情況。

1.Producer傳送訊息到Broker

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

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

acks = 1

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

2.Consumer從Broker拉取訊息

Kafka中有兩種consumer介面，分別為Low-level API和High-levelAPI

(1). Low-level API  SimpleConsumer

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

(2).  High-level API ZookeeperConsumerConnector

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

3. Broker儲存訊息

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

    (2).  對於記憶體髒(沒有flush磁碟)資料，broker重啟會丟。
        可以通過log.flush.interval.messages和log.flush.interval.ms來配置flush間隔，interval大丟的資料多些，小會影響效能。
        但在0.8.x版本以後，可以通過replication機制保證資料不丟，代價就是需要更多資源，尤其是磁碟資源，kafka當前支援GZIP和Snappy壓縮，來緩解這個問題。 
        是否使用replication

總結

Kafka只是能保證at-least once訊息語義，即資料是可能重複的，這個在應用上需要可以容忍。
對於Kafka consumer，一般情況下推薦使用high-level API介面，最好不要直接使用low-level API，自己寫起來比較麻煩和困難。