隨著互聯網的發展，各項軟件的客戶量日益增多，當客戶量達到一定峰值時，當數以萬計的流量來臨時，程序的順利運行以及即時響應則顯得尤為重要，就像雙11那天的淘寶一樣。那麼，如何設計架構才能夠抗住這千萬級的流量。
老闆讓你抗住千萬級流量，如何做架構設計？
首先，要在我們架構設計的時候建立一些原則。
1. 實現高可用
集群、限流、降級
2. 實現高併發
服務拆分：將整個項目拆分成多個子項目或者模塊，分而治之，將項目進行水平擴展。
服務化：解決服務調用複雜之後的服務的註冊發現問題。
消息隊列：解耦，異步處理
緩存：各種緩存帶來的併發
3. 業務設計
冪等：就是用戶對於同一操作發起的一次請求或者多次請求的結果是一致的，不會因為多次點擊而產生了副作用，就像數學裡的數字1，多少次冪的結果都是1。舉個最簡單的例子，那就是支付，用戶購買商品後支付，支付扣款成功，但是返回結果的時候網絡異常，此時錢已經扣了，用戶再次點擊按鈕，此時會進行第二次扣款，返回結果成功，用戶查詢餘額發現多扣錢了，流水記錄也變成了兩條。
防重：防止同樣的數據同時提交
除了在業務方向判斷和按鈕點擊之後不能繼續點擊的限制以外，在服務器端也可以做到防重：
在服務器端生成一個唯一的隨機標識號(Token令牌)同事在當前用戶的Session域中保存這個令牌，然後將令牌發送到客戶端的form表單中，在form表單中使用隱藏域來存儲這個Token，表單提交的時候聯通這個Token一起提交到服務器，然後在服務器端判斷客戶提交上來的Token與服務器端生成的Token是否一致，如果不一致，那就重複提交了，此時服務器端就可以不處理重複提交的表單，如果相同則處理表單，處理完後清楚當前用戶的Session域中存儲的標識號。
在下列情況中，服務器程序將拒絕處理用戶提交的表單請求：
1）存儲Session域中的Token與表單提交的Token不一致
2）當前用戶的Session中不存在Token
3）用戶提交的表單數據中沒有Token。
狀態機
軟件設計中的狀態機概念，一般是指有限狀態機（英語：finite-state machine，縮寫：FSM）又稱有限狀態自動機，簡稱狀態機，是表示有限個狀態以及在這些狀態之間的轉移和動作等行為的數學模型。
這裡著重講一下限流的概念和例子
限流的目的
限流的目的是通過對併發訪問/請求進行限速或者一個時間窗口內的請求進行限速來保護系統的可用性，一旦達到限制速率就可以拒絕服務。就像手機預售一樣，假如要賣出3萬臺，只需要接收3萬用戶的請求就可以，其他的用戶請求可以選擇過濾，可以提示當前服務器過忙，請稍後再試的提示。
限流方式：
1. 限制時間窗口內的平均速率：在接口層面，通過限制訪問速率來控制接口的併發請求。
2. 限制總併發數：通過配置數據庫連接池、線程池大小來約束總併發數
3. 限制瞬時併發數 ： 比如在入口層（nginx添加nginx_http_limit_conn_module）來限制同一個ip來源的連接數，防止惡意攻擊訪問的情況。
4. 其他方式：限制遠程接口的調用速率、限制MQ的消費速率。
常用限流算法
1. 滑動窗口協議：一種常見的流量控制技術，用來改善吞吐量的技術。
滑動窗口協議的由來：
滑動窗口（sliding window）是一種流量控制技術。早期的網絡通訊中，通信雙方不會考慮網絡的擁擠情況直接發送數據。由於大家不知道網絡擁塞狀況，同時發送數據，導致中間節點阻塞掉包，誰也發送不了數據，所以就有了滑動窗口機制來解決此問題。 發送和接收方都會維護一個數據幀的序列，這個序列被稱為窗口。
定義：滑動窗口協議（Sliding Window Protocol），屬於TCP協議的一種應用，用於網絡數據傳輸時的流量控制，以避免擁塞的發生。該協議允許發送方在停止並等待確認前發送多個數據分組。由於發送方不必每發一個分組就停下來等待確認，因此該協議可以加速數據的傳輸，提高網絡吞吐量。
發送窗口：就是發送端允許連續發送的幀的序號表。發送端可以不等待應答而連續發送數據（可以通過設置窗口的尺寸來控制）
接收窗口：接收方允許接收的幀的序列表，凡是落在接收窗口內的幀，接收方都必須處理，落在接收窗口外的幀將被丟棄。接收方每次允許接收的幀數稱為接收窗口的尺寸
演示地址：
https://media.pearsoncmg.com/aw/ecs_kurose_compnetwork_7/cw/content/interactiveanimations/selective-repeat-protocol/index.html
2. 漏桶：漏桶算法能強行限制數據的傳輸速率。
漏桶算法思路很簡單，請求先進入到漏桶裡，漏桶以一定的速度出水。當水請求過大會直接溢出，可以看出漏桶算法能強行限制數據的傳輸速率。進入端無需考慮出水端的速率，就像mq消息隊列一樣，provider只需要將消息傳入隊列中，而不需要關心Consumer是否接收到了消息。
對於溢出的水，就是被過濾的數據，可以直接被丟棄，也可以通過某種方式暫時保存，如加入隊列之中，像線程池裡對溢出數據的4種處理機制一樣
3. 令牌桶：屬於控制速率類型的限流算法。
對於很多應用場景來說，除了要求能夠限制數據的平均傳輸速率外，還要求允許某種程度的突發傳輸。這時候漏桶算法可能就不合適了，令牌桶算法更為適合。令牌桶算法的原理是系統會以一個恆定的速度往桶裡放入令牌，而如果請求需要被處理，則需要先從桶裡獲取一個令牌，當桶裡沒有令牌可取時，則拒絕服務。
設置 Rate = 2 ：每秒放入令牌的個數
桶的大小：100
這裡小編用一個小Demo來實現一下令牌桶，回覆“資料”可獲取源代碼
執行結果：
<code>正常處理正常處理
正常處理
正常處理
正常處理
處理失敗
正常處理
處理失敗
處理失敗
處理失敗
正常處理
處理失敗
正常處理
處理失敗
正常處理
正常處理
正常處理
正常處理
處理失敗
處理失敗/<code>
由此可見，當令牌不足時，會獲取令牌失敗，達到限流的效果。
4. 計數器：最簡單的一種。通過控制時間段內的請求次數。
現在私信我“資料”即可獲取Java工程化、高性能及分佈式、高性能、高架構。性能調優、Spring，MyBatis，Netty源碼分析和大數據等多個知識點高級進階乾貨的直播免費學習權限及領取相關資料，助你早日升職加薪！
