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

創(chuàng)新互聯(lián)公司聯(lián)系電話：18980820575，為您提供成都網(wǎng)站建設網(wǎng)頁設計及定制高端網(wǎng)站建設服務，創(chuàng)新互聯(lián)公司網(wǎng)頁制作領域十年，包括服務器租用等多個行業(yè)擁有多年的網(wǎng)站制作經(jīng)驗，選擇創(chuàng)新互聯(lián)公司，為企業(yè)保駕護航。

    生產(chǎn)環(huán)境對于生產(chǎn)者來說，Kafka集群發(fā)送消息經(jīng)常會遇到消息丟失、重復、亂序等問題，下面我們來講解一下出現(xiàn)這些問題的原因及解決方案。

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

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

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

2.副本數(shù)據(jù)是如何進行同步的呢？

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

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

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

a.acks=all

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

b.acks=1：

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

c.acks=0：

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

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

1).Producer發(fā)送數(shù)據(jù)分為同步、異步兩種模式，由參數(shù)producer.type控制，一般生產(chǎn)采用異步模式批量發(fā)送，提高Kafka系統(tǒng)的吞吐率。

a同步模式 producer.type = sync：

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

    當acks=1，在只有l(wèi)eader接收成功并發(fā)送ack確認后，leader宕機，副本沒有同步完成，也會造成數(shù)據(jù)丟失；

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

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

?

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

    異步模式下的有個buffer，通過buffer來進行控制數(shù)據(jù)的發(fā)送，有兩個值來進行控制，時間閾值與消息的數(shù)量閾值，如果buffer滿了數(shù)據(jù)還沒有發(fā)送出去，如果設置的是立即清理模式，風險很大，容易造成數(shù)據(jù)丟失。一般設置為阻塞模式：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時，數(shù)據(jù)發(fā)送到 leader 后 ，數(shù)據(jù)發(fā)送到 leader 后 ，部分 ISR 的副本同步，leader 此時掛掉。比如 follower1 和 follower2 都有可能變成新的 leader, producer 端會得到返回異常，producer 端會重新發(fā)送數(shù)據(jù)，可能會造成數(shù)據(jù)重復,這種可通過冪等性和事務解決，后續(xù)會講；

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

可通過設置參數(shù)：

unclean.leader.election.enable=false

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

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

參數(shù)：max.in.flight.requests.per.connection

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

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

擴充知識點：

1.Kafka發(fā)送數(shù)據(jù)過快，導致服務器網(wǎng)卡流量暴增?；虼疟P過忙，出現(xiàn)丟包，造成。這時候我們采取以下措施：

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

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

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

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

分享標題：Producer發(fā)送數(shù)據(jù)丟失、重復、亂序原因及解決方案是什么
文章網(wǎng)址：http://jinyejixie.com/article4/ppieoe.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站建設、微信小程序、虛擬主機、網(wǎng)頁設計公司、網(wǎng)站排名、網(wǎng)站內(nèi)鏈

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)