這個問題要從3個方面來保證數據不丟失：生產者、服務端、消費者。
一.producer 生產端是如何保證數據不丟失的
1.ack的配置策略
acks = all (或-1)
生產者在發(fā)送消息之后，需要等待ISR中所有的副本都成功寫入消息之后才能夠收到來自服務端的成功響應，在配置環(huán)境相同的情況下此種配置可以達到最強的可靠性。
即：在發(fā)送消息時，需要leader 向fllow 同步完數據之后，也就是ISR隊列中所有的broker全部保存完這條消息后，才會向ack發(fā)送消息，表示發(fā)送成功。
2.retries的配置策略
在kafka中錯誤分為2種，一種是可恢復的，另一種是不可恢復的。
可恢復性的錯誤：
如遇到在leader的選舉、網絡的抖動等這些異常時，如果我們在這個時候配置的retries大于0的，也就是可以進行重試操作，那么等到leader選舉完成后、網絡穩(wěn)定后，這些異常就會消息，錯誤也就可以恢復，數據再次重發(fā)時就會正常發(fā)送到broker端。需要注意retries(重試)之間的時間間隔，以確保在重試時可恢復性錯誤都已恢復。
不可恢復性的錯誤：
如：超過了發(fā)送消息的最大值(max.request.size)時，這種錯誤是不可恢復的，如果不做處理，那么數據就會丟失，因此我們需要注意在發(fā)生異常時把這些消息寫入到DB、緩存本地文件中等等，把這些不成功的數據記錄下來，等錯誤修復后，再把這些數據發(fā)送到broker端。
3.如何選取
1.高可用型
- 配置：acks = all，retries > 0 retry.backoff.ms=100(毫秒) (并根據實際情況設置retry可能恢復的間隔時間)
- 優(yōu)點：這樣保證了producer端每發(fā)送一條消息都要成功，如果不成功并將消息緩存起來，等異常恢復后再次發(fā)送。
- 缺點：這樣保證了高可用，但是這會導致集群的吞吐量不是很高，因為數據發(fā)送到broker之后，leader要將數據同步到fllower上，如果網絡帶寬、不穩(wěn)定等情況時，ack響應時間會更長
2.折中型
- 配置：acks = 1 retries > 0 retries 時間間隔設置 (并根據實際情況設置retries可能恢復的間隔時間)
- 優(yōu)點：保證了消息的可靠性和吞吐量，是個折中的方案
- 缺點：性能處于2者中間
3.高吞吐型
- 配置：acks = 0
- 優(yōu)點：可以相對容忍一些數據的丟失，吞吐量大，可以接收大量請求
- 缺點：不知道發(fā)送的消息是 否成功
二.broker端是如何保證數據不丟失的
unclean.leader.election.enable=false
設置為 false（默認參數為 true），意思是，當存有你最新一條記錄的 replication 宕機的時候，Kafka 自己會選舉出一個主節(jié)點，如果默認允許還未同步你最新數據的 replication 所在的節(jié)點被選舉為主節(jié)點的話，你的數據將會丟失，因此這里應該按需將參數調控為 false；
三.consumer端是如何保證數據不丟失的
在consumer消費階段，對offset的處理，關系到是否丟失數據，是否重復消費數據，因此，我們把處理好offset就可以做到exactly-once && at-least-once(只消費一次)數據。
當enable.auto.commit=true時
表示由kafka的consumer端自動提交offset,當你在pull(拉取)30條數據，在處理到第20條時自動提交了offset,但是在處理21條的時候出現了異常，當你再次pull數據時，由于之前是自動提交的offset，所以是從30條之后開始拉取數據，這也就意味著21-30條的數據發(fā)生了丟失。
當enable.auto.commit=false時
由于上面的情況可知自動提交offset時，如果處理數據失敗就會發(fā)生數據丟失的情況。那我們設置成手動提交。
當設置成false時，由于是手動提交的，可以處理一條提交一條，也可以處理一批，提交一批，由于consumer在消費數據時是按一個batch來的，當pull了30條數據時，如果我們處理一條，提交一個offset，這樣會嚴重影響消費的能力，那就需要我們來按一批來處理，或者設置一個累加器，處理一條加1，如果在處理數據時發(fā)生了異常，那就把當前處理失敗的offset進行提交(放在finally代碼塊中)注意一定要確保offset的正確性，當下次再次消費的時候就可以從提交的offset處進行再次消費。
