背景
限流控制，又稱 反壓 （backpressure）， 這個概念現在在大數據中非常火爆， 尤其是最近Heron/Spark都實現了這個功能。其實在jstorm 0.9.0 時，底層netty的同步模式，即可做到限流控制， 即當接收端能處理多少tuple， 發送端才能發送多少tuple， 但隨着大面積使用， 發現netty的同步模式會存在死鎖問題， 故這種方式並沒有被大量使用。
原理
後來自2015年6月，twitter發佈了heron的一篇論文， 描敘了，當下遊處理速度跟不上上游發送速度時， 他們採取了一種暴力手段，立即停止spout的發送。 這種方式， jstorm拿過來進行壓測， 發現存在大量問題， 當下游出現阻塞時， 上游停止發送， 下游消除阻塞後，上游又開閘放水，過了一會兒，下游又阻塞，上游又限流， 如此反覆， 整個數據流一直處在一個顛簸狀態。
真正合適的狀態時， 上游降速到一個特定的值後， 下游的處理速度剛剛跟上上游的速度
什麼樣才能觸發反壓
jstorm的限流機制， 當下遊bolt發生阻塞時， 並且阻塞task的比例超過某個比例時（現在默認設置爲0.1）， 即假設一個component有100個併發，當這個component 超過10個task 發生阻塞時，纔會觸發啓動反壓限流
什麼樣的情況才能判斷是阻塞
在jstorm 連續4次採樣週期中採樣，隊列情況，當隊列超過80%（可以設置）時，即可認爲該task處在阻塞狀態
觸發誰限流
根據阻塞component，進行DAG 向上推算，直到推算到他的源頭spout， 並將topology的一個狀態位，設置爲 “限流狀態”
怎麼限流
當task出現阻塞時，他會將自己的執行線程的執行時間， 傳給topology master， 當觸發阻塞後， topology master會把這個執行時間傳給spout， 於是， spout每發送一個tuple，就會等待這個執行時間。storm 社區的人想通過動態調整max_pending達到這種效果，其實這種做法根本無效。
怎樣解除限流
當spout降速後， 發送過阻塞命令的task 檢查隊列水位連續4次低於0.05時， 發送解除反應命令到topology master， topology master 發送提速命令給所有的spout， 於是spout 每發送一個tuple的等待時間－－， 當spout的等待時間降爲0時， spout會不斷髮送“解除限速”命令給 topology master， 而topology master確定所有的降速的spout都發瞭解除限速命令時， 將topology狀態設置爲正常，標誌真正解除限速
如何使用
反壓總開關
topology.backpressure.enable: true高水位 －－ 當隊列使用量超過這個值時，認爲阻塞
topology.backpressure.water.mark.high: 0.8低水位 －－ 當隊列使用量低於這個量時， 認爲可以解除阻塞
topology.backpressure.water.mark.low: 0.05阻塞比例 －－ 當阻塞task數／這個component併發 的比例高於這值時，觸發反壓
topology.backpressure.coordinator.trigger.ratio: 0.1反壓採樣週期， 單位ms
topology.backpressure.check.interval: 1000採樣次數和採樣比例， 即在連續4次採樣中， 超過（不包含）（4 ＊0.75）次阻塞才能認爲真正阻塞， 超過（不包含）(4 * 0.75)次解除阻塞才能認爲是真正解除阻塞
topology.backpressure.trigger.sample.rate: 0.75 topology.backpressure.trigger.sample.number: 4
動態調整
```
jstorm update_topology topology-name -conf confpath
```
