1.漏桶限流算法的原理
以固定速率從桶中流出水滴，以任意速率往桶中放入水滴，桶容量大小是不會發生改變的。
流入：以任意速率往桶中放入水滴。
流出：以固定速率從桶中流出水滴。
水滴：是唯一不重複的標識。
因爲桶中的容量是固定的，如果流入水滴的速率>流出的水滴速率，桶中的水滴可能會溢出。那麼溢出的水滴請求都是拒絕訪問的，或者直接調用服務降級方法。前提是同一時刻。
2.令牌桶算法(Token)
令牌桶分爲2個動作，動作1(固定速率往桶中存入令牌)、動作2(客戶端如果想訪問請求，先從桶中獲取token)。guava 提供的RateLimiter類來進行限流處理。
1.傳統的方式整合RateLimiter 有很大的缺點：代碼重複量特別大，而且本身不支持註解方式。
2.如果限流代碼可以放在網關中，相當於針對所有的服務接口都實現限流(可以使用排除法進行排除不進行限流的方法)，維護性不是很強。
3.正常的公司項目，不是所有的服務接口都需要實現限流方法的，一般只真針對於大流量接口。比如：秒殺搶購、12306搶票這樣的場景。
4.可以手動封裝一個RateLimiter類 註解來解決這個方法。
以規定的速率往令牌桶中放入 token，用戶請求必須獲取到令牌桶中的 token纔可以訪問我們的業務邏輯方法，如果沒有從令牌桶中獲取到 token ，拒絕訪問。
在高併發情況下，如果我們的請求過多 超出了令牌桶生成令牌的速度，這時候請求就會被駁回，提示請稍後重試！
優勢：能夠控制請求的速率。
限流的目的：爲了保護服務，避免服務宕機。
漏桶算法與令牌桶算法的區別
令牌桶算法：以固定的速率(平均速率)生成對應的令牌放到桶中，客戶端只需要在桶中獲取到令牌後，就可以訪問服務請求。
漏桶算法：以任意速率往桶中放入水滴，如果桶中的水滴沒有滿的話，可以訪問服務。
在突發情況請求的時候，令牌桶中只需要客戶端你能夠拿到令牌就能訪問服務。但是漏桶算法正好與令牌桶算法相反，令牌桶以平均速率訪問，漏桶算法平滑訪問。