參考鏈接

?

高并發經常會發生在有大活躍用戶量，用戶高聚集的業務場景中。為了讓業務可以流暢的運行并且給用戶一個好的交互體驗，我們需要根據業務場景預估達到的并發量等因素，來設計適合自己業務場景的高并發處理方案。

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

高并發相關的業務，需要進行并發的測試，通過大量的數據分析評估出整個架構可以支撐的并發量。

服務器架構圖：

?

查詢是優先查詢緩存，如果緩存不存在，再進行DB查詢，將查詢結果緩存起來。例如，用戶訂單：這里我們只緩存用戶第一頁的訂單信息，一頁40條數據，用戶一般也只會看第一頁的訂單數據用戶訪問訂單列表，如果是第一頁讀緩存，如果不是讀DB計算出用戶分布的key,redis hash中查找用戶訂單信息，如果查詢到用戶訂單信息，返回訂單信息。如果不存在就進行DB查詢第一頁的訂單數據，然后緩存redis，返回訂單信息。

秒殺類業務時候就會使用消息隊列的，可以將參與用戶的信息添加到消息隊列中，然后再寫個多線程程序去消耗隊列，給隊列中的用戶發放紅包。

一級緩存就是使用站點服務器緩存去存儲數據，注意只存儲部分請求量大的數據，并且緩存的數據量要控制，不能過分的使用站點服務器的內存而影響了站點應用程序的正常運行，一級緩存需要設置秒單位的過期時間，具體時間根據業務場景設定，目的是當有高并發請求的時候可以讓數據的獲取命中到一級緩存，而不用連接緩存nosql數據服務器，減少nosql數據服務器的壓力。數據不會頻繁的更新，像這種接口的請求量比較大就可以加入一級緩存。

靜態化數據：高并發請求數據不變化的情況下如果可以不請求自己的服務器獲取數據那就可以減少服務器的資源壓力。對于更新頻繁度不高，并且數據允許短時間內的延遲，可以通過數據靜態化成JSON，XML,HTML等數據文件上傳CDN，在拉取數據的時候優先到CDN拉取，如果沒有獲取到數據再從緩存，數據庫中獲取，當管理人員操作后臺編輯數據再重新生成靜態文件上傳同步到CDN，這樣在高并發的時候可以使數據的獲取命中在CDN服務器上。由于同步有延遲性，需找一個靠譜的服務器商。

其他方案，對于更新頻繁度不高的數據，可以緩存數據到本地，然后每次請求接口的時候上傳當前緩存數據的版本號，服務端接收到版本號判斷版本號與最新數據版本號是否一致，如果不一樣就進行最新數據的查詢并返回最新數據和最新版本號，如果一樣就返回狀態碼告知數據已經是最新。

?

轉載于:https://www.cnblogs.com/watm/p/11038212.html

總結

以上是生活随笔為你收集整理的架构阅读笔记14的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。