事实上，Sink可能是程序中的限制因素，也是造成背压的因素。
我使用的是Flink 1.10，我有一个简单的Flink应用程序
- 从Kafka读取数据
- 过程数据(简单的一对一映射(
- 接收器到DB
当我查看UI上的背压状态时，它显示：
Operator BackPresure
Source High
Map High
Sink OK
我想问，鉴于上述背压状态，哪个部分是瓶颈？我认为sink操作符是写DB的瓶颈，但我不明白为什么它的BackPresure状态是OK
在1.13/1.14中，他们更改了术语：Backpressure UI进行了改进；他们没有为操作员谈论"背压"，而是将其称为"背压d"或其"背压状态"。
在您的情况下，接收器不会反向加压(根据定义，任何接收器都不可能反向加压(，但Source和Map操作符会反向加压。
除了背压(以输出缓冲器的可用性衡量(之外，新版本还增加了空闲(由是否有可用的输入确定(的新概念。这将有助于IMHO确定是网络IO还是CPU是程序的限制因素。
以下是它的样子：
https://ci.apache.org/projects/flink/flink-docs-master/docs/ops/monitoring/back_pressure/