總體架構方案

網絡攔截: DNS優化, SLB負載均衡，網關封IP限速

業務攔截： ID限速， 驗證碼， 只吸收前面N個請求，後面的全拒絕;

Redis攔截: 庫存不超發，保證限購

接口攔截： 儘量減少業務檢查，判斷黑名單

MQ+MYSQL: 異步處理落庫情況;

Redis List方案 + Incrby方案

1. 從緩存讀取出活動信息
2. 判斷活動開始時間和結束時間
3. redis內無庫存就直接返回無庫存，活動結束
4. 讀取 UID+活動ID的 參與次數 達到限制就返回限制
5. 使用Incrby 寫入 UID+活動ID的 參與次數，判斷返回的次數是否超過限購次數，超過則返回限制
6. 寫入DB（或者用MQ推送給DB削峯落庫）

第四點雖然redis是單線程的，但是客户端是多個的，所以第四點的讀取和第五點的使用，兩個不能同時具有原子性, 必須以 incrby結果為準;

比如一人限購一個，就算某用户第二個請求進來了，把 UID+活動ID 的值 incrby 為2 ，那麼這個人返回的也是 “一人只可以購買一個”，對於業務無損；

如果出現Redis崩潰或者Mysql崩潰等異常情況，等待服務恢復後， 可以直接從DB裏面的購買記錄和庫存信息簡單同步到redis裏面，無需開發人員進行過多操作

Redis List方案支持庫存編號模型，如果所有的SKU本身無編號意義或者發貨才確定庫存，可以使用 Incrby控制庫存 + Incrby 控制個人限購數量