在APP開發(fā)中，一般小項目對高并發(fā)的要求不是很高，但是對于一些用戶量大的大型項目，對系統(tǒng)高并發(fā)的支持就要重視了。業(yè)務(wù)從發(fā)展的初期到逐漸成熟，服務(wù)器架構(gòu)也是從相對單一到集群，再到分布式服務(wù)。一個可以支持高并發(fā)的服務(wù)少不了好的服務(wù)器架構(gòu)，需要有均衡負載，數(shù)據(jù)庫需要主從集群，nosql緩存需要主從集群，靜態(tài)文件需要上傳cdn，這些都是能讓業(yè)務(wù)程序流暢運行的強大后盾。
 

高并發(fā)相關(guān)的業(yè)務(wù)，需要進行并發(fā)的測試，通過大量的數(shù)據(jù)分析評估出整個架構(gòu)可以支撐的并發(fā)量。
測試高并發(fā)可以使用第三方服務(wù)器或者自己測試服務(wù)器，利用測試工具進行并發(fā)請求測試，分析測試數(shù)據(jù)得到可以支撐并發(fā)數(shù)量的評估，這個可以作為一個預(yù)警參考，俗話說知己自彼百戰(zhàn)不殆。
 

在一個訂單處理的場景中，服務(wù)器架構(gòu)如下圖所示：

場景中的這些業(yè)務(wù)基本是用戶進入APP后會操作到的，除了活動日(618,雙11，等)，這些業(yè)務(wù)的用戶量都不會高聚集，同時這些業(yè)務(wù)相關(guān)的表都是大數(shù)據(jù)表，業(yè)務(wù)多是查詢操作，所以我們需要減少用戶直接命中DB的查詢；優(yōu)先查詢緩存，如果緩存不存在，再進行DB查詢，將查詢結(jié)果緩存起來。

更新用戶相關(guān)緩存需要分布式存儲，比如使用用戶ID進行hash分組，把用戶分布到不同的緩存中，這樣一個緩存集合的總量不會很大，不會影響查詢效率。
 

以上例子是一個相對簡單的高并發(fā)架構(gòu)，并發(fā)量不是很高的情況可以很好的支撐，但是隨著業(yè)務(wù)的壯大，用戶并發(fā)量增加，我們的架構(gòu)也會進行不斷的優(yōu)化和演變，比如對業(yè)務(wù)進行服務(wù)化，每個服務(wù)有自己的并發(fā)架構(gòu)，自己的均衡服務(wù)器，分布式數(shù)據(jù)庫，nosql主從集群，如：用戶服務(wù)、訂單服務(wù)。
 

對于更新頻繁度不高的數(shù)據(jù)，APP,PC瀏覽器，可以緩存數(shù)據(jù)到本地，然后每次請求接口的時候上傳當前緩存數(shù)據(jù)的版本號，服務(wù)端接收到版本號判斷版本號與最新數(shù)據(jù)版本號是否一致，如果不一樣就進行最新數(shù)據(jù)的查詢并返回最新數(shù)據(jù)和最新版本號，如果一樣就返回狀態(tài)碼告知數(shù)據(jù)已經(jīng)是最新。