高併發業務接口開發思路(實戰)

時間 2019-11-13

標籤併發業務接口開發思路實戰简体版

原文原文鏈接

業務場景

業務：
- 今日好貨
交互端：
- 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)時間戳]範圍內的版本號，而後從大到小排序版本號，過濾出版本號，而且有版本號相對於的商品數據，若是不存在商品數據，就往下遍歷，直到有符合規則的版本號返回