本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# 背壓
<a name="troubleshooting-backpressure"></a>

Flink 使用背壓來調整個別運算子的處理速度。

由於許多原因，運算子可能難以跟上處理收到的訊息量。該操作可能需要比運算子可用資源更多的 CPU 資源，運算子可能會等待 I/O 操作完成。如果運算子無法以足夠快的速度處理事件，它會在饋送給慢速運算子的上游運算子中造成背壓。這會導致上游運算子減慢速度，從而進一步將背壓傳播到來源，並透過減慢速度來使來源適應應用程式的整體輸送量。您可以在 [Apache Flink™ 如何處理背壓](https://www.ververica.com/blog/how-flink-handles-backpressure)中找到有關背壓及其運作方式的更深入說明。

知道應用程式中的哪些運算子速度緩慢，可為您提供重要資訊來了解應用程式效能問題的根本原因。背壓資訊[透過 Flink 控制面板公開](https://nightlies.apache.org/flink/flink-docs-stable/docs/ops/monitoring/back_pressure/)。若要識別慢速運算子，請尋找具有最接近接收器高背壓值的運算子 (以下範例中為運算子 B)。造成緩慢的運算子就是其中一個下游運算子 (範例中的運算子 C)。B 可以更快地處理事件，但由於無法將輸出轉發到實際的慢速運算子 C，因此會受到背壓。

```
A (backpressured 93%) -> B (backpressured 85%) -> C (backpressured 11%) -> D (backpressured 0%)
```

一旦確定慢速運算子，試著了解它為什麼慢。可能有無數的原因，有時出了什麼問題並不明顯，可能需要數天的偵錯和分析來解決。以下是一些明顯和更常見的原因，其中一些進一步解釋如下：
+ 運算子正在執行緩慢的 I/O，例如網路呼叫 (考慮改用 AsyncIO)。
+ 存在資料扭曲，一個運算子接收的事件比其他運算子多，可查看 Flink 儀表板中單個子任務 (即同一運算子的多個執行個體) 的進/出訊息數目進行驗證。
+ 這是一個消耗資源的操作 (如果沒有資料扭曲，請考慮橫向擴展 CPU/記憶體綁定的工作或增加 I/O 綁定工作的 `ParallelismPerKPU`)
+ 運算子中存在大量記錄 (將生產應用程式的記錄減少到最低限度，或者考慮將偵錯輸出發送到資料串流)。

## 使用捨棄接收器測試輸送量
<a name="troubleshooting-testing-throughput"></a>

[丟棄接收器](https://nightlies.apache.org/flink/flink-docs-stable/api/java/org/apache/flink/streaming/api/functions/sink/DiscardingSink.html)只是忽略它在仍在執行應用程式時收到的所有事件 (沒有任何接收器的應用程式無法執行)。這對於輸送量測試、分析以及驗證應用程式是否正確擴展非常有用。這也是一種非常簡潔實用的完整性檢查，可以驗證接收器是否給應用程式導致背壓 (不過直接檢查背壓指標通常更容易和更直接)。

您可以透過用捨棄的接收器取代應用程式的所有接收器，並建立可產生與生產資料類似資料的模擬來源，來衡量應用程式在特定平行處理設定時的最大輸送量。然後，您也可以增加平行處理層級，以驗證應用程式是否正確擴展，並且沒有只在較高輸送量 (例如由於資料扭曲) 時才會出現的瓶頸。