所謂的背壓就是反壓(backpressure)

什么是背壓?jiǎn)栴}

流系統(tǒng)中消息的處理速度跟不上消息的發(fā)送速度，導(dǎo)致消息的堆積。如果系統(tǒng)能感知消息堆積，并調(diào)整消息發(fā)送的速度。 使消息的處理速度和發(fā)送速度相協(xié)調(diào)就是有背壓感知的系統(tǒng)。背壓如果不能得到正確地處理，可能會(huì)導(dǎo)致資源被耗盡或者 甚至出現(xiàn)更糟的情況導(dǎo)致數(shù)據(jù)丟失。flink就是一個(gè)有背壓感知的基于流的分布式消息處理系統(tǒng)。?

舉例說(shuō)明： 1.正常情況：消息處理速度>=消息的發(fā)送速度，不發(fā)生消息擁堵，系統(tǒng)運(yùn)行流暢?

?

?2.異常情況：消息處理速度< 消息的發(fā)送速度，發(fā)生了消息擁堵，系統(tǒng)運(yùn)行不暢。?

?消息擁堵可以采取兩種方案 a.將擁堵的消息直接刪除，將會(huì)導(dǎo)致數(shù)據(jù)丟失，在精確到要求高的場(chǎng)景非常不合適 b.將擁堵的消息緩存起來(lái)，并告知消息發(fā)送者減緩消息發(fā)送的速度。 3.處理方法：將緩沖區(qū)持久化，以方便在處理失敗的情況下進(jìn)行數(shù)據(jù)重放。 有些source本身提供持久化保證，可以優(yōu)先考慮。例如： Apache Kafka是一個(gè)很不錯(cuò)的選擇，可以背壓從sink到source 的整個(gè)pipeline,同時(shí)對(duì)source進(jìn)行限流來(lái)適配整個(gè)pipeline中最慢組件的速度，從而獲得系統(tǒng)的穩(wěn)定狀態(tài)。?

flink中的背壓

Flink使用分布式阻塞隊(duì)列來(lái)作為有界緩沖區(qū)。如同Java里通用的阻塞隊(duì)列跟處理線程進(jìn)行連接一樣，一旦隊(duì)列達(dá)到容量上限， 一個(gè)相對(duì)較慢的接受者將拖慢發(fā)送者。 舉例說(shuō)明: 圖中有一個(gè)簡(jiǎn)單的flow，它由兩個(gè)task組成?

?

1、記錄“A”進(jìn)入Flink，然后被Task 1處理

2、Task 1處理后的結(jié)果被序列化進(jìn)緩沖區(qū)

3、task 2從緩沖區(qū)內(nèi)讀取一些數(shù)據(jù)，緩沖區(qū)內(nèi)將有更多的空間。

4、如果task 2處理的較慢，task1的緩存區(qū)將很快填滿。發(fā)送速度隨之下降。 注意：為了記錄能被Flink處理，緩沖區(qū)必須是可用的

flink背壓的兩種場(chǎng)景

1.本地傳輸?

?如果task1和task2都運(yùn)行在同一個(gè)工作節(jié)點(diǎn)（TaskManager），緩沖區(qū)可以被直接共享給下一個(gè)task，一旦task 2消費(fèi)了數(shù)據(jù)它會(huì) 被回收。如果task 2比task 1慢，buffer會(huì)以比task 1填充的速度更慢的速度進(jìn)行回收從而迫使task降速。

2.網(wǎng)絡(luò)傳輸?

如果task 1和task 2運(yùn)行在不同的工作節(jié)點(diǎn)上。一旦緩沖區(qū)內(nèi)的數(shù)據(jù)被發(fā)送出去(TCP Channel)，它就會(huì)被回收。在接收端，數(shù)據(jù)被 拷貝到輸入緩沖池的緩沖區(qū)中，如果沒(méi)有緩沖區(qū)可用，從TCP連接中的數(shù)據(jù)讀取動(dòng)作將會(huì)被中斷。輸出端通常以watermark機(jī)制來(lái)保證不 會(huì)有太多的數(shù)據(jù)在傳輸途中。如果有足夠的數(shù)據(jù)已經(jīng)進(jìn)入可發(fā)送狀態(tài)，會(huì)等到情況穩(wěn)定到閾值以下才會(huì)進(jìn)行發(fā)送。這可以保證沒(méi)有太多的 數(shù)據(jù)在路上。如果新的數(shù)據(jù)在消費(fèi)端沒(méi)有被消費(fèi)（因?yàn)闆](méi)有可用的緩沖區(qū)），這種情況會(huì)降低發(fā)送者發(fā)送數(shù)據(jù)的速度。

flink背壓的性能測(cè)試

下面這張圖顯示了：隨著時(shí)間的改變，生產(chǎn)者（黃色線）和消費(fèi)者（綠色線）基于所達(dá)到的最大吞吐（在單一JVM中每秒達(dá)到8百萬(wàn)條記錄） 的平均吞吐百分比。我們通過(guò)衡量task每5秒鐘處理的記錄數(shù)來(lái)衡量平均吞吐。?

首先，我們運(yùn)行生產(chǎn)者task到它最大生產(chǎn)速度的60%（我們通過(guò)Thread.sleep()來(lái)模擬降速）。消費(fèi)者以同樣的速度處理數(shù)據(jù)。 然后，我們將消費(fèi)task的速度降至其最高速度的30%。你就會(huì)看到背壓?jiǎn)栴}產(chǎn)生了，正如我們所見(jiàn)，生產(chǎn)者的速度也自然降至其最高速度的30%。

接著，我們對(duì)消費(fèi)者停止人為降速，之后生產(chǎn)者和消費(fèi)者task都達(dá)到了其最大的吞吐。接下來(lái)，我們?cè)俅螌⑾M(fèi)者的速度降至30%，pipeline給出了立即響應(yīng)：生產(chǎn)者的速度也被自動(dòng)降至30%。

最后，我們?cè)俅瓮Ｖ瓜匏?#xff0c;兩個(gè)task也再次恢復(fù)100%的速度。這所有的跡象表明：生產(chǎn)者和消費(fèi)者在pipeline中的處理都在跟隨彼此的吞吐而進(jìn)行適當(dāng)?shù)恼{(diào)整，這就是我們?cè)诹鱬ipeline中描述的行為。

flink背壓的總結(jié)

Flink與持久化的source（例如kafka），能夠?yàn)槟闾峁┘磿r(shí)的背壓處理，而無(wú)需擔(dān)心數(shù)據(jù)丟失。Flink不需要一個(gè)特殊的機(jī)制來(lái)處理背壓， 因?yàn)镕link中的數(shù)據(jù)傳輸相當(dāng)于已經(jīng)提供了應(yīng)對(duì)背壓的機(jī)制。因此，Flink所獲得的最大吞吐量由其pipeline中最慢的部件決定。

?

上述內(nèi)容轉(zhuǎn)載自[1]，扯白了就是Flink自帶的隊(duì)列扛不住了。

Reference:

[0]《flink中的背壓的處理原理》

[1]Flink如何應(yīng)對(duì)背壓?jiǎn)栴}

[2]How Apache Flink? handles backpressure

[3]flink的背壓?jiǎn)栴}產(chǎn)生原因和解決方法

[4]Flink 背壓?jiǎn)栴}排查的梳理

[5]Flink ：網(wǎng)絡(luò)流控及反壓剖析

?

?

總結(jié)

以上是生活随笔為你收集整理的flink背压问题处理(还没弄完)的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。