訪問量大，對網路頻寬要求高
系統如何支援瞬間的高併發
如何防止商品超賣
如何防刷、防黃牛等
cdn快取，nginx+lua實現活動資料快取2秒
高併發：限流、防刷
超賣：使用redis實現原子性的操作
防刷：openresty lua 實現限流、驗證黑名單等
黑名單機制：手動/自動收集ip、userid資訊，加入到黑名單庫或者黑洞
活動型別：秒殺、搶購、預售
支援商品型別：套裝、單品
預約時間、秒殺時間等
是否需要驗證手機號
搶購總量
相同活動的相同商品，購物車裡只能存在一條
每人最大搶購次數
每人每次最大購買數量（一次只支援購買乙個套裝）
小公尺的排隊方案：http層接收請求後放入佇列
通過走**：redis lua實現原子性的驗證邏輯，成功後，寫入佇列（佇列可以降級）
秒殺系統設計總結
秒殺問題 1.前端 突然增加網路訪問頻寬 使用者可能存在重複提交 2.後端 商品超賣 資料庫樂觀鎖 cas無鎖 redis分布式鎖 mq非同步形式修改庫存 使用者需要等待 單機壓力大 單獨一服務形式部署 docker。可以實現快速擴容 使用者操作頻率塊 閘道器限流 使用者作弊 資料庫訪問壓力大 分表...
秒殺系統的實現
按照正常的購買流程 查詢商品庫存，庫存大於0時，生成訂單，去庫存。如果出現併發，導致在查詢商品庫存的時候，庫存會一直出現大於0的情況，出現超賣現象。基於mysql的事務和鎖實現方式 如果不開啟事務，第二步即使加鎖，第乙個會話讀庫存結束後，變會釋放鎖，第二個會話仍有機會在去庫存前讀庫存，出現超賣。如果...
redis實現的秒殺系統
利用redis的樂觀鎖，實現秒殺系統的資料同步 基於watch實現 import redis conn redis.redis host 127.0.0.1 port 6379 conn.set count 1000 with conn.pipeline as pipe 先監視，自己的值沒有被修改過...