閱讀之支付寶高併發架構

 

高併發常常會發生在有大活躍用戶量，用戶高彙集的業務場景中，如：秒殺活動，定時領取紅包等。

爲了讓業務能夠流暢的運行而且給用戶一個好的交互體驗，咱們須要根據業務場景預估達到的併發量等因素，來設計適合本身業務場景的高併發處理方案。

服務器架構

 

業務從發展的初期到逐漸成熟，服務器架構也是從相對單一到集羣，再到分佈式服務。 

一個能夠支持高併發的服務少不了好的服務器架構，須要有均衡負載，數據庫須要主從集羣，nosql緩存須要主從集羣，靜態文件須要上傳cdn，這些都是能讓業務程序流暢運行的強大後盾。

 

服務器這塊可能是須要運維人員來配合搭建，具體我就很少說了，點到爲止。

大體須要用到的服務器架構以下：

 

服務器

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

資源監控

分佈式

數據庫

主從分離，集羣

DBA 表優化，索引優化，等

分佈式

nosql

主從分離，集羣

主從分離，集羣

主從分離，集羣

redis

mongodb

memcache

cdn

html

css

js

image

 

併發測試

 

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

測試高併發可使用第三方服務器或者本身測試服務器，利用測試工具進行併發請求測試，分析測試數據獲得能夠支撐併發數量的評估，這個能夠做爲一個預警參考，俗話說知己自彼百戰不殆。

第三方服務：

阿里雲性能測試

併發測試工具：

Apache JMeter

Visual Studio性能負載測試

Microsoft Web Application Stress Tool

實戰方案

面向服務

SOA面向服務架構設計

微服務更細粒度服務化，一系列的獨立的服務共同組成系統

使用服務化思惟，將核心業務或者通用的業務功能抽離成服務獨立部署，對外提供接口的方式提供功能。

最理想化的設計是能夠把一個複雜的系統抽離成多個服務，共同組成系統的業務，優勢：鬆耦合，高可用性，高伸縮性，易維護。

經過面向服務化設計，獨立服務器部署，均衡負載，數據庫集羣，可讓服務支撐更高的併發

 

服務例子：

用戶行爲跟蹤記錄統計

 

說明：

經過上報應用模塊，操做事件，事件對象，等數據，記錄用戶的操做行爲

好比：記錄用戶在某個商品模塊，點擊了某一件商品，或者瀏覽了某一件商品

 

背景：

因爲服務須要記錄用戶的各類操做行爲，而且能夠重複上報，準備接入服務的業務又是核心業務的用戶行爲跟蹤，因此請求量很大，高峯期會產生大量併發請求。

 

架構：

nodejs WEB應用服務器均衡負載

redis主從集羣

mysql主

nodejs+express+ejs+redis+mysql

服務端採用nodejs,nodejs是單進程（PM2根據cpu核數開啓多個工做進程），採用事件驅動機制，適合I/O密集型業務，處理高併發能力強

 

業務設計：

併發量大，因此不能直接入庫，採用：異步同步數據,消息隊列

請求接口上報數據，接口將上報數據push到redis的list隊列中

nodejs寫入庫腳本，循環pop redis list數據，將數據存儲入庫，並進行相關統計Update，無數據時sleep幾秒

由於數據量會比較大，上報的數據表按天命名存儲

 

接口：

上報數據接口

統計查詢接口

上線跟進：

服務業務基本正常

天天的上報表有上千萬的數據

冗餘，自動化

 

當高併發業務所在的服務器出現宕機的時候，須要有備用服務器進行快速的替代，在應用服務器壓力大的時候能夠快速添加機器到集羣中，因此咱們就須要有備用機器能夠隨時待命。 最理想的方式是能夠經過自動化監控服務器資源消耗來進行報警，自動切換降級方案，自動的進行服務器替換和添加操做等，經過自動化能夠減小人工的操做的成本，並且能夠快速操做，避免人爲操做上面的失誤。

 

冗餘

數據庫備份

備用服務器

自動化

自動化監控

自動化報警

自動化降級

作了備份數據並不表明就萬無一失了，咱們須要保證高可用性，首先備份是否正常進行，備份數據是否可用，須要咱們進行按期的檢查，或者自動化監控， 還有包括如何避免人爲上的操做失誤問題。

總結：高併發的架構適用方案有不少，在不一樣的業務場景下選擇合適的方案是必要的。