不知道大家對throttle這個單詞是否看着眼熟，還是說對這個計算機基礎概念有很清晰的了解了。今天就來聊聊和throttle相關的一些技術場景。
我經常有一種感覺，對于英語這門語言的語感，會影響我們對于一些關鍵技術概念的了解。有時候在學習新技術知識的時候，我會先花一些時間去了解術語英文單詞的各種語義，在形成強烈清晰的語感之後，再去深入具體的技術語境。throttle也算是個生僻的單詞，至少在口語中畢竟少用到，先來看看詞義：
a device controlling the flow of fuel or power to an engine.
中文翻譯是節流器，一種控制流量的裝置。對應到我們計算機世界，可以了解成，一種控制資料或者事件流量大小的機制。這麼說可能還是有些抽象，再來看看一些具體的技術場景加深了解。
話說gcd幾乎是ios面試的必問題，也是個送分題:)。
我一般會機械式的先問：gcd有哪幾種queue？回答：串行queue和并行queue。
我繼續問：global queue有哪幾種優先級？回答：有幾種吧，大概記得default，low，high吧。
當然啦，答不出i/o throttle并不能說明技術不紮實，但能答出來，至少表明對待技術是有好奇心的，加分！
官方文檔如是說：
items dispatched to the queue run at background priority; the queue is scheduled for execution after all high priority queues have been scheduled and the system runs items on a thread whose priority is set for background status. such a thread has the lowest priority and any disk i/o is throttled to minimize the impact on the system.
那disk i/o throttle做什麼用呢？按照上面這段描述，disk i/o會impact system performance。
了解disk
i/o的影響需要補充一些大學課本上的知識。一次磁盤讀寫操作涉及到的硬體資源主要有兩個，cpu和磁盤。任務本身由cpu觸發和排程，讀操作發生時，cpu告知disk去擷取某個位址的資料，此時由于disk的讀操作存在尋址延遲，cpu是處于i/o
wait狀态，一直維持到disk傳回資料為止。處于i/o
wait狀态的cpu，此時并不能把這部分等待的時間用來處理其他任務，也就是說這一段等待的cpu時間被“浪費”了。而cpu是公共的系統資源，這部分資源的損耗自然會對系統的整體表現産生負面影響。即使global
queue使用的是子線程，也會造成cpu資源的消耗。
如果把任務的priority調整為dispatch_queue_priority_background，那麼這些任務中的i/o操作就被被控制，雖然具體的控制政策并沒有官方文檔描述（一種可能的政策是并發的disk
i/o變為串行的），但我們能确認的是，部分i/o操作的啟動時間很有可能被适當延遲，把更多的cpu資源騰出來處理其他任務(比如說一些系統資源的排程任務)，這樣可以讓我們的系統更加穩定高效。簡而言之，對于重度磁盤i/o依賴的背景任務，如果對實時性要求不高，放到dispatch_queue_priority_background
queue中是個好習慣，對系統更友好。
實際上i/o throttle還分為好幾種，有disk i/o throttle，memory i/o throttle，和network i/o throttle。語義類似隻不過場景不同，繼續往下看。
早幾年讀asihttprequest源碼的時候，讀到過一段有意思的代碼：
在afnetworking中也有類似的代碼：
原諒我貼了一大段注釋，這段英文描述對于加深我們對于一些網絡行為的了解很有幫助。
這些知名的第三方網絡架構都有對newtork throttle的支援，你可能會好奇，我們為什麼要對自己發出的網絡請求做流量控制，難道不應該盡可能最大限度的利用帶寬嗎？
此處需要科普一點tcp協定相關的知識。我們通過http請求發送資料的時候，實際上資料是以packet的形式存在于一個send
buffer中的，應用層平時感覺不到這個buffer的存在。tcp提供可靠的傳輸，在弱網環境下，一個packet一次傳輸失敗的機率會升高，即使一次失敗，tcp并不會馬上認為請求失敗了，而是會繼續重試一段時間，同時tcp還保證packet的有序傳輸，意味着前面的packet如果不被ack，後面的packet就會繼續等待，如果我們一次往send
buffer中寫入大量的資料，那麼在弱網環境下，排在後面的packet失敗的機率會變高，也就意味着我們http請求失敗的幾率會變大，類似這樣：
大部分時候在應用層寫代碼的時候，估計不少同學都意識不到newtork
throttle這種機制的存在，在弱網環境下（丢包率高，帶寬低，延遲高）一些http請求(比如上傳圖檔或者日志檔案)失敗率會激增，有些朋友會覺得這個我們也沒辦法，畢竟網絡辣麼差。其實，作為有追求的工程師，我們可以多做一點點，而且弱網下請求的成功率其實是個很值得深入研究的方向。針對弱網場景，我們可以啟用newtork
throttle機制，減小我們一次往send
buffer中寫入的資料量，或者延遲某些請求的發送時間，這樣所有的請求在弱網環境下，都能「耐心一點，多等一會」，請求成功率自然也就适當提高啦。
那麼，再看afnetworking中的這個函數，是不是更能了解了呢？
network throttle展現了一句至理名言「慢即是快」。
不知道大家在寫ui的時候，有沒有遇到過使用者快速連續點選uibutton，産生多次touch事件回調的場景。以前機器還沒那麼快的時候，我在用一些app的時候，時不時會遇到偶爾卡頓，多次點選一個button，重複push同一個controller。有些工程師會在button的點選事件裡記錄一個timestamp，然後判斷每次點選的時間間隔，間隔過短就忽略，這也不失為一種解決辦法。
再後來學習rxswift的時候，看到：
終于有了優雅的書寫方式。發現沒有，throttle又出現了，這裡throttle控制的是什麼呢？不是disk讀寫，也不是network
buffer，而是事件，把事件本身抽象成了一種data，控制這種資料的流量或者産生頻率，就解決了上面我們所說重複點選按鈕的問題，so easy。
當然還會有更多的場景，throttle其實是個基礎的計算機知識。了解throttle相關的技術概念，需要在不同場景下去抽象出一個flow被節流的畫面。現在，如果讓你來解釋一些具體的技術場景下，throttle是怎麼回事，是不是可以信手拈來了: )
作者：mrpeak雜貨鋪
來源：51cto