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

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

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

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

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

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

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