秒殺系統有那麼複雜嗎？

限制流量

靜態資源

• 靜態資源怎麼得要上個CDN吧，要不買服務器也得花錢，還要配置，多麻煩
• 有了CDN，秒殺頁面的URL綁定個域名便可，其餘啥也不用配置

接口

• 網關總有限流功能吧，按需把80%流量直接返回搶購失敗消息，20%流量正常進入秒殺策略

至此，大部流量被稀釋了，如下進入正常的秒殺策略。

秒殺策略

本文采用了併發鎖，併發鎖更好的支持業務

併發鎖

• redis setnx
• 分佈式併發鎖

變量

• limit - 秒殺數量
• product - 商品惟一標籤
• project - 秒殺項目惟一標籤
• book - 實時產生的訂單表（uuid，status）
• inervalBook - 監控book定時器，實時更新book，能夠經過book查看當前訂單數量，和用戶是否已存在
• inervalOver - 監控book定時器，實時查看book中全部訂單是否全部都支付完成，此時達到limit則設置結束標籤，活動結束
• 若是須要實時更新庫存，能夠在設置一個定時器

接口

• checkOrder - 下單接口
• getOrderStatuss - 查詢訂單接口，該接口須要根據uuids列表返回對應的訂單status列表，以便實時更新book

流程

redis併發鎖不足

總結

通常爲支付訂單有效期爲15分鐘，若是某個用戶在15分鐘才支付或者一直未支付直到失效，就會浪費一個庫存；若是庫存滿了，但真實購買量並無滿，假設咱們規定此時新用戶去搶，返回「搶光了」的消息，那麼用戶就不會去搶了，因而浪費一個名額；假設咱們規定返回「請繼續搶」，那麼用戶持續搶15分鐘，體驗不好。
針對以上問題，咱們能夠根據經驗適當擴大庫存量，好比預計秒殺100臺，那麼庫存能夠增長到105，這樣，當產生105個訂單時，可直接返回「搶光了」，保證有一部分客戶訂單失效時，仍然達到預期銷售量。