這篇文章帶給大家的內容是關於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，返回簽到訊息
注意
這裡會有並發情況下的邏輯問題，如：一天簽到多次，發放多次積分給使用者。
我的部落格文章[大話程式猿眼裡的高並發]有相關的處理方案。
用戶訂單
這裡我們只快取用戶第一頁的訂單信息，一頁40條數據，用戶一般也只會看第一頁的訂單數據
用戶存取訂單列表，如果是第一頁讀取緩存，如果不是讀DB
計算用戶分佈的key,redis hash中查找用戶訂單資訊
如果查詢到用戶訂單信息，返回訂單信息
如果不存在就進行DB查詢第一頁的訂單數據，然後緩存redis，返回訂單信息
用戶中心
計算出用戶分佈的key ,redis hash中查找用戶訂單資訊
如果查詢到用戶信息，返回用戶資訊
#如果不存在進行用戶DB查詢，然後緩存redis，返回用戶資訊
其他業務
以上例子是一個相對簡單的高並發架構，並發量不是很高的情況可以很好的支撐，但是隨著業務的壯大，用戶並發量增加，我們的架構也會進行不斷的最佳化和演變，例如對業務進行服務化，每個服務有自己的並發架構，自己的均衡伺服器，分散式資料庫，nosql主從集群，如：用戶服務、訂單服務;
訊息佇列
秒殺、秒搶等活動業務，使用者在瞬間湧入產生高並發請求
場景：定時領取紅包，等
伺服器架構圖：
#說明：
場景中的定時領取是一個高並發的業務，像秒殺活動用戶會在到點的時間湧入，DB瞬間就接受到一記暴擊，hold不住就會宕機，然後影響整個業務;
像這種不是只有查詢的操作並且會有高並發的插入或更新資料的業務，前面提到的通用方案就無法支撐，並發的時候都是直接命中DB;
設計這塊業務的時候就會使用訊息佇列的，可以將參與使用者的信息加入到訊息佇列中，然後再寫個多執行緒程式去消耗佇列，給佇列中的使用者發放紅包;
方案如：
定時領取紅包
一般習慣使用redis的list
當使用者參與活動，將使用者參與資訊push到佇列中
然後寫個多線程程式去pop數據，進行發放紅包的業務
這樣可以支援高並發下的用戶可以正常的參與活動，並且避免資料庫伺服器宕機的危險
一級快取
高並發請求連線快取伺服器超出伺服器能夠接收的請求連線量，部分使用者出現建立連線逾時無法讀取到資料的問題;
因此需要有個方案當高並發時候時候可以減少命中快取伺服器;
這時候就出現了一級快取的方案，一級快取就是使用網站伺服器快取去儲存數據，注意只儲存部分請求量大的數據，並且緩存的數據量要控制，不能過分的使用站點伺服器的內存而影響了站點應用程序的正常運行，一級緩存需要設置秒單位的過期時間，具體時間根據業務場景設定，目的是當有高並發請求的時候可以讓資料的獲取命中到一級緩存，而不用連接緩存nosql數據伺服器，減少nosql數據伺服器的壓力
比如APP首屏商品數據接口，這些數據是公共的不會針對使用者自定義，而且這些資料不會頻繁的更新，像這種介面的請求量比較大就可以加入一級快取;
##伺服器架構圖：
合理的規格和使用nosql快取資料庫，根據業務拆分快取資料庫的集群，這樣基本上可以很好支援業務，一級緩存畢竟是使用網站伺服器快取所以還是要善用。
靜態化資料
高並發請求資料不變化的情況下如果可以不請求自己的伺服器取得資料那就可以減少伺服器的資源壓力。
對於更新頻繁度不高，且資料允許短時間內的延遲，可以透過資料靜態化成JSON，XML,HTML等資料檔案上傳CDN，在拉取資料的時候優先到CDN拉取，如果沒有取得到資料再從緩存，資料庫中獲取，當管理人員操作後台編輯資料再重新產生靜態檔案上傳同步到CDN，這樣在高並發的時候可以使資料的取得命中在CDN伺服器上。 CDN節點同步有一定的延遲性，所以找一個可靠的CDN伺服器商也很重要。
以上是Java高並發架構設計的介紹（圖文）的詳細內容。更多資訊請關注PHP中文網其他相關文章！
