反压通常产生于这样的场景：
短时负载高峰导致系统接收数据的速率远高于它处理数据的速率。【大量进线索，负载高峰，导致销售们跟进线索的速率跟不上进线的速率】
许多日常问题都会导致反压，
例如，垃圾回收停顿可能会导致流入的数据快速堆积，或者遇到大促或秒杀活动导致流量陡增。
反压如果不能得到正确的处理，可能会导致资源耗尽甚至系统崩溃。
目前主流的流处理系统 Storm/JStorm/Spark Streaming/Flink 都已经提供了反压机制，不过其实现各不相同。
flink spark storm的反压机制（backpressure） - 阿凡卢 - 博客园
https://www.cnblogs.com/luxiaoxun/p/12987438.html
CRM术语与反压处理设计思想映射：
sale销售就是worker。
capacity私海库容，就是watermark水位线。
上图摘自网络
Flink 原理与实现：如何处理反压问题-阿里云开发者社区
https://developer.aliyun.com/article/64821
如何形象的描述反应式编程中的背压(Backpressure)机制？ - 知乎
https://www.zhihu.com/question/49618581/answer/237078934
分布式工作流系统，【如果】归类为流处理系统的一种。
同样，也面临同样的问题，具体见Camunda公司Zeebe的设计思想：https://new.qq.com/omn/20210324/20210324A0DEG200.html，经典部分摘抄如下：
e. 处理背压(handling back-pressure)
当broker收到客户端请求，会先把请求写到事件流里，然后交由流处理器处理。如果处理太慢或者流里面堆积了太多客户端请求，处理器可能需要花很长时间才能处理新接收到的请求指令。如果broker继续从客户端接收新请求，待处理的任务(back log)会不断增加，任务处理延时会超过可以接收的时间。为了避免这种问题，Zeebe采用了一种背压机制。当broker接收到的请求超过其能在一定延时范围内处理的限度，broker就会拒绝(reject)一些请求。
broker能处理的最大请求速率取决于机器的处理能力、网络延时、系统的当前负载等。因此，Zeebe不会配置固定的最大请求限度。相反的，Zeebe采用自适应的算法动态的决定inflight(broker已经接收但是还没处理完成的)请求数限度。当新的请求被接收时，Inflight请求数增加；当请求处理完成，响应发回给客户端后， Inflight请求数减少。当Inflight请求数达到限度，broker拒绝后续的请求。
如果broker因为背压拒绝了客户端请求，客户端可以用合适的重试策略重试。如果拒绝率一直很高，说明broker持续处于高负载。在这种情况下，推荐降低请求速率。
Dealing with Backpressure with RxJava | Baeldung
https://www.baeldung.com/rxjava-backpressure
Generating backpressure-aware streams with Flowable.generate() - RxJava FAQ
https://nurkiewicz.com/2017/08/generating-backpressure-aware-streams.html
Android flowable背压 取消_使用Flowable.generate（）生成可感知背压的流– RxJava常见问题解答..._最佳 Java 编程-CSDN博客
https://blog.csdn.net/dnc8371/article/details/107259996
背压(Back Pressure)与流量控制 | 三点水
https://lotabout.me/2020/Back-Pressure/
Where does Kafka fit in a reactive architecture? Using Kafka for asynchonous messaging in a reactive system – IBM Developer
https://developer.ibm.com/articles/kafka-fit-reactive-system/#:~:text=Backpressure in Kafka. Kafka can be used as,can use to add backpressure to your consumers.