JAVA架構師眼中的高併發架構，分佈式架構 應用服務器集羣

JAVA架構師眼中的高併發架構，分佈式架構 應用服務器集羣

前言

 

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

 

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

 

在電商相關產品開發的這些年，我有幸的遇到了併發下的各類坑，這一路摸爬滾打過來有着很多的血淚史，這裏進行的總結，做爲本身的歸檔記錄，同時分享給你們。

 

服務器架構

 

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

 

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

 

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

 

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

 

• 服務器

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

  • 資源監控

  • 分佈式

• 數據庫

  • 主從分離，集羣

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

  • 分佈式

• nosql

  • 主從分離，集羣

  • 主從分離，集羣

  • 主從分離，集羣

  • redis

  • mongodb

  • memcache

• cdn

  • html

  • css

  • js

  • image

 

併發測試

 

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

 

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

 

第三方服務：

 

• 阿里雲性能測試

 

併發測試工具：

 

• Apache JMeter

• Visual Studio性能負載測試

• Microsoft Web Application Stress Tool

 

實戰方案

 

通用方案

 

日用戶流量大，可是比較分散，偶爾會有用戶高聚的狀況；

 

場景： 用戶簽到，用戶中心，用戶訂單，等

 

服務器架構圖：

說明：

 

場景中的這些業務基本是用戶進入APP後會操做到的，除了活動日(618,雙11，等)，這些業務的用戶量都不會高彙集，同時這些業務相關的表都是大數據表，業務可能是查詢操做，因此咱們須要減小用戶直接命中DB的查詢；優先查詢緩存，若是緩存不存在，再進行DB查詢，將查詢結果緩存起來。

 

更新用戶相關緩存須要分佈式存儲，好比使用用戶ID進行hash分組，把用戶分佈到不一樣的緩存中，這樣一個緩存集合的總量不會很大，不會影響查詢效率。

 

方案如：

 

• 用戶簽到獲取積分

  • 計算出用戶分佈的key,redis hash中查找用戶今日簽到信息

  • 若是查詢到簽到信息，返回簽到信息

  • 若是沒有查詢到，DB查詢今日是否簽到過，若是有簽到過，就把簽到信息同步redis緩存。

  • 若是DB中也沒有查詢到今日的簽到記錄，就進行簽到邏輯，操做DB添加今日簽到記錄，添加簽到積分(這整個DB操做是一個事務)

  • 緩存簽到信息到redis，返回簽到信息

  • 注意這裏會有併發狀況下的邏輯問題，如：一天簽到屢次，發放屢次積分給用戶。

  • 個人博文《大話程序猿眼裏的高併發》（http://blog.thankbabe.com/2016/04/01/high-concurrency/）有相關的處理方案。

 

用戶訂單

• 這裏咱們只緩存用戶第一頁的訂單信息，一頁40條數據，用戶通常也只會看第一頁的訂單數據

• 用戶訪問訂單列表，若是是第一頁讀緩存，若是不是讀DB

• 計算出用戶分佈的key,redis hash中查找用戶訂單信息

• 若是查詢到用戶訂單信息，返回訂單信息

• 若是不存在就進行DB查詢第一頁的訂單數據，而後緩存redis，返回訂單信息

 

用戶中心

• 計算出用戶分佈的key,redis hash中查找用戶訂單信息

• 若是查詢到用戶信息，返回用戶信息

• 若是不存在進行用戶DB查詢，而後緩存redis，返回用戶信息

 

其餘業務

• 上面例子可能是針對用戶存儲緩存，若是是公用的緩存數據須要注意一些問題，以下

• 注意公用的緩存數據須要考慮併發下的可能會致使大量命中DB查詢，可使用管理後臺更新緩存，或者DB查詢的鎖住操做。

• 個人博文《大話Redis進階》（http://blog.thankbabe.com/2016/08/05/redis-up/）對更新緩存問題和推薦方案的分享。

 

以上例子是一個相對簡單的高併發架構，併發量不是很高的狀況能夠很好的支撐，可是隨着業務的壯大，用戶併發量增長，咱們的架構也會進行不斷的優化和演變，好比對業務進行服務化，每一個服務有本身的併發架構，本身的均衡服務器，分佈式數據庫，nosql主從集羣，如：用戶服務、訂單服務；

 

消息隊列

 

秒殺、秒搶等活動業務，用戶在瞬間涌入產生高併發請求

 

場景：定時領取紅包，等

 

服務器架構圖：

說明：

 

場景中的定時領取是一個高併發的業務，像秒殺活動用戶會在到點的時間涌入，DB瞬間就接受到一記暴擊，hold不住就會宕機，而後影響整個業務；

 

像這種不是隻有查詢的操做而且會有高併發的插入或者更新數據的業務，前面提到的通用方案就沒法支撐，併發的時候都是直接命中DB；

 

設計這塊業務的時候就會使用消息隊列的，能夠將參與用戶的信息添加到消息隊列中，而後再寫個多線程程序去消耗隊列，給隊列中的用戶發放紅包；

 

方案如：

 

• 定時領取紅包

  • 通常習慣使用 redis的 list

  • 當用戶參與活動，將用戶參與信息push到隊列中

  • 而後寫個多線程程序去pop數據，進行發放紅包的業務

  • 這樣能夠支持高併發下的用戶能夠正常的參與活動，而且避免數據庫服務器宕機的危險

 

附加： 

 

經過消息隊列能夠作不少的服務。 

 

如：定時短信發送服務，使用sset(sorted set)，發送時間戳做爲排序依據，短信數據隊列根據時間升序，而後寫個程序定時循環去讀取sset隊列中的第一條，當前時間是否超過發送時間，若是超過就進行短信發送。

 

一級緩存

 

高併發請求鏈接緩存服務器超出服務器可以接收的請求鏈接量，部分用戶出現創建鏈接超時沒法讀取到數據的問題；

 

所以須要有個方案當高併發時候時候能夠減小命中緩存服務器；

 

這時候就出現了一級緩存的方案，一級緩存就是使用站點服務器緩存去存儲數據，注意只存儲部分請求量大的數據，而且緩存的數據量要控制，不能過度的使用站點服務器的內存而影響了站點應用程序的正常運行，一級緩存須要設置秒單位的過時時間，具體時間根據業務場景設定，目的是當有高併發請求的時候可讓數據的獲取命中到一級緩存，而不用鏈接緩存nosql數據服務器，減小nosql數據服務器的壓力

 

好比APP首屏商品數據接口，這些數據是公共的不會針對用戶自定義，並且這些數據不會頻繁的更新，像這種接口的請求量比較大就能夠加入一級緩存；

 

服務器架構圖：

 

合理的規範和使用nosql緩存數據庫，根據業務拆分緩存數據庫的集羣，這樣基本能夠很好支持業務，一級緩存畢竟是使用站點服務器緩存因此仍是要善用。

 

靜態化數據

 

高併發請求數據不變化的狀況下若是能夠不請求本身的服務器獲取數據那就能夠減小服務器的資源壓力。

 

對於更新頻繁度不高，而且數據容許短期內的延遲，能夠經過數據靜態化成JSON，XML,HTML等數據文件上傳CDN，在拉取數據的時候優先到CDN拉取，若是沒有獲取到數據再從緩存，數據庫中獲取，當管理人員操做後臺編輯數據再從新生成靜態文件上傳同步到CDN，這樣在高併發的時候可使數據的獲取命中在CDN服務器上。

 

CDN節點同步有必定的延遲性，因此找一個靠譜的CDN服務器商也很重要

 

其餘方案

 

• 對於更新頻繁度不高的數據，APP,PC瀏覽器，能夠緩存數據到本地，而後每次請求接口的時候上傳當前緩存數據的版本號，服務端接收到版本號判斷版本號與最新數據版本號是否一致，若是不同就進行最新數據的查詢並返回最新數據和最新版本號，若是同樣就返回狀態碼告知數據已是最新。減小服務器壓力：資源、帶寬

 

針對上面的技術我特地整理了一下，有不少技術不是靠幾句話能講清楚，因此乾脆找朋友錄製了一些視頻，不少問題其實答案很簡單，可是背後的思考和邏輯不簡單，要作到知其然還要知其因此然。若是想學習Java工程化、高性能及分佈式、深刻淺出。微服務、Spring，MyBatis，Netty源碼分析的朋友能夠加我微信進羣：emprere，羣裏有阿里大牛直播講解技術，以及Java大型互聯網技術的視頻免費分享給你們。

 

分層，分割，分佈式

 

大型網站要很好支撐高併發，這是須要長期的規劃設計 

 

在初期就須要把系統進行分層，在發展過程當中把核心業務進行拆分紅模塊單元，根據需求進行分佈式部署，能夠進行獨立團隊維護開發。

 

• 分層

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

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

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

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

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

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

 

分割

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

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

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

 

分佈式

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

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

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

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

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

 

 

網站分層-圖1來自網絡

 

集羣

 

對於用戶訪問集中的業務獨立部署服務器，應用服務器，數據庫，nosql數據庫。 核心業務基本上須要搭建集羣，即多臺服務器部署相同的應用構成一個集羣，經過負載均衡設備共同對外提供服務， 服務器集羣可以爲相同的服務提供更多的併發支持，所以當有更多的用戶訪問時，只須要向集羣中加入新的機器便可, 另外能夠實現當其中的某臺服務器發生故障時，能夠經過負載均衡的失效轉移機制將請求轉移至集羣中其餘的服務器上，所以能夠提升系統的可用性

 

• 應用服務器集羣

  • nginx 反向代理

  • slb

  • … …

• (關係/nosql)數據庫集羣

  • 主從分離，從庫集羣