搶購系統設計與思考

搶購系統設計與思考
Simon Liang (YC)
業務導向與成本控制兼具的系統設計實例

大綱
● 業務需求
● 預期目標
● 設計思路
● 搶購系統主流程
● 功能模塊說明
● 資源架構說明
● 執行計畫建議
● 成效推估

業務需求
● 解決系統高流量時卡頓問題
● 銷售型態
○ 熱銷
○ 爆品
○ 限時搶購

預期目標
● 與既有系統結合
● 有效運用既有運算資源
● 一致性良好體驗
○ 賣場頁不卡頓, 不掛點
○ 爆品不影響其他商品銷售
○ 數量不超賣
○ 系統不掉單
● 維持公平性
● 具擴充性
● 高可用性

結合既有系統
● 減少管控成本
● 減少既有系統異動範圍
● 接受現況, 避開既有問題點

設計思路
● 既有流程分析
● 作法與成本效益
● 結合既有系統
● 動靜分離
● 逐層過濾
● 業務拆分
● 運算資源拆分
● 精簡流程

既有系統流程
● 熱點發散
● 邏輯堆疊
● 跨系統
● 共用資源

既有系統流程
Check A
Check B
Check A
Check B
Check C
Check D
Check A
Check B
Check C
Check D
Check E
Check F
● 熱點分散
● 邏輯堆疊
Refresh
Refresh
Refresh

既有資源配置思維
Shared
Resource
瀏覽賣場
結帳
購物車
資料填寫
xxxxx...
yyyy...
庫存管理
Shared
Resource
Shared
Resource
Scaling
Cloud service
with hugh
capacity
Shared Resource
(DynamoDB
BigQuery….)
● 共用運算資源, 互相影響, 擴展成本高
Auto scaling

成本效益
● 營收 = 銷售數量*單價 (限量商品數量固定)
● 成本 = 單位成本*參與人數 (隨人數增加)
● 潛在效益
○ 額外流量
○ 品牌關注
○ 媒體聲量
● 固定收益下，不斷擴大運算資源支撐流量，合乎成本效益原則?
● 需要使用相同成本，服務價值較低的流量?
● 將流量逐層過濾，以合理之運算資源配置，服務不同對象 (淺在客戶, 實際客戶,
湊熱鬧的鄉民, 來亂的)

系統資源配置思維
● 共享資源(Shared resource)在一定量級以上產品並不吃香
● 對稱式資源配置, 單一服務滿載即造成吞吐量瓶頸
● 設計思維
○ 適度業務拆分(Dedicated resource), 避免互相影響
○ 業務導向資源配置, 控制成本
○ 非對稱式資源配置, 提高乘載能力

● 一般賣場
○ EC
● 熱銷賣場
○ EC > 搶購系統 > 交換接口 > EC
● 搶購賣場
○ 搶購系統 > 交換接口 > EC
系統銜接方式
EC主系統
EC主系
統-結帳
搶購系統
交換接口

階層設計
賣場
• 導流入口, 靜態資訊呈現
• 可透過CDN橫向擴展
派卷
系統
• 發送號碼牌: 流量&人數管控
• 獨立資源, 避免影響其他服務
交換
接口
• 系統銜接, 資訊交換
• 安全驗證
EC主
系統
• 暨有購物流程
• 僅需處理限縮過之流量

逐層過濾
賣場
派卷系統
購物車
結帳
成單
流量高, 低精度
流量低, 高精度
200,000
100,000
2,000
1,700
1500
EC主系統
交換接口
搶購系統

賣場
派卷系統
購物車
結帳
成單
流量滲透與資源
Firewall & Load balance
來亂的
EC主系統
搶購系統
湊熱鬧鄉民淺在客戶實際客戶
流量單位
成本
輕量
擴充性高
低單位成本
可靠性高
合適成本
固定資源

搶購系統
a scaleble token-based system

設計思路
● 輕量快速為首要要求
● 單一職責拆分
● 非對稱式運算資源配置
● 單一對象服務設定
● 簡單可靠
● 運用合理資源對正常行為做查核; 即有水準以上精準度

搶購系統
● 賣場頁
○ CDN
● 派卷系統 (Ticket System)
○ Dedicated Resource
● 交換接口 (Exchange Gate)
● 管控系統
○ Dedicated Resource

賣場頁動靜分離(1/2)
● 靜態資料
○ 搜尋列
○ 左側目錄
○ 賣場介紹
○ 規格列表
● 動態資料
○ 會員登入
○ 購物車數量
○ 規格對應庫存量 (已售完字樣)

賣場頁動靜分離 (2/2)
● 靜態資料由CDN服務
○ Page html
○ css
○ js
○ image
● 動態資料由API取得
○ Realtime data
○ Semi-sync data

賣場頁與Sale Token
● CDN快取
○ CDN承載刷頁流量
○ 快取n分, 每n分取得新的頁面與Sale Token
● Sale Token
○ 與派卷系統溝通的必要參數
○ 動態產生, 內容加密
○ 時效內有用
○ 資訊組成
■ 賣場銷售規則
■ 庫存資訊
■ 有效時間
■ 驗證參數
CDN
EC主系統

派卷系統 Ticket System
● Token API : 驗證派號
● Ticket API : 以號換卷
● Verify API : Token驗證

Token機制
● 避免繞過
● 避免邏輯堆疊
● 輕量快速
● 安全性足夠高

查核項目
● 賣場規則
● 銷售規則
● 庫存狀況
● 流量控制
● 存取頻率

Token API與Client Token
● 人數把關
○ 基本銷售規則檢查
○ 緩流Ticket API
● 呼叫參數: Sale Token + Client Id + OrderInfo
● 回傳參數: Client Token
● Client Token
○ Time-based & Client-based
○ Client Id
○ 有效時間
○ 賣場編號
○ 驗證參數

Token API 流程
Token Rdis Redis

Ticket API與Ticket Token
● 銷量控管
○ 賣場庫存管理
○ 派發票劵&紀錄
● 呼叫參數: Sale Token + Client Token + OrderInfo
● 回傳參數: Tiket Token
● Ticket Token
○ Client Id
○ 賣場編號
○ 訂購資訊
○ 票劵資訊
○ 驗證參數

Ticket API 流程
Token Redis MySQL MySQL

時間分流策略
● 透過時間分流, 分散Ticket API的瞬間流量
● 於Token API 與 Ticket API 之間增加等待時間
● 設計重點
○ 由前端賣場頁控制
○ 單位等待時間需大於平均執行時間 (ex: 150 ms > 100ms)
○ 瞬間流量m, 區段數量n, 每一區段流量落在 m * (1 / n) ~ m 之間
○ 因Token API總量控管, 故Ticket API區段實際流量可能成階梯式減少

Exchange Gate 交換接口
● 位於EC主系統
● 銜接搶構系統&既有EC系統
● 需更嚴格要求之賣場, 可透過Verify API做驗證
● 主要角色
○ 流量過濾, 也可有分流之設計
○ 可存取既有EC資料庫, 做進一步查核
○ 避免繞過

管控系統
● 銷售管理機制
○ 與既有管理後台銜接
○ 同步銷售規則
○ 緩存管理
● 總量控管機制
○ 人數控管
○ 庫存銷量控管
● 監控系統
○ 服務監控
○ 負載狀態監控
○ 錯誤恢復

銷售管理機制思考 (1/3)
● 銷售規則同步會存在時間差
● 賣場頁, 派卷系統, EC主系統三者落差問題
● 如何控制資料同步的順序與時間點?
rule A賣場頁
派卷系統
EC主系統
rule A
rule A
rule A
rule B
因更新時間差可能造成規則互衝
rule B

rule A
賣場頁
派卷系統
EC主系統 rule B
rule A
U-A
rule B
rule B
rule A U-A
當銷售規則變化對使用者之影響
User currently with rule A
U-B User currently with rule B
rule A
rule B
rule B
U-A
U-B
U-A

● 順序性
○ 無法100%控制，但可以減少時間差
○ 流程可包裝
○ 定時更新&事件trigger
● 時間點
○ EC主系統加上時間版本概念，可減小影響 (延後升效)
○ 由EC主系統主控，方能統籌兩個分散系統的更新時機
○ 盡量不要在搶購過程中變更規則，對使用者體驗與公平性都不是很好

銷售管理機制設計
● 同時觸發減少時間差
● EC主系統trigger目標系統更
新機制
● 目標系統連回EC主系統取
得資料

總量管理機制思考
● 入口管理
○ 每個波次同步實際庫存量
● 票劵管理
○ 票劵可依各規格區分
○ 總量依實際庫存與設定參數決定
● 庫存管理
○ 實際庫存量
● 回補機制
○ 減少兩個系統相依性
○ Stock manager 程式於每個波次結束(wave)，取得最新的庫存量，並更新於派卷系統(Ticket
system)
○ wave 1 > refund > wave 2 > refund > wave n….

總量管理機制設計 (1/3)
賣場頁
Token API
Ticket API
購物車
結帳
async stock
async stock * traffic rate
async stock * sale rate
instant stock
exchange gate
white: 2000
black: 1000
30% additional traffic
white: 2000 * 1.3 = 2600
black: 1000 * 1.3 = 1300
10% additional quota
white: 2000 * 1.1 = 2200
black: 1000 * 1.1 = 1100
white: 2000
black: 1000
Initial

賣場頁
Token API
Ticket API
購物車
結帳
exchange gate
white: 2600-2600 = 0
black: 1300-800 = 500
white: 2200-2200 = 0
black: 1100-800 = 300
3000 client to EC system (maximum)
white: 2000
black: 1000
white: 2000 * 1.3 = 2600
black: 1000 * 1.3 = 1300
white: 2000 * 1.1 = 2200
black: 1000 * 1.1 = 1100
white: 2000
black: 1000
80% conversion rate
white: 2200 -(2200*0.8) = 440
black: 1100 -(800*0.8) = 460
Wave 1

賣場頁
Token API
Ticket API
購物車
結帳
exchange gate
white: 2600-2600 = 0
black: 1300-800 = 500
white: 2200-2200 = 0
black: 1100-800 = 300
80% conversion rate
white: 2200 -(2200*0.8) = 440
black: 1100 -(800*0.8) = 460
Wave 1 Refund
white: 440
black: 460
white: 440 * 1.3 = 572
black: 460 * 1.3 = 598
white: 440 * 1.1 = 484
black: 460 * 1.1 = 506
white: 440
black: 160
Wave 2
X mins

運算資源配置思維 (1/3)
● 呼應流量價值&成本概念
● 低價值流量，低成本處理
● 更高的銷售量
○ 持續性成長
○ 臨時性可預測
○ 突發性
來亂的湊熱鬧鄉民淺在客戶實際客戶
單位
成本
輕量
擴充性高
低單位成本
可靠性高
合適成本
固定資源

● 對稱式資源配置
○ 每個Request皆須經過Web server > Application server > Database > Cache server
○ 每個Request都能執行完畢，就必須要有成對的資源配置
○ 併發n個Reqeust, 就必須要有併發n個(甚至是3n)處理能力的 Web & Application & Database &
Cache
● 對稱式優點
○ Shared Reource下，可處理多種服務，資源利用度高
○ 服務套件設定難度低，基本調校容易
● 對稱式缺點
○ 細部調校難度高，無法設定最佳值，僅能設定合理最大值
○ 只要最弱的環節無法負荷，即會造成堵塞，進而崩潰
○ 為了撐量，成本自然高

● 非對稱式資源配置
○ 每個環節皆有其乘載能力上限 Web & Application & Database & Cache
○ 在任何一個環節達到設定上限，即禁止進入
● 非對稱式優點
○ 單一職責拆分下，可精確利用資源，吞吐量較容易推估
○ 確保了每個可服務的Request，皆有完整資源服務
○ 成本較低，且可控制在一定範圍內
● 非對稱式缺點
○ 僅能服務單一對象
○ 拆分調校較繁瑣
○ 額外的維護成本

運算資源配置
● 採單一職責+非對稱式資源配置
● 產線輸送帶原理：寧可失敗跳過，但不能阻塞輸送帶前進
○ 限制每個Request之最大執行時間
○ 限制每個Service最大連線數量
○ 限制每個Request最大記憶體使用量
● 調整設定值至最佳值，而非一昧調高設定值
● 設定須依循業務特性
○ 賣得完：同時處理數限制 = 同時可乘載併發數 >> 最大庫存數
○ 處理得完：最大執行時間限制 > 正常執行時間
○ 剩下overflow的都是低產值的流量

運算資源配置
● Seperate virtual host for each API (Token & Ticket)
● MySQL
○ max_connection
○ innodb_buffer_pool_size
● PHP-FPM
○ max_ children (pm=static)
○ max_excution_time (php.ini)
● Nginx
○ fastcgi_read_timeout
● Firewall & Load balance
○ limit session

運算資源配置
● 可能的錯誤
○ 504 Gateway Time-out
○ 502 Bad Gateway
○ 500 Too many connections
● 錯誤不等於錯誤，而是成本控制
● 透過nginx錯誤處理，統一回傳已售完Json
○ User無法得知背後發生了什麼事情，而這個Json可以讓他得到結果
○ 在設定得宜的狀況下，確實已售完，並無欺騙消費者
● 最大吞吐能力不再是依附最弱的Service，而能夠較接近最強的Service
● Nginx >>>> PHP-FPM > MySQL (write)
○ 只要nginx還活著，服務就活著

簡單測試
● 僅為簡單測試，但仍可看得出效果
● 服務機器位於Google Cloud Platformn，n1-standard-2 * 1 (WEB)，n1-
highmem-2 * 1 (DB)
● 測試機器: n1-highcpu-2 * 8 透過Vegeta壓測，4+2 執行 Apache bench ，
所有機器滿載測試
● 併發下，Token API超收率僅為0.13% (30039/30000)
● 中等流量狀況下, Token&Ticket API皆能穩定於60ms內處理完畢; 高流量
小於100ms
● 若加上適度時間分流, 反應速度會更穩定

系統運作與維護
● 擴充能力
○ 流量價值分級下，本身吞吐能力表現就不錯，擴充難度不高
○ 使用基本的方法，或是選用雲端服務就可解決
● 高可用性
● 錯誤恢復

Scalability
● Sale page
○ CDN
● Web & Application server
○ Load balance
○ Auto scaling with cloud service (EC2, GCE)
● Redis
○ official cluster
● Database
○ Percona cluster
○ Horizontal partition
○ Sharding

High Availability
● Sale page
○ CDN
● Web & Application server
○ Load balance
● Redis
○ official cluster
● Database
○ Percona cluster

整體檢視
● 透過搶購系統，EC主系統僅需處理過濾後的流量
● 單一職責拆分，避免互相干擾
● 搶購系統輕量化設計，本身有不錯的乘載能力
● 流量價值分級，配置對應運算資源，成本更低
● 非對稱式資源配置，控制成本，確保資源

後續思考
● 即便搶購系統將流量過濾，EC主系統與金流是否有乘載交易量的能力?
● EC主系統本身需要系統面的調整，達到一個更健康的狀態
● 系統拆分有他的好處，但伴隨的是交互狀況處理更複雜，對團隊會是個挑戰

搶購系統設計與思考

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to 搶購系統設計與思考

Similar to 搶購系統設計與思考 (20)

搶購系統設計與思考

Editor's Notes