消息可靠性的保證基本上我們都要從3個方面來闡述（這樣才比較全面，無懈可擊）
1 生產者發送消息丟失
kafka支持3種方式發送消息，這也是常規的3種方式，發送后不管結果、同步發送、異步發送，基本上所有的消息隊列都是這樣玩的。
發送並忘記，直接調用發送send方法，不管結果，雖然可以開啟自動重試，但是肯定會有消息丟失的可能
同步發送，同步發送返回Future對象，我們可以知道發送結果，然后進行處理
異步發送，發送消息，同時指定一個回調函數，根據結果進行相應的處理
為了保險起見，一般我們都會使用異步發送帶有回調的方式進行發送消息，再設置參數為發送消息失敗不停地重試。
acks=all，這個參數有可以配置0|1|all。
0表示生產者寫入消息不管服務器的響應，可能消息還在網絡緩沖區，服務器根本沒有收到消息，當然會丟失消息。
1表示至少有一個副本收到消息才認為成功，一個副本那肯定就是集群的Leader副本了，但是如果剛好Leader副本所在的節點掛了，Follower沒有同步這條消息，消息仍然丟失了。
配置all的話表示所有ISR都寫入成功才算成功，那除非所有ISR里的副本全掛了，消息才會丟失。
retries=N，設置一個非常大的值，可以讓生產者發送消息失敗后不停重試
2 kafka broker 自身消息丟失
kafka因為消息寫入是通過PageCache異步寫入磁盤的，因此仍然存在丟失消息的可能。
因此針對kafka自身丟失的可能設置參數：
replication.factor=N，設置一個比較大的值，保證至少有2個或者以上的副本。
min.insync.replicas=N，代表消息如何才能被認為是寫入成功，設置大於1的數，保證至少寫入1個或者以上的副本才算寫入消息成功。
unclean.leader.election.enable=false，這個設置意味着沒有完全同步的分區副本不能成為Leader副本，如果是true的話，那些沒有完全同步Leader的副本成為Leader之后，就會有消息丟失的風險。
3 消費者消息丟失
消費者丟失的可能就比較簡單，關閉自動提交位移即可，改為業務處理成功手動提交。
因為重平衡發生的時候，消費者會去讀取上一次提交的偏移量，自動提交默認是每5秒一次，這會導致重復消費或者丟失消息。
enable.auto.commit=false，設置為手動提交。
還有一個參數我們可能也需要考慮進去的：
auto.offset.reset=earliest，這個參數代表沒有偏移量可以提交或者broker上不存在偏移量的時候，消費者如何處理。earliest代表從分區的開始位置讀取，可能會重復讀取消息，但是不會丟失，消費方一般我們肯定要自己保證冪等，另外一種latest表示從分區末尾讀取，那就會有概率丟失消息。
綜合這幾個參數設置，我們就能保證消息不會丟失，保證了可靠性。