閱讀支付寶架構師眼中的高併發架構

      沒有閱讀文章在以前，本身對高併發的見解：就是不少用戶同時操做，業務場景爲相似：天貓618活動，淘寶雙十一活動。有可能形成服務器癱瘓，爲了解決這一問題，採用分佈式服務器以及分佈式數據庫的高併發架構。

     經過閱讀支付寶架構師眼中的高併發架構發現了還有不少東西須要學習，高併發架構目的是爲了讓業務能夠流暢的運行而且給用戶一個好的交互體驗，咱們須要根據業務場景預估達到的併發量等因素，來設計適合本身業務場景的高併發處理方案。從而瞭解服務器架構：

• 服務器

• 均衡負載(如：nginx，阿里雲SLB)

• 資源監控

• 分佈式

數據庫架構：

      

• 主從分離，集羣

• DBA 表優化，索引優化，等

• 分佈式

• nosql

• 主從分離，集羣

• 主從分離，集羣

• 主從分離，集羣

• redis

• mongodb

• memcache

• cdn

• html

• css

• js

• image

併發測試:高併發相關的業務，須要進行併發的測試，經過大量的數據分析評估出整個架構能夠支撐的併發量。採用第三方服務

 

如下爲服務器架構圖：

分層，分割，分佈式

• 分層

• 將系統在橫向維度上切分紅幾個部分，每一個部門負責一部分相對簡單並比較單一的職責，而後經過上層對下層的依賴和調度組成一個完整的系統

• 好比把電商系統分紅：應用層，服務層，數據層。(具體分多少個層次根據本身的業務場景)

• 應用層：網站首頁，用戶中心，商品中心，購物車，紅包業務，活動中心等，負責具體業務和視圖展現

• 服務層：訂單服務，用戶管理服務，紅包服務，商品服務等，爲應用層提供服務支持

• 數據層：關係數據庫，nosql數據庫 等，提供數據存儲查詢服務

• 分層架構是邏輯上的，在物理部署上能夠部署在同一臺物理機器上，可是隨着網站業務的發展，必然須要對已經分層的模塊分離部署，分別部署在不一樣的服務器上，使網站能夠支撐更多用戶訪問

• 分割

• 在縱向方面對業務進行切分，將一塊相對複雜的業務分割成不一樣的模塊單元

• 包裝成高內聚低耦合的模塊不只有助於軟件的開發維護，也便於不一樣模塊的分佈式部署，提升網站的併發處理能力和功能擴展

• 好比用戶中心能夠分割成：帳戶信息模塊，訂單模塊，充值模塊，提現模塊，優惠券模塊等

 

• 分佈式

• 分佈式應用和服務,將分層或者分割後的業務分佈式部署，獨立的應用服務器，數據庫，緩存服務器

• 當業務達到必定用戶量的時候，再進行服務器均衡負載，數據庫，緩存主從集羣

• 分佈式靜態資源，好比：靜態資源上傳cdn

• 分佈式計算，好比：使用hadoop進行大數據的分佈式計算

• 分佈式數據和存儲,好比：各分佈節點根據哈希算法或其餘算法分散存儲數據

異步

 

在高併發業務中若是涉及到數據庫操做，主要壓力都是在數據庫服務器上面，雖然使用主從分離，可是數據庫操做都是在主庫上操做，單臺數據庫服務器鏈接池容許的最大鏈接數量是有限的 

 當鏈接數量達到最大值的時候，其餘須要鏈接數據操做的請求就須要等待有空閒的鏈接，這樣高併發的時候不少請求就會出現connection time out 的狀況 

 

 

緩存

 

高併發業務接口多數都是進行業務數據的查詢，如：商品列表，商品信息，用戶信息，紅包信息等，這些數據都是不會常常變化，而且持久化在數據庫中

 高併發的狀況下直接鏈接從庫作查詢操做，多臺從庫服務器也抗不住這麼大量的鏈接請求數（單臺數據庫服務器容許的最大鏈接數量是有限的）

總結：經過今天的學習瞭解了高併發架構是一個不斷衍化的過程，須要不少東西相互輔助，基本上採用分佈式架構。從服務器架構圖上能夠詳細瞭解整個服務器的結構。從此應多多學習關於高併發方面的知識。