限流不能亂用，否則正常流量會出現一些奇怪的問題，從而導致使用者抱怨。
假設有130w到140w的資料插入到資料庫中，如果沒有做限流，資料庫的主庫會突然接收到130w的插入操作。
首先是網路上的開銷，很可能直接把頻寬佔滿，導致其他請求無法正常傳輸和處理，其次會是資料庫的負載突然增高，導致無法處理某些資料庫的操作，也有可能資料庫沒有足夠的連線導致某些資料庫插入查詢失敗；
還有一點就是現在資料庫都做了主從設計，主資料庫的資料還要同步給從庫，這時瞬間插入了大量的資料，會帶來從庫和主庫的延遲特別大，這時從庫查詢不準確的概率也會跟著提公升。
如果我們放慢插入資料庫的速度，這時插入資料庫主庫的速率會很正常，同步到從庫也很正常。網路消耗也可以接收不會影響其他服務。
1.計數器法
有時我們還會使用計數器來進行限流，主要用來限制一定時間內的總併發數，比如資料庫連線池、執行緒池、秒殺的併發數；計數器限流只要一定時間內的總請求數超過設定的閥值則進行限流，是一種簡單粗暴的總數量限流，而不是平均速率限流。
這個方法有乙個致命問題：臨界問題——當遇到惡意請求，在0:59時，瞬間請求100次，並且在1:00請求100次，那麼這個使用者在1秒內請求了200次，使用者可以在重置節點突發請求，而瞬間超過我們設定的速率限制，使用者可能通過演算法漏洞擊垮我們的應用。
2.滑動視窗演算法
在上圖中，整個紅色矩形框是乙個時間視窗，在我們的例子中，乙個時間視窗就是1分鐘，然後我們將時間視窗進行劃分，如上圖我們把滑動視窗
劃分為6格，所以每一格代表10秒，每超過10秒，我們的時間視窗就會向右滑動一格，每一格都有自己獨立的計數器，例如：乙個請求在0:35到達，
那麼0:30到0:39的計數器會+1，那麼滑動視窗是怎麼解決臨界點的問題呢？如上圖，0:59到達的100個請求會在灰色區域格仔中，而1：00到達的請求
會在紅色格仔中，視窗會向右滑動一格，那麼此時間視窗內的總請求數共200個，超過了限定的100，所以此時能夠檢測出來觸發了限流。
回頭看看計數器演算法，會發現，其實計數器演算法就是視窗滑動演算法，只不過計數器演算法沒有對時間視窗進行劃分，所以是一格。
由此可見，當滑動視窗的格仔劃分越多，限流的統計就會越精確。
3.漏銅演算法
這個演算法很簡單。首先，我們有乙個固定容量的桶，有水進來，也有水出去。對於流進來的水，我們無法預計共有多少水流進來，也無法預計流水速度，但
對於流出去的水來說，這個桶可以固定水流的速率，而且當桶滿的時候，多餘的水會溢位來。
4.令牌桶演算法
從上圖中可以看出，令牌演算法有點複雜，桶裡存放著令牌token。桶一開始是空的，token以固定的速率r往桶裡面填充，直到達到桶的容量，多餘的token會
被丟棄。每當乙個請求過來時，就會嘗試著移除乙個token，如果沒有token，請求無法通過。
併發與高併發（二十）高併發 應用拆分思路
這一章節我們將講解高併發解決方案中的應用拆分思路，也可以稱之為系統拆分。單個伺服器再優化，它的處理都是有上限的，因此我們採用擴容 快取 訊息佇列等對程式進行優化，這些手段都可行，但還不是全部。隨著專案的需求要求越來越多，應用自然會跟著越來越大，因此呢，架構師設計出了特別容易擴充套件的方案，從整體將乙...
目前常用的高併發處理手段
最近看了很多高併發的解決方案，高併發並沒有通用的解決方案，也不會有現成的demo或者原始碼可以參考，我在這方面也沒有什麼經驗 但是從我看到很多深度不高的文章來說，可以總結出一些可以真正落地的解決辦法 1.入口流量分發，軟體硬體分發 常見的nginx 負載均衡，lvs虛擬ip流量分發，以及f5硬體負載...
處理高併發的思路整理
1.垂直分層 dns分層 跨機房部署lvs nginx負載均衡，vanish 共享儲存實現動靜分離，nginx後掛載n態伺服器集群，伺服器集群後掛載服務化，微服務後掛載資料庫分庫分表 訊息佇列 任務排程，最後端掛載資料集群負責資料的統一歸檔 流計算 非同步批量處理 2.水平分割槽 根據業務劃分業務線...