高併發業務除了需要有支撐高併發的服務器架構，還需要根據業務需求和架構體系。
.
設計出合理的開發方案，這裏根據一個實踐過業務場景分析開發思路，羅列出高併發接口需要注意的點，以及設計上的巧思，共勉之，望共鳴
.
業務場景
業務：今日好貨
.
交互端：IOS/Andorid
.
需求點：（實際業務會複雜些，爲了容易理解，這裏簡化需求點）
提供最新的好貨商品信息列表，支持分頁
.
需要時時獲取最新的商品數據列表，以下情況商品信息會發生變化
● 品數據字段更新(人爲編輯，熱度字段更新，等)
● 不定時上新，在固定時段會有大量商品更新(目前 10點/20點上新量大)
● 商品在會在規律時間裏重新排序(根據：銷量，曝光量，點擊量 等計算排序)
.
商品加載過程中不能出現重複商品
.
客戶端和服務端需要考慮加載商品的交互體驗
.
終極目標：
支持高併發下業務穩定
.
設計思路
.
前提：
【商品服務API】：通過商品服務提供的API獲取商品數據，當商品有上新、字段更新、排序有更新時，通過API都可以獲取到最新的數據(db查詢，支持獲取未來時間裏的商品數據)
.
緩存使用 Redis
.
緩存更新分析：
● 商品數據緩存到Redis：支撐高併發的查詢業務，數據需要進行緩存
.
● 提供商品緩存刷新接口：商品顯示需要即時性，需要時時展示最新數據，當商品發生變化的時候，我們需要刷新商品緩存數據
.
● 支持未來時間緩存提前更新：爲了更好支撐即時性，尤其在固定時段商品的大量上新，緩存更新會比較慢，所以我們需要提前備好未來時間的緩存數據
.
● 緩存刷新需要注意點：緩存更新的過程中不能出現前臺無數據展示的情況
.
● 商品緩存支持版本號區分：每次緩存更新都要生成一個新的數據版本號緩存Key，數據存儲在對應的緩存版本Key裏
.
● 緩存版本Key存儲到列表 ：列表可以用來篩選出當前時間可以使用的最新版本號
.
商品緩存更新設計：
接口參數：updatetime【更新時間】(可空)，默認等於當前時間，可以傳未來時間
.
每次刷新緩存都會生成新的數據版本號作爲【商品緩存Key名】，將數據存到版本號對應的緩存Key中，所以需要生成一個唯一字符串，這裏我們把【更新時間】的時間戳作爲緩存的Key名，爲何這麼設計，後面會介紹到
.
首先請求【商品服務API】獲取【更新時間】對應的商品數據，接着對數據進行字段處理、排序，最後把最終商品數據更新到【商品緩存Key名】的Redis SortedSet中
.
商品緩存成功後，把【商品緩存Key名】存到【版本號集合】Redis SortedSet中，同時把【更新時間】的時間戳作爲排序的值
.【商品緩存Key名】=【更新時間】的時間戳，這個設計的目的是可以支持未來時間版本數據的提前更新，並且可以通過SortedSet排序，過濾出當前時間最新的版本號
.
緩存結構圖
.
今日好貨API設計：
接口參數：version：數據版本號(可空)，pageindex：頁碼
.
響應JSON數據：Datas：商品數據集合，CurrentVersion：當前數據版本號
.
【當前最新版本號】：【版本號集合】通過SortedSet機制，獲取當前時間能夠使用的數據版本號，
如：取[當前時間戳]-[(當前時間-1h)時間戳]區間的版本號，排序後獲取離當前時間最近的版本號作爲最新版本號 <這裏爲何取區間，而不是直接取最新版本號，會有個容錯處理，後面會說到>
.
用戶在瀏覽商品的時候客戶端請求【今日好貨API】需要上傳版本號和頁數，如果是第一次(pageindex=1，首頁)，會獲取【當前最新版本號】，然後返回最新商品數據
.
客戶端本地緩存首頁數據返回的版本號，後續翻頁需要客戶端上報緩存的版本號，API返回版本號對應的商品分頁數據，這樣設計的目的是當用戶繼續加載後面頁數數據的時候不會出現重複的數據(數據會不定時更新，避免用戶加載到重複的數據，如：商品A原來是第一頁數據，數據更新後變成第二頁數據)
.
當請求首頁數據，客戶端上報的版本號=【當前最新版本號】，就不進行數據緩存查詢，直接返回空數據（數據不變），客服端無需重新渲染商品列表，同時可以避免無限下拉刷新帶來的服務器壓力
.
如果version參數沒有上傳，獲取【當前最新版本號】和當前最新數據返回，數據版本號參數有上傳，就獲取對應版本號的分頁數據
.
其他注意點：
.
版本號無限累加
【版本號集合】隨着時間增長，版本號數據會不斷累加，需要在每次更新的時候刪除掉最近一天的版本，操作 SortedSet 過濾掉比(當前時間-1天)的時間戳小的版本號
.
容錯處理
獲取【當前最新版本號】的時候，操作 【版本號集合】集合，獲取最近一個小時的，即操作SortedSet[當前時間戳]至[(當前時間-1h)時間戳]範圍內的版本號，然後從大到小排序版本號，過濾出版本號，並且有版本號相對於的商品數據，如果不存在商品數據，就往下遍歷，直到有符合規則的版本號返回
.
雙11模式：
.
一級緩存
將商品數據短暫的緩存到站點服務區Cache中
.
降級方案：
.
● 資源監控，自動降級
● 開啓降級方案後，客服端會從cdn中拉取商品數據
● 商品分頁數據生成JSON數據文件存儲到cdn中
.
架構圖
.
總結
以上舉例的高併發接口設計的實踐方案，有些設計可能比較針對此業務場景，但是思路是有共性的，重點在於理解設計上的思路
.
高併發接口的開發需要考慮因素:
● 接口性能
● 接口的穩定
● 容錯機制
● 服務端壓力：竟可能減少服務端壓力，可以與客戶端交互配合
● 服務降級：資源高壓力的情況下進行降級
.
有任何想說的請留言哦
轉載請申明原文地址，謝謝合作
.
感謝你的支持，我會繼續努力！~
