如果將 consumer 設定為 autocommit，consumer 一旦讀到資料立即自動 commit。如果只討論這一讀取訊息的過程，那 Kafka 確保了 Exactly once。

但實際使用中應用程式並非在 consumer 讀取完資料就結束了，而是要進行進一步處理，而資料處理與 commit 的順序在很大程度上決定了consumer delivery guarantee：

1.讀完訊息先 commit 再處理訊息。
    這種模式下，如果 consumer 在 commit 後還沒來得及處理訊息就 crash 了，下次重新開始工作後就無法讀到剛剛已提交而未處理的訊息，這就對應於 At most once
2.讀完訊息先處理再 commit。
 

    這種模式下，如果在處理完訊息之後 commit 之前 consumer crash 了，下次重新開始工作時還會處理剛剛未 commit 的訊息，實際上該訊息已經被處理過了。這就對應於 At least once。
3.如果一定要做到 Exactly once，就需要協調 offset 和實際操作的輸出。
    精典的做法是引入兩階段提交。如果能讓 offset 和操作輸入存在同一個地方，會更簡潔和通用。這種方式可能更好，因為許多輸出系統可能不支援兩階段提交。比如，consumer 拿到資料後可能把資料放到 HDFS，
如果把最新的 offset 和資料本身一起寫到 HDFS，那就可以保證資料的輸出和 offset 的更新要麼都完成，要麼都不完成，間接實現 Exactly once。
 
（目前就 high-level API而言，offset 是存於Zookeeper 中的，無法存於HDFS，而SimpleConsuemr API的 offset 是由自己去維護的，可以將之存於 HDFS 中）