大型項目APP開發如何做好高并發

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

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

在一個訂單處理的場景中，服務器架構如下圖所示：

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

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

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

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