說道限流，首先得明白爲什麼要限流，如果不限流會有什麼影響，爲什麼會產生這種影響，我們先圍繞這幾個問題來說說。
爲什麼要限流 ?
一臺服務器的資源是有限的，無論是CPU還是內存還是IO，在一定的閾值下資源的能效比是逐漸上升得，也就是說資源利用率上升得同時產生的效益也是逐漸上升得，直觀的體現就是吞吐量提升。但超過一定閾值後，能效比會迅速下降，也就是資源用的更多，但是吞吐量反而急劇下降。同時應用內如果某個服務佔據的資源過多甚至某個調用方過多調用會影響其他服務的正常運行。所以無論是對應用的整體流量，還是應用內不同服務的流量，還是針對下游的調用方，都應該做限流。
如果不限流會有什麼問題 ?
如果不限流，調用方的請求瘋狂湧入可能會有如下問題：
- 會導致應用的響應時間越來越長
- 可能會導致進程負載飆高，同時還有CPU使用率急劇飆升
- 可能會應用的使用內存持續在高位，同時會有頻繁的Full GC，最後甚至OOM
爲什麼會產生這種問題 ?
- 過多的線程過多的請求，CPU來不及處理，負載飆升
- 如果未對線程數做限制，或者線程池的MaxSize太高，那麼瘋狂的流量會瞬間將線程數彪到上限，每個線程都會在jvm堆內分配一小塊空間以存儲線程相關的數據，少則64K，大則1M，過多的線程首先會佔用大量內存空間，導致更頻繁的GC，降低吞吐量。其次CPU的運算資源是在多個線程間以時間片的形式流轉的，當從一個線程切換到另一個線程時，需要先暫存上一個線程的上下文，然後加載當前線程的上下文，這些都會耗費CPU資源，過多的線程會導致這種切換變得非常頻繁，將CPU資源大量的耗費在線程切換上，會進一步惡化應用的健康度。Linux下可以通過查看系統的
nvcswch，表示每秒非自願上下文切換（non voluntary context switches）的次數這個指標來查看是否是線程數過多問題。非自願上下文切換, 也就是上下文切換不是由IO中斷等事件主動切換的線程場景。 - 過多的請求到來，沒有及時的處理(相應或者快速失敗)，而是用請求隊列的形式緩存，每個請求都會耗費一定的內存資源，過長的請求緩衝隊列會導致內存被大量佔滿，會更容易發生full gc，而gc也同樣是一個高耗能的操作，並且是大量數據都難以回收的情況下，應用的處理能力會更進一步降低，最後可能會導致OOM。
限流可以怎麼限？
- 線程池：限流最典型的方式就是線程池了，比如tomcat線程池，mysql連接池，rpc線程池，甚至是應用內的自定義線程池。定義線程池，限制線程上限，限制應用緩衝的請求數，指定超限的請求處理方式。線程池的參數要怎麼設置，這是一個需要需要結合服務器資源和業務場景計算的。比如應用時一個CPU密集型的，那麼線程數和CPU核心數量差不多是合適的；如果應用時一個IO密集型的，那麼線程池數有兩種考量。1：如果應用定義了對外提供服務的QPS上限，那麼通過服務調用的IO等待和CPU使用時間的比例，計算需要的線程上限，一般這個數目會低於實際的CPU核心數目，如果不夠那麼用更好的服務器。2：如果未指定對外提供的QPS上限，根據服務的IO和CPU的時間比例與提供服務的物理線程數之積計算出線程池的線程池數上限。
- 服務線程：一個應用內服務之間有輕重之分，有些服務需要優先保障可用性和迅速響應，有些服務不是關鍵性的服務，比如當電商大促時會對一些非必要服務做降級或者關閉。可以用線程池隔離的形式對內部服務的調用做資源隔離，但這也容易導致同步的調用變異步，或者額外增加線程數，增加資源耗費。可以使用Sentinel的線程隔離，限制服務在同一時間使用的線程池數，還是比較方便的。
- 調用QPS：一根據的限流算法之漏銅桶算法，每秒生成固定個數的令牌，服務調用方拿到令牌可通過，拿不到被阻塞或者快速失敗。QPS限制可以在應用的統一入口，限制所有服務的總和調用QPS；也可以對特定服務做QPS限制。使用Sentinel能很方便的做QPS限流。
- 調用方(調用參數)：售賣性的服務都會限制買方的調用QPS，不同套餐QPS上下限不同，實質就是對請求中某個參數的做了識別，限制套餐參數在不同值下的QPS，甚至也可以限制不同參數可以使用的線程數。或者一些熱點參數，比如大促時的熱門商品，通過對熱門商品做標識，識別不同標識來限制熱點參數的QPS也是一個常見的策略。
- 系統參數：實時監控系統的參數指標，比如當負載達到一定程度，或者內存使用率到了某個閾值，或者CPU使用率飆升時，觸發限流。
- 集羣限流：集羣限流和單機限流有些不同，實時性的集羣限流需要有一個流控的Server，響應流控Client的調控請求，實時統計集羣服務的QPS，調用線程數，然後對調控請求做通過與否的響應。