反壓通常產生於這樣的場景：

短時負載高峰導致系統接收資料的速率遠高於它處理資料的速率。【大量進線索，負載高峰，導致銷售們跟進線索的速率跟不上進線的速率】

許多日常問題都會導致反壓，

例如，垃圾回收停頓可能會導致流入的資料快速堆積，或者遇到大促或秒殺活動導致流量陡增。

反壓如果不能得到正確的處理，可能會導致資源耗盡甚至系統崩潰。

目前主流的流處理系統 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.