高併發業務除了需要有支撐高併發的伺服器架構，還需要根據業務需求和架構體系，設計出合理的開發方案， 這裡根據一個實踐過業務場景分析開發思路，羅列出高併發介面需要注意的點，以及設計上的巧思，共勉之，望共鳴

業務場景

• 業務：
  • 今日好貨
• 互動端：
  • 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中

架構圖

總結

• 以上舉例的高併發介面設計的實踐方案，有些設計可能比較針對此業務場景，但是思路是有共性的，重點在於理解設計上的思路
• 高併發介面的開發需要考慮因素:
  • 介面效能
  • 介面的穩定
  • 容錯機制
  • 服務端壓力：竟可能減少服務端壓力，可以與客戶端互動配合
  • 服務降級：資源高壓力的情況下進行降級