千萬級流量架構設計實現方案

實現千萬級流量架構設計實現原則算法

1 實現高併發數據庫

  • 服務拆分:將整個項目拆分紅多個子項目或者模塊,分而治之,將項目進行水平擴展
  • 服務化:解決服務調用複雜以後的服務註冊和發現問題
  • 消息隊列: 解耦,異步處理
  • 緩存:各類緩存帶來的高併發

2 實現高可用緩存

  • 集羣
  • 限流
  • 降級

3 業務設計服務器

  • 冪等:用戶對於同一個操做發起的一次請求或者屢次請求的最終請求結果是一致的,不會由於點擊了屢次而產生不一致的結果
  • 防重:防止一樣的數據同時提交,服務端防重實現思路:在服務器端生成一個唯一的隨機標識(Token),同時在當前用戶的Session中保存這個標識,而後將這個標識發送到客戶端的form表單中,在表單中用隱藏域存儲這個標識,當表單提交的時候,這個標識和表單一塊兒提交到服務端,而後在服務端判斷用戶提交上來的標識和服務器生成的標識是否同樣,若是不同就表明是重複提交,此時服務器就能夠不用處理重複提交上來的請求,若是同樣,則證實不是重複提交,服務器能夠對提交的請求作相關的處理,請求處理完成後清除當前用戶session中存儲的標識

在下列狀況下,服務器將拒絕用戶提交的請求:網絡

  1. 存儲session中的token域表單提交的token不一致
  2. 存儲用戶的session中不存在token
  3. 用戶提交的表單數據中不存在token
  •  狀態機:軟件設計中的狀態機,通常指有限狀態機,是表示有限個狀態以及這些狀態之間的轉移和動做等

4  限流session

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

限流的方式併發

  1. 限制瞬時併發數: 在入口層限制同一個IP 來源的鏈接請求,防止惡意攻擊
  2. 限制併發總數:經過配置數據庫鏈接池,線程池的大小來約束總的併發數
  3. 限制時間窗口內的平均速度:在接口層面,經過限制訪問速率來控制接口的併發請求
  4. 其餘方式:限制遠程接口的調用速率,限制MQ的消費速率

經常使用的限流算法異步

  1. 滑動窗戶協議:一種常見的流量控制技術,用來改善吞吐量

滑動窗口是一種流量控制技術,在早期的網絡通訊中,通訊雙方不會考慮網絡擁擠狀況直接發送數據,因爲你們不知道網絡的擁擠狀況,同時發送數據致使中間節點阻塞丟包,誰也發送不了數據,因此就有了滑動窗口機制來解決這類問題,發送方和接收方都維護一個數據幀的序列,這個序列就成爲窗口ide

滑動窗口協議,是基於TCP協議的一種應用,用於網絡數據傳輸時的流量控制,避免阻塞發生。該協議容許發送方在中止並等待確認前發送多個數據分組,因爲發送方沒必要每發一個分組就停下來等待確認,所以該協議能夠加速數據的傳輸,提升網絡吞吐量

發送窗口:發送端容許連續發送的幀的序號表,發送端能夠不等待應答而連續發送數據(能夠經過設置窗口的尺寸來控制)

接收窗口:接收方容許接收的幀的序列表,凡是落在接收窗口內的幀,接收方都必須處理,落在窗口以外的幀將被丟棄,接收方每次容許接收的幀數稱爲接收窗口的尺寸

      2 漏桶:漏桶算法能強行限制數據的傳輸速率

漏桶算法的原理很簡單,請求先進入到漏桶中,漏桶以必定的速度出水,當水請求過大會直接溢出,能夠看出漏桶算法能強行限制數據的傳輸速率,進入端無須考慮出水端的速率,就像mq消息隊列那樣,provider只須要將消息傳入隊列中,而不須要關係consumer是否接收到了消息。對於溢出的水就是被過濾的數據,能夠直接丟棄,也能夠經過某種方式暫時保存,例如加入隊列,像線程池裏面對溢出數據的4種處理機制同樣

     3 令牌桶:屬於控制速率類型的限流算法

對於不少應用場景來講,除了可以要求限制數據的平均傳輸速率外,還要求容許某種程度的突發傳輸,這個時候漏桶算法就不合適了,令牌桶算法更爲合適,令牌桶的算法原理是系統會以一個恆定的速度往桶裏面放入令牌,若是請求須要被處理,則須要從桶裏面獲取一個令牌,當桶裏面沒有令牌可獲取的時候,則拒絕服務

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

相關文章
相關標籤/搜索