1. 程式人生 > >老闆讓你抗住千萬級流量,如何做架構設計?

老闆讓你抗住千萬級流量,如何做架構設計?

隨著網際網路的發展,各項軟體的客戶量日益增多,當客戶量達到一定峰值時,當數以萬計的流量來臨時,程式的順利執行以及即時響應則顯得尤為重要,就像雙11那天的淘寶一樣。那麼,如何設計架構才能夠抗住這千萬級的流量。

老闆讓你抗住千萬級流量,如何做架構設計?

首先,要在我們架構設計的時候建立一些原則。

1. 實現高併發

服務拆分:將整個專案拆分成多個子專案或者模組,分而治之,將專案進行水平擴充套件。

服務化:解決服務呼叫複雜之後的服務的註冊發現問題。

訊息佇列:解耦,非同步處理

快取:各種快取帶來的併發

2. 實現高可用 

叢集、限流、降級

3. 業務設計

冪等:

就是使用者對於同一操作發起的一次請求或者多次請求的結果是一致的,不會因為多次點選而產生了副作用,就像數學裡的數字1,多少次冪的結果都是1。舉個最簡單的例子,那就是支付,使用者購買商品後支付,支付扣款成功,但是返回結果的時候網路異常,此時錢已經扣了,使用者再次點選按鈕,此時會進行第二次扣款,返回結果成功,使用者查詢餘額發現多扣錢了,流水記錄也變成了兩條。

防重:防止同樣的資料同時提交

除了在業務方向判斷和按鈕點選之後不能繼續點選的限制以外,在伺服器端也可以做到防重:

在伺服器端生成一個唯一的隨機標識號(Token<令牌>)同事在當前使用者的Session域中儲存這個令牌,然後將令牌傳送到客戶端的form表單中,在form表單中使用隱藏域來儲存這個Token,表單提交的時候聯通這個Token一起提交到伺服器,然後在伺服器端判斷客戶提交上來的Token與伺服器端生成的Token是否一致,如果不一致,那就重複提交了,此時伺服器端就可以不處理重複提交的表單,如果相同則處理表單,處理完後清楚當前使用者的Session域中儲存的標識號。高可用高併發架構參考:

高可用高併發的 9 種技術架構

在下列情況中,伺服器程式將拒絕處理使用者提交的表單請求:

1)儲存Session域中的Token與表單提交的Token不一致

2)當前使用者的Session中不存在Token

3)使用者提交的表單資料中沒有Token。

狀態機

軟體設計中的狀態機概念,一般是指有限狀態機(英語:finite-state machine,縮寫:FSM)又稱有限狀態自動機,簡稱狀態機,是表示有限個狀態以及在這些狀態之間的轉移和動作等行為的數學模型。

這裡著重講一下限流的概念和例子

限流的目的

限流的目的是通過對併發訪問/請求進行限速或者一個時間視窗內的請求進行限速來保護系統的可用性,一旦達到限制速率就可以拒絕服務。就像手機預售一樣,假如要賣出3萬臺,只需要接收3萬用戶的請求就可以,其他的使用者請求可以選擇過濾,可以提示"當前伺服器過忙,請稍後再試"的提示。

限流方式:

1. 限制瞬時併發數 : 比如在入口層(nginx新增nginx_http_limit_conn_module)來限制同一個ip來源的連線數,防止惡意***訪問的情況。

2. 限制總併發數:通過配置資料庫連線池、執行緒池大小來約束總併發數

3. 限制時間視窗內的平均速率:在介面層面,通過限制訪問速率來控制介面的併發請求。

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來實現一下令牌桶



執行結果:


由此可見,當令牌不足時,會獲取令牌失敗,達到限流的效果。

4. 計數器:最簡單的一種。通過控制時間段內的請求次數。