反向壓力
大家好，我是魚皮，今天分享一個實用的編程小知識 —— 反向壓力。
在介紹反向壓力前，我們先聊聊什么是壓力？
什么是壓力？
我是一個打工人，日常工作就是聽產品經理的話，寫代碼做需求。
正常情況下，我每天能寫 500 行代碼，一周能做完 1 個需求就不錯了。
但如果某天，領導突然發(fā)話了：對手公司已經榮華富貴了，我們也得抓緊，發(fā)財發(fā)財發(fā)財！
于是產品經理收到了更多來自領導的需求，也就給我安排了更多的需求。但我畢竟能力有限，每天只能寫那么幾行代碼，因此只能每天加班苦不堪言，整個人處于超負荷狀態(tài)，感受到了 壓力 。
那把這個場景類比到程序系統中，就是服務調用方對服務提供者的壓力，或者說是請求方對處理方的壓力。每個服務單位時間的處理能力是有限的，一旦請求量過大，服務的壓力就會逐漸增大（可能是內存等資源不斷被占用），嚴重時會導致服務停機。
也可以把整個過程理解為泳池蓄水吧，進水管比排水管的水量更大，那泳池一會兒就水滿溢出了。
了解什么是壓力后，反向壓力就很簡單了。
什么是反向壓力？
先接著做個比喻，假如領導和產品經理要給我增加過多的工作量，那我干嘛要傻傻的默默忍受呢？不是還有其他選擇么？
跟上級們反映一下，工作量太多
實在欺人太甚的話，直接甩下一句話：勞資不干了！
當然，對于領導來說，可能也會給你兩種結果：
傾聽你的反饋，動態(tài)調整你的工作量，先讓你做高優(yōu)先級的需求，其他的排到后面慢慢做。
愛干不干，不干滾蛋！
顯然第一種情況比較好對吧。這便是反向壓力（Back Pressure），又叫 背壓 。
類比到程序系統中，就是根據服務處理方的處理能力和狀態(tài)動態(tài)地調整調用方的請求頻率。
可以是處理方 主動通知 調用方：哦我壓力太大了、活干不完了！然后調用方可以減少請求頻率。
也可以是調用方 被動監(jiān)測 處理方：看見員工開始摸魚了，肯定是工作不飽和！然后調用方可以逐漸增大請求頻率。
反向壓力的好處
反向壓力實際上是 流量控制 的一種解決方案，可以使得調用方和處理方的能力相匹配，從而保護系統的各節(jié)點處于持續(xù)的正常工作狀態(tài)。
如果不使用反向壓力，只能人為去評估系統中各個節(jié)點能承受的壓力，再給每個服務調用者的調用頻率加一個 固定 的限制。限制設小了，就很容易產生資源浪費；限制設大了，服務又可能承受不住，導致掛掉或被剔除。
而且最致命的是，系統中的節(jié)點變化是不可控的，可能現在的系統狀態(tài)很穩(wěn)定，但如果突然多了個服務調用方，就又增加了服務提供者的壓力。而這種壓力沒有被感知到，才是最恐怖的！
因此，如今動態(tài)流控、甚至是智能流控也被應用的越來越廣泛。
反向壓力的應用
有流量控制的需求，就會有反向壓力的身影。
我是從一本 實時流式計算 的書籍中第一次真正了解到反向壓力的概念，這也是它應用最廣泛的領域，像幾個流處理框架 Flink、Spark Streaming、Storm 中，都有相應的反向壓力實現。
反向壓力的概念也被廣泛應用于 反應式編程（Reactive Programming）中，比如 Spring WebFlux、RxJava 框架等，可以實現異步非阻塞、低延遲、高吞吐量的處理系統。
此外，反向壓力的思想也很實用，比如 TCP 網絡協議的流量和擁塞控制中，實際是由發(fā)送方和接收方共同確認數據包滑動窗口的大小，從而控制傳輸包的速率。
因此，反向壓力還是很值得學習的！
至于它如何實現，還是有很大學問的，不同框架的實現方式也不同，大家可以自行了解。（等我學好了再分享哈哈）
以上就是本期分享。
我是魚皮，學到的話還請 點贊 + 在看 支持，這是我持續(xù)更新的最大動力！??
往期推薦