大流量時代，如何規劃系統流量提升可靠性

摘要：本文主要是對《鳳凰架構》的解讀，講述規劃系統流量的幾種方式，

本文分享自華為云社區《大流量時代，如何規劃系統流量提升可靠性》，作者：breakDawn ，

透明多級分流系統

對系統流量進行規劃， 要注意以下2個原則

1. 盡可能減少單點部件， 或者減少到達單點部件的流量或者作用
2. 奧卡姆剃刀原則，確定有再有必要的時候才去使用，避免過度設計

1 客戶端快取

即對于某些資源， 在客戶端就做快取，客戶端不去重復請求，

1.1 強制快取

類似HTTP協議里在header里用到的兩種標簽，且都是服務端強行控制的，基于時間的

1. Expires
   服務端直接回傳資料不會變動的截止時間，
   缺點：受限于客戶端本地時間、無法表示不快取除非強制改時間戳、無法表示是否是私有資源（避免私有資源被其他節點快取）
2. Cache-Control
   這個請求頭使用max-age、private、no-cache等標簽解決了Expires里的3個缺點，

1.2 協商快取

協商快取需要考慮是否真的發生變化， 協商和強制可以共同存在，即強制失效的時候就可以用上協商，
協商快取不僅存在于地址輸入、跳轉，也存在F5中（但如果Ctrl+F5強制重繪則會讓快取失效）

1. Last-Modified
   告訴客戶端資源的最后修改時間， 客戶端再次請求時也會對這個時間做修改
   如果服務端發現在那個時間之后資源未變動，回傳304 Not Modified
   如果有變動，就回傳OK，并攜帶完整的資源
2. ETag
   需要對資源計算哈希值，客戶端發請求也會帶上自己存的ETag，每次會比對資源的哈希值是否一致，不一致則回傳新資源，
   Etag是一致性最強的本地快取機制，但也是性能最差的，

2 傳輸通道優化

本章節大部分以熟知的HTTP協議作為主要傳輸通道協議，講解如何進行優化

2.1 連接數優化

HTTP是基于TCP的，每次都是重新建立一個TCP連接， 因此前端開發人員開發了很多小優化，來減少請求次數，例如雪碧圖、分段檔案、合并Ajax請求之類的，

HTTP1.0里的長連接(keep-alive連接復用）為什么不能解決這個問題？
因為存在隊首阻塞問題，本質上是基于FIFO復用連接， 1個請求卡住了，后面9個請求都阻塞住了，但如果同時支持回傳，在順序混亂的情況下無法正常處理

HTTP2.0的多路復用解決了這個問題：

• 以幀作為最小粒度單位，每個幀都攜帶流ID識別是哪個流
• 客戶端可以很容易在不同流中重組HTTP請求和回應報文

2.2 傳輸壓縮

HTTP很早就支持GZip壓縮來減少大資源的傳輸量

HTTP1.0中， 持久連接和傳輸壓縮無法一起使用， 因為壓縮后無法識別資源是否傳輸完畢，

HTTP1.1中引入了“分塊傳輸編碼”，來進行資源結束的判斷，

2.3 用UDP來加快網路傳輸

HTTP/3中，希望能替換掉HTTP on TCP的依賴、
谷歌推出了快速UDP網路連接， 即QUIC

• QUIC以UDP為基礎， 可靠傳輸能力由自己實作
• QUIC專門面向移動設備支持， 移動設備的ip地址經常會切換，使用ip作為定位不合適， 因此提出了連接識別符號來保持連接，
• 對于不支持QUIC的情況，支持回退為TCP連接，實作兼容

3 內容分發網路CDN

CND可以解決 互聯網系統跨運營商、跨地域物理距離所導致的時延問題，為網站流量帶寬起到分流、減負的作用，
主要包含以下4個作業部分

3.1 路由決議

用戶的靜態資源請求訪問CDN是通過DNS決議來完成的，甚至可能一個網站會有各種不同地域的CDN域名決議地址回傳， 通過你的路由配置會自動選擇符合地域的ip地址

3.2 內容分發

如何分發內容有兩種方式：

1. 主動分發， 通過CND服務商提供的介面主動推送自己的資源，這樣你需要額外撰寫資源推動的代碼，大型活動例如雙11會優先考慮主動分發預先準備資源，
2. 被動回源， 由用戶訪問觸發，當發現沒有資源時,CDN會去源站請求并回傳，則用你不需要新寫相關代碼，只要在CDN那邊支持回源你的源站即可，小型站點基本都是用這個方法，

如何更新資源有兩種方式：

1. 超時被動失效，CDN的資源都有有效期，超時了就回源獲取
2. 手工主動失效， CDN服務商提供快取失效介面，主動觸發失效并進行被動回源更新，
   現在一般是1和2結合使用，二者不沖突

4 負載均衡

負載均衡有兩種大類

• 四層負載均衡
  指的是計算機七層模型中四層及以下的均衡策略結合
  即 資料鏈路層 + 網路層 均可做均衡
• 七層負載均衡
  指的是在應用層通過實際代碼做均衡

4.1 資料鏈路層負載均衡（四層負載均衡）

• 通過鏈路層上的均衡器替換MAC地址，進行鏈路層的均衡
• 各負載節點的IP是一樣的（相同的虛擬IP）
• 回傳時無需經過均衡器，直接回傳即可（因為目標ip、源ip基本沒變）

缺點：
必須是同一個子網內，無法跨VLAN，只能作為最接近資料中心的均衡器

4.2 網路層負載均衡（四層負載均衡）

有兩種方式：

IP隧道模式

均衡器在IP報文外面包了一層新的header，header里指定了目標機器的實際ip或者小網ip， 接識訓器要支持解header，且同樣要求作為回傳的虛擬ip是一致的，也是直接回傳無需經過均衡器，
缺點：

1. 用到的服務器都要支持隧道解包能力（linux系統現在都支持）
2. 虛擬ip仍然有較大限制，需要人工介入管理眾多機器

NAT模式

NAT模式中，就是進行真正的ip轉換， 且回傳時也要回傳給NAT進行ip轉換，這樣只需要針對NAT進行人工管理即可，
缺點在于NAT容易成功性能瓶頸

SNAT會修改源IP改為NAT的ip， 可以做到對業務真正透明， 但是代價是如果需要對源IP做限制時容易有問題， 因為所有的來源ip都是一樣的了，

4.3 應用層負載均衡（七層負載均衡）

也叫做七層代理（應用層代理），因為這個負載均衡屬于反向代理（即部署在服務端的代理，對客戶端不感知）

不適合做下載站、視頻站等流量應用
如果瓶頸在服務計算能力，則可以考慮做應用層均衡
期

七層代理除負載均衡外的其他功能：

• 支持做CDN類似的快取能力
• 施行智能化路由，根據URL或者特定用戶做特殊服務
• 抵御安全工具，提前過濾攻擊報文
• 鏈路治理

4.4 負載均衡策略

• 輪詢均衡
  輪流分配，從1到N再到1
  適用于所有服務器硬體配置完全相同，服務請求需要相對均衡
• 權重輪詢
  根據服務器權重分配周期內的輪詢次數
• 隨機均衡
  適用于資料量足夠大的相對均衡分布
• 權重隨機均衡
  提升權重高的隨機率
• 一致性哈希均衡
  適用于服務器經常可能掉線或者加入，可以避免哈希鍵全部更新的情況
• 回應速度均衡
  定期探測各個服務器的回應速度，根據速度分配權重
• 最少連接數均衡
  根據連接數分配權重， 適用于長時處理服務例如FTP等
• 軟體均衡器包括基于作業系統內核的LVS、 基于應用程式的Nginx、KeepAlive、HAProxy
• 硬體均衡器包括F5、A10等公司提供的硬體負載均衡產品

5 服務端快取

引入快取的理由：

• 級訓CPU計算壓力
• 快取IO壓力
  這2個緩解只是能峰值時的壓力緩解，如果普通的回應都很慢，那就算用了快取也意義不大，

5.1 快取的幾個屬性

快取需要選型，選型時需要根據實際場景選擇你匹配的快取熟悉

吞吐量

JDK8改進后的ConcurrentHashMap是并發場景下吞吐量最高的快取容器，但除了吞吐量其他的能力就很弱了，

快取狀態更新思路：

• GuavaCache: 同步處理機制，在訪問資料時一并更新，分段加鎖減少競爭
• Caffeine：異步日志提交機制，參考資料庫日志，并且還有環形緩沖區容忍有損失的狀態變更，讀性能非常快， 使用多讀少寫的情況，

命中率和淘汰策略

基礎的三種淘汰方案：

• FIFO：先進先出，簡單實作，但對于高頻訪問的快取命中率低，越常用到越可能先進入佇列
• LRU：優先淘汰最久未被訪問，基于時間， 用HashMap+鏈表List實作，但每個快取都要記錄時間，且可能淘汰短期內正好沒訪問且價值高的資料
• LFU：優先淘汰最不頻繁使用，基于使用次數，可以解決LRU的缺點，
  自身缺點：

1. 每個快取專門維護要更新次數的計數器，維護開銷大還有加鎖問題（LRU的更新時間不需要考慮加鎖，直接覆寫最新即可）
2. 如果某個快取某時期訪問很高，比其他快取高了一個數量級，后面不再使用，想淘汰很困難

為了解決上面2個缺點，有2個新的策略：

• TinyLFU： 解決修改計數器的開銷問題， 采用Sketch分析訪問資料，用少量資料估計全體資料特征，采用滑動時間窗、熱度衰減等處理
• W-Tinfy-LFU： 結合了LRU+LFU的特點， 考慮熱度和時間，

分布式能力

分布式快取介紹了復制式快取JbossCache以及集中式快取Memcached，

jbosscache的缺點在于寫入性能太差，容易因為網路同步速度跟不上寫入速度，導致記憶體中積累過多待發物件引發omm

memcached是C語言實作的，好處在于讀寫性能高，缺點在于資料結構太過緊密，非常依賴序列化做跨語言傳輸，如果100個欄位中的1個欄位發生更新，要把100個欄位都發出去更新

redis基本打敗了各種分布式快取，成為首選，

對于redis等分布式快取， 是不會追求一致性C的
如果一定要一致性C， 那應該選用zk或者etcd等分布式協調框架（但他們一般就不會拿來做快取，因為高并發下吞吐量太低，沒有可用性）

行程內快取和分布式快取通常結合使用，但容易出現二者資料不一致，寫維護策略導致快取對開發者而言不透明，
一種設定原則是 變更以分布式快取中的資料為主，訪問以行程內快取的資料優先，
大致做法是資料發生變動時， 在分布式快取內推送通知， 讓一級快取失效，
訪問快取時，提供封裝好的一二級聯合查詢介面， 讓開發者對一二級快取不感知，

5.2 快取風險

快取穿透

大量不存在的快取打進來
要么是支持對不存在的資料快取空值
要么是引入布隆過濾器

快取擊穿

同一時間瞬間涌現很多請求，訪問資料庫有但是快取里沒有的資料，此時可能直接打穿資料庫（快取生效是有延遲的）
可以是用鎖、佇列來完成同步
對于熱點快取，提前預處理或者配置策略

點擊關注，第一時間了解華為云新鮮技術~

標籤：架構設計

上一篇：淺談復雜業務系統的架構設計

下一篇：返回列表