流處理系統需要能優雅地處理反壓（backpressure）問題。反壓通常産生于這樣的場景：短時負載高峰導緻系統接收資料的速率遠高于它處理資料的速率。許多日常問題都會導緻反壓，例如，垃圾回收停頓可能會導緻流入的資料快速堆積，或者遇到大促或秒殺活動導緻流量陡增。反壓如果不能得到正确的處理，可能會導緻資源耗盡甚至系統崩潰。
目前主流的流處理系統 storm/jstorm/spark streaming/flink 都已經提供了反壓機制，不過其實作各不相同。
jstorm 認為直接停止 spout 的發送太過暴力，存在大量問題。當下遊出現阻塞時，上遊停止發送，下遊消除阻塞後，上遊又開閘放水，過了一會兒，下遊又阻塞，上遊又限流，如此反複，整個資料流會一直處在一個颠簸狀态。是以 jstorm 是通過逐級降速來進行反壓的，效果會較 storm 更為穩定，但算法也更複雜。另外 jstorm 沒有引入 zookeeper 而是通過 topologymaster 來協調拓撲進入反壓狀态，這降低了 zookeeper 的負載。
那麼 flink 是怎麼處理反壓的呢？答案非常簡單：flink 沒有使用任何複雜的機制來解決反壓問題，因為根本不需要那樣的方案！它利用自身作為純資料流引擎的優勢來優雅地響應反壓問題。下面我們會深入分析 flink 是如何在 task 之間傳輸資料的，以及資料流如何實作自然降速的。
flink 在運作時主要由 operators 和 streams 兩大元件構成。每個 operator 會消費中間态的流，并在流上進行轉換，然後生成新的流。對于 flink 的網絡機制一種形象的類比是，flink 使用了高效有界的分布式阻塞隊列，就像 java 通用的阻塞隊列（blockingqueue）一樣。還記得經典的線程間通信案例：生産者消費者模型嗎？使用 blockingqueue 的話，一個較慢的接受者會降低發送者的發送速率，因為一旦隊列滿了（有界隊列）發送者會被阻塞。flink 解決反壓的方案就是這種感覺。
在 flink 中，這些分布式阻塞隊列就是這些邏輯流，而隊列容量是通過緩沖池來（<code>localbufferpool</code>）實作的。每個被生産和被消費的流都會被配置設定一個緩沖池。緩沖池管理着一組緩沖(<code>buffer</code>)，緩沖在被消費後可以被回收循環利用。這很好了解：你從池子中拿走一個緩沖，填上資料，在資料消費完之後，又把緩沖還給池子，之後你可以再次使用它。
在解釋 flink 的反壓原理之前，我們必須先對 flink 中網絡傳輸的記憶體管理有個了解。
如下圖所示展示了 flink 在網絡傳輸場景下的記憶體管理。網絡上傳輸的資料會寫到 task 的 inputgate（ig） 中，經過 task 的處理後，再由 task 寫到 resultpartition（rs） 中。每個 task 都包括了輸入和輸入，輸入和輸出的資料存在 <code>buffer</code> 中（都是位元組資料）。buffer 是 memorysegment 的包裝類。
task 線程啟動時，會向 networkenvironment 注冊，networkenvironment 會為 task 的 inputgate（ig）和 resultpartition（rp） 分别建立一個 localbufferpool（緩沖池）并設定可申請的 memorysegment（記憶體塊）數量。ig 對應的緩沖池初始的記憶體塊數量與 ig 中 inputchannel 數量一緻，rp 對應的緩沖池初始的記憶體塊數量與 rp 中的 resultsubpartition 數量一緻。不過，每當建立或銷毀緩沖池時，networkbufferpool 會計算剩餘空閑的記憶體塊數量，并平均配置設定給已建立的緩沖池。注意，這個過程隻是指定了緩沖池所能使用的記憶體塊數量，并沒有真正配置設定記憶體塊，隻有當需要時才配置設定。為什麼要動态地為緩沖池擴容呢？因為記憶體越多，意味着系統可以更輕松地應對瞬時壓力（如gc），不會頻繁地進入反壓狀态，是以我們要利用起那部分閑置的記憶體塊。
在 task 線程執行過程中，當 netty 接收端收到資料時，為了将 netty 中的資料拷貝到 task 中，inputchannel（實際是 remoteinputchannel）會向其對應的緩沖池申請記憶體塊（上圖中的①）。如果緩沖池中也沒有可用的記憶體塊且已申請的數量還沒到池子上限，則會向 networkbufferpool 申請記憶體塊（上圖中的②）并交給 inputchannel 填上資料（上圖中的③和④）。如果緩沖池已申請的數量達到上限了呢？或者 networkbufferpool 也沒有可用記憶體塊了呢？這時候，task 的 netty channel 會暫停讀取，上遊的發送端會立即響應停止發送，拓撲會進入反壓狀态。當 task 線程寫資料到 resultpartition 時，也會向緩沖池請求記憶體塊，如果沒有可用記憶體塊時，會阻塞在請求記憶體塊的地方，達到暫停寫入的目的。
當一個記憶體塊被消費完成之後（在輸入端是指記憶體塊中的位元組被反序列化成對象了，在輸出端是指記憶體塊中的位元組寫入到 netty channel 了），會調用 <code>buffer.recycle()</code> 方法，會将記憶體塊還給 localbufferpool （上圖中的⑤）。如果localbufferpool中目前申請的數量超過了池子容量（由于上文提到的動态容量，由于新注冊的 task 導緻該池子容量變小），則localbufferpool會将該記憶體塊回收給 networkbufferpool（上圖中的⑥）。如果沒超過池子容量，則會繼續留在池子中，減少反複申請的開銷。
下面這張圖簡單展示了兩個 task 之間的資料傳輸以及 flink 如何感覺到反壓的：
記錄“a”進入了 flink 并且被 task 1 處理。（這裡省略了 netty 接收、反序列化等過程）
記錄被序列化到 buffer 中。
該 buffer 被發送到 task 2，然後 task 2 從這個 buffer 中讀出記錄。
不要忘了：記錄能被 flink 處理的前提是，必須有空閑可用的 buffer。
結合上面兩張圖看：task 1 在輸出端有一個相關聯的 localbufferpool（稱緩沖池1），task 2 在輸入端也有一個相關聯的 localbufferpool（稱緩沖池2）。如果緩沖池1中有空閑可用的 buffer 來序列化記錄 “a”，我們就序列化并發送該 buffer。
這裡我們需要注意兩個場景：
本地傳輸：如果 task 1 和 task 2 運作在同一個 worker 節點（taskmanager），該 buffer 可以直接交給下一個 task。一旦 task 2 消費了該 buffer，則該 buffer 會被緩沖池1回收。如果 task 2 的速度比 1 慢，那麼 buffer 回收的速度就會趕不上 task 1 取 buffer 的速度，導緻緩沖池1無可用的 buffer，task 1 等待在可用的 buffer 上。最終形成 task 1 的降速。
遠端傳輸：如果 task 1 和 task 2 運作在不同的 worker 節點上，那麼 buffer 會在發送到網絡（tcp channel）後被回收。在接收端，會從 localbufferpool 中申請 buffer，然後拷貝網絡中的資料到 buffer 中。如果沒有可用的 buffer，會停止從 tcp 連接配接中讀取資料。在輸出端，通過 netty 的水位值機制來保證不往網絡中寫入太多資料（後面會說）。如果網絡中的資料（netty輸出緩沖中的位元組數）超過了高水位值，我們會等到其降到低水位值以下才繼續寫入資料。這保證了網絡中不會有太多的資料。如果接收端停止消費網絡中的資料（由于接收端緩沖池沒有可用 buffer），網絡中的緩沖資料就會堆積，那麼發送端也會暫停發送。另外，這會使得發送端的緩沖池得不到回收，writer 阻塞在向 localbufferpool 請求 buffer，阻塞了 writer 往 resultsubpartition 寫資料。
這種固定大小緩沖池就像阻塞隊列一樣，保證了 flink 有一套健壯的反壓機制，使得 task 生産資料的速度不會快于消費的速度。我們上面描述的這個方案可以從兩個 task 之間的資料傳輸自然地擴充到更複雜的 pipeline 中，保證反壓機制可以擴散到整個 pipeline。
下方的代碼是初始化 nettyserver 時配置的水位值參數。
當輸出緩沖中的位元組數超過了高水位值, 則 channel.iswritable() 會傳回false。當輸出緩存中的位元組數又掉到了低水位值以下, 則 channel.iswritable() 會重新傳回true。flink 中發送資料的核心代碼在 <code>partitionrequestqueue</code> 中，該類是 server channel pipeline 的最後一層。發送資料關鍵代碼如下所示。
核心發送方法中如果channel不可寫，則會跳過發送。當channel再次可寫後，netty 會調用該handle的 <code>channelwritabilitychanged</code> 方法，進而重新觸發發送函數。
首先，我們運作生産task到它最大生産速度的60%（我們通過thread.sleep()來模拟降速）。消費者以同樣的速度處理資料。然後，我們将消費task的速度降至其最高速度的30%。你就會看到背壓問題産生了，正如我們所見，生産者的速度也自然降至其最高速度的30%。接着，停止消費task的人為降速，之後生産者和消費者task都達到了其最大的吞吐。接下來，我們再次将消費者的速度降至30%，pipeline給出了立即響應：生産者的速度也被自動降至30%。最後，我們再次停止限速，兩個task也再次恢複100%的速度。總而言之，我們可以看到：生産者和消費者在 pipeline 中的處理都在跟随彼此的吞吐而進行适當的調整，這就是我們希望看到的反壓的效果。
在 storm/jstorm 中，隻要監控到隊列滿了，就可以記錄下拓撲進入反壓了。但是 flink 的反壓太過于天然了，導緻我們無法簡單地通過監控隊列來監控反壓狀态。flink 在這裡使用了一個 trick 來實作對反壓的監控。如果一個 task 因為反壓而降速了，那麼它會卡在向 <code>localbufferpool</code> 申請記憶體塊上。那麼這時候，該 task 的 stack trace 就會長下面這樣：
那麼事情就簡單了。通過不斷地采樣每個 task 的 stack trace 就可以實作反壓監控。
flink 的實作中，隻有當 web 頁面切換到某個 job 的 backpressure 頁面，才會對這個 job 觸發反壓檢測，因為反壓檢測還是挺昂貴的。jobmanager 會通過 akka 給每個 taskmanager 發送<code>triggerstacktracesample</code>消息。預設情況下，taskmanager 會觸發100次 stack trace 采樣，每次間隔 50ms（也就是說一次反壓檢測至少要等待5秒鐘）。并将這 100 次采樣的結果傳回給 jobmanager，由 jobmanager 來計算反壓比率（反壓出現的次數/采樣的次數），最終展現在 ui 上。ui 重新整理的預設周期是一分鐘，目的是不對 taskmanager 造成太大的負擔。
flink 不需要一種特殊的機制來處理反壓，因為 flink 中的資料傳輸相當于已經提供了應對反壓的機制。是以，flink 所能獲得的最大吞吐量由其 pipeline 中最慢的元件決定。相對于 storm/jstorm 的實作，flink 的實作更為簡潔優雅，源碼中也看不見與反壓相關的代碼，無需 zookeeper/topologymaster 的參與也降低了系統的負載，也利于對反壓更迅速的響應。
<a href="http://data-artisans.com/how-flink-handles-backpressure/">how flink handles backpressure</a>
<a href="https://ci.apache.org/projects/flink/flink-docs-master/internals/back_pressure_monitoring.html">flink: back pressure monitoring</a>