分佈式架構 高併發處理

分佈式架構 高併發處理

高併發介紹

 

• 在同時或者極短期內，有大量請求到達服務端，每一個請求都須要服務端耗費資源進行處理，並作出相應反饋
• 服務端好比同時開啓進程數，能同時運行的線程數、網絡鏈接數、CPU運算、I/O、內存都是有限，
  因此服務端能同時處理請求也是有限的。高併發本質就是資源的有限性
  如：1.系統在線人數10W，並不意味系統併發用戶是10W,可能存在10w用戶同時在首頁查看靜態文章，並未對服務器進行發送請求
  那麼高併發數 是根據系統真實用戶數併發送請求須要服務端耗費資源進行處理的請求
  2.服務端只能開啓100個線程，剛好1個線程處理一個請求須要耗時1s，那麼服務端1s只能處理100個請求，多餘請求沒法處理

經典案例

• 商品、活動秒殺下訂單

準備階段

• 系統獨立部署
• 作好系統容量規劃（7-7.5折計算），系統優化、系統容災限流等方案
• 作好系統拆分，如：功能模塊、實時/非實時、動態/靜態等
• 參加活動商品設置定時上架時間
• 服務器時間同步（集羣中每臺機器時鐘要保持一致）
• 動態生成下單頁面的URL

實現階段

客戶端層面：

• 前端頁面採用h5靜態化，ajax獲取動態內容；如實時庫存、活動狀態、當前時間等
• 作CDN部署加速
• 靜態頁面和資源緩存 如：（圖片）
• JS針對請求過濾，減小請求發送到達服務端 如：（獲取驗證碼、時間截止或已售空自動結束等）

Web端層面：

• F5/LVS+Nginx接收高併發請求、並作負載均衡
• Lua腳本+Redis作請求隊列，針對有效請求用List排隊，並實現一些基本操做（限流、帳號參加次數檢查、同一IP請求數檢查）
  Redis單線程高性能，每秒處理100W請求，若是大於100W請求如何處理呢？
  1.能夠結合Lua腳本控制請求數量並限流，有效減小redis壓力；好比100W請求，過濾20W，還剩80W，無效請求直接返回客戶端不到達服務端
  2.若是應用很是龐大，用戶流量高額，Redis單節點作成集羣模式，請求處理數量也隨之增長
• Varnish緩存靜態頁面和靜態資源
• Tomcat集羣，預處理，經過業務場景判斷用戶是具有參加活動資格、帳號是否正常、是否在黑名單等

邏輯層面：

• 按照Redis請求隊列進行前後處理
• 純內存操做+異步（經過Redis完成減庫存，1.利用Redis的watch事物 2.利用Redis腳本Lua原子操做減庫存）

高併發產生問題，分析思考

• 服務端處理響應會逐漸變慢，甚至會丟失部分請求不處理，嚴重會致使服務器崩潰
• 客戶端（app\h5）、前端請求（nginx/varnish）、web服務器(webServer)、web應用(rmi/dubbo/遠程調用)、緩存（redis/membercache）、消息隊列（mq）、數據庫（db）都會面臨高併發等問題

高併發優化思路

客戶端層面

• 儘可能減小請求數量，充分利用客戶端、瀏覽器自身緩存，如微服務先後端交互、網絡傳輸詳細記載，本文不在詳敘
• 儘可能減小對服務端資源沒必要要浪費，如重複請求鏈接後端打開/關閉操做鏈接池

Nginx層面

• 動靜分離，靜態資源直接返回
• 負載均衡，如F5/LVS分流多個Nginx
• 根據系統業務，單獨拆分訪問（路徑）

Varnish層面

• 動態內容緩存、減小訪問後端服務
• 使用頁面片斷緩存技術，如ESI

Web服務器層面

• 針對JVM配置進行合理優化
• 服務器配置進行優化，如：調整內存數量、線程數量等
• 相同服務部署多臺機器，實現負載均衡
• 增長資源，如增長網絡帶寬、高性能服務器、高性能數據庫 （立杆見效，服務器普通硬盤換SSD,數據庫換物理機等）
• 請求分流
  1.使用集羣：如以前1臺處理100個請求，增長兩臺後，3臺機器虛擬組成一個集羣后，對外處理請求能夠提高到300*80%=240
  2.採用微服務架構，後續微服務架構高可用會詳細描述

Web應用層面（優化應用程序）

• 提升單個請求的處理速度，如上若是處理一個請求消耗從1s下降到0.5秒，併發就是200
• 耗時業務同步根據業務狀況 使用mq異步處理
• 好比導入、導出耗時耗力 合理使用多線程批量處理、指向單臺應用獨立處理
• 高效使用緩存，減小鎖的使用範圍
• 優化訪問數據庫SQL
• 儘可能避免遠程調用、大量I/O等耗時操做
• 合理規劃事物等比較耗資源操做
• 部分業務考慮採用預計算處理，減小實時計算耗資源操做 如：報表
• 不要盲目使用RPC、netty、http遠程網絡調用，如需特定調用注意加上超時時間

數據庫層面

• 合理使用數據庫引擎 如 mysql的InnoDB和MyISAM引擎
• 數據庫系統參數配置優化
• 特殊複雜計算耗時操做能夠考慮使用存儲過程來處理
• 數據庫集羣，進行讀寫分離
• 合理設計數據庫表結構、索引 如（組合索引）
• 分庫、分區、分表降到單庫單表併發量
• 合理使用Nosql，如傳統、分佈式數據庫共存，根據數據特性合理存放（hbase、hive、mongoDB）

總結：

高併發並不僅是單一渠道等問題，本文主要講述高併發涉及場景等具體詳細優化思路。
優化原則 分析定位哪一個環節鏈路是高併發瓶頸，進行優化分而治之，最終提升請求處理速度。
筆者建議優化順序以下
1.web應用層面 核心優化web應用層面，80%高併發等問題都和低效應用程序有關係。
2.web服務器層面
3.客戶端層面
4.nginx層面
5.varnish層面
6.數據庫層面

做者簡介：張程 技術研究

更多文章請關注微信公衆號：zachary分解獅 (frankly0423)