Producer發送數據丟失、重復、亂序原因及解決方案是什么

這篇文章給大家介紹Producer發送數據丟失、重復、亂序原因及解決方案是什么，內容非常詳細，感興趣的小伙伴們可以參考借鑒，希望對大家能有所幫助。

    生產環境對于生產者來說，Kafka集群發送消息經常會遇到消息丟失、重復、亂序等問題，下面我們來講解一下出現這些問題的原因及解決方案。

1.我們知道Kafka為保障數據的可靠性，采用了多副本的存儲機制

    假設一個Topic拆分為了3個Partition，分別是PartitionA，PartitonB，PartitionC，此時每個Partition都有2個副本。比如PartitionA有一個副本是leader，另外一個副本是follower，leader和follower兩個副本是分布在不同機器上的。

    一般生產環境我們都會指定Topic的數據有3個副本，即使一臺broker掛掉以后，數據也不會徹底丟失，因為其他broker還存在另外的副本數據。

2.副本數據是如何進行同步的呢？

    對于多個副本的topic來說，只有分區leader提供讀寫服務的，follower只是不停的嘗試從leader拉取最新的數據到本地，不提供讀寫服務，跟leader數據保持同步的數據有哪些呢？就是通過ISRl來管理的。

    ISR全稱是“In-Sync Replicas”,就是能跟首領副本基本保持一致的跟隨副本，如果同步的速度太慢的話，就會被踢出ISR副本。

3.說一下Kafka的Producer端消息傳遞語義，由參數"acks"控制，分三種：

a.acks=all

    意味著當Producer發送消息時，leader接收到消息之后，還必須要求ISR列表里跟leader保持同步的那些follower都要把消息同步過去，才能認為這條消息是寫入成功了,這種效率最低，但是可靠性最高。

b.acks=1：

    意味著當Producer發送消息時，leader接收到消息而且寫入本地磁盤了，就認為成功了，不管他其他的follower有沒有同步過去這條消息了,acks默認值為1。

c.acks=0：

    意味著當Producer發送消息時，producer發送一次就不再發送了，不管是否發送成功,這種情況下沒有任何的確認，可能存在消息的丟失；這種效率最高，但是可靠性最低。

4.Producer端引起數據丟失、重復、亂序的原因及解決方案

1).Producer發送數據分為同步、異步兩種模式，由參數producer.type控制，一般生產采用異步模式批量發送，提高Kafka系統的吞吐率。

a同步模式 producer.type = sync：

    當acks=0，不進行消息接收的確認，那么當網絡異常時，就會造成數據丟失，一般生產不建議設置為0；

    當acks=1，在只有leader接收成功并發送ack確認后，leader宕機，副本沒有同步完成，也會造成數據丟失；

    上面兩種數據丟失，我們可以設置acks=all，保證produce 寫入所有副本算成功,效率比較低。

 producer.type = sync  request.required.acks=all

?

b.異步模式 producer.type = async：

    異步模式下的有個buffer，通過buffer來進行控制數據的發送，有兩個值來進行控制，時間閾值與消息的數量閾值，如果buffer滿了數據還沒有發送出去，如果設置的是立即清理模式，風險很大，容易造成數據丟失。一般設置為阻塞模式：queue.enqueue.timeout.ms = -1表示后臺消息queue積壓到上限后將一直阻塞,直到queue空間釋放；

producer.type = asyncrequest.required.acks=1queue.buffering.max.ms=6000queue.buffering.max.messages=10000queue.enqueue.timeout.ms = -1batch.num.messages=500

3).acks = all時，數據發送到 leader 后 ，數據發送到 leader 后 ，部分 ISR 的副本同步，leader 此時掛掉。比如 follower1 和 follower2 都有可能變成新的 leader, producer 端會得到返回異常，producer 端會重新發送數據，可能會造成數據重復,這種可通過冪等性和事務解決，后續會講；

4).acks=all時，當isr列表為空，如果unclean.leader.election.enable為true，則會選擇其他存活的副本作為新的leader，也會存在消息丟失的問題

可通過設置參數：

unclean.leader.election.enable=false

    這個參數在0.11.0之前其默認值為true，而之后的版本其默認值為false。意思是，在leader選舉時是否在沒有活著的ISR副本時從OSR中的最早follower選舉，如果為true可能會造成數據的丟失；

5).異步發送消息時,有兩條數據數據準備發送到相同的Partition,第一條消息寫入失敗,第二條消息寫入失敗,經過重試后第一批次寫入成功,這時就會造成發送數據的亂序，這種情況我們可以通過設置參數進行限制:

參數：max.in.flight.requests.per.connection

    表示請求隊列大小，默認5，請求隊列中存放的是在發送途中的請求，包括：正在發送的請求和已經發送的但還沒有接收到response的請求;請求隊列滿了，發送消息將會發生阻塞。也就是發往同一個node的最大未響應請求。設置此值是1，表示kafka broker在響應請求之前client不能再向同一個broker發送請求，這樣便可以避免消息亂序。

    通過4的分析發現kafka在兩端的默認配置都是at least once，可能重復，通過配置也不能做到exactly once，好像kafka的消息一定會丟失或者重復，在kafka 0.11.0.0版本之后，開始引入了冪等性和事務機制來解決上述問題。

擴充知識點：

1.Kafka發送數據過快，導致服務器網卡流量暴增。或磁盤過忙，出現丟包，造成。這時候我們采取以下措施：

     a.首先，對kafka進行限速；

     b.其次啟用重試機制，使重試間隔變長；

     c.Kafka設置ack=all,即需要處于ISR（副本列表）的分區都確認，才算發送成功。

關于Producer發送數據丟失、重復、亂序原因及解決方案是什么就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。