商城特殊活動架構.png
特殊活動構成模塊
-
驗證碼
-
產生驗證碼
- 初始化產生100個驗證碼送悔，每次按照當前時間ms%100獲取一個驗證碼扯再，保存至tair传黄，超時為x分鐘
- 這里的校驗碼類似于token连茧，每次請求都隨機分配一個用戶唯一的token并且保存至tair核蘸，這個token還有圖片顯示給前端
- 用戶需要手動輸入這個圖片里的驗證碼
- 這樣秒殺拼的系統(tǒng)是(分流不至于單點壓力，提高機器人刷單行為成本)
- 用戶點擊秒殺按鈕的速度
- 快速識別驗證碼和輸入驗證碼的速度
- 校驗驗證碼
- 發(fā)獎時要拿這個token對tair內token進行校驗(覺得這個流程體驗很不好)
- 應該是token的生成和校驗都是 代碼自動做的啸驯，不需要額外的用戶交互
-
產生驗證碼
-
活動模塊信息(商品列表)
- 一個活動下面包含多個模塊
- 秒殺品模塊客扎，推薦品模塊(商品)[為了導流]，其他模塊(主題商品館)[不一定需要]罚斗，秒殺場次模塊時間表
- 包含的spu類型有, 優(yōu)惠券/實物
- 秒殺品應該只是spu/sku的特殊類型徙鱼，當秒殺時間過期后，商品應該自動變?yōu)槠胀ǖ膕pu/sku（我們現(xiàn)在的系統(tǒng)并不是這樣的针姿，而是單獨把秒殺品和非秒殺品的訂單流程分開袱吆，造成秒殺品訂單不可逆）
- 秒殺品只能是 b2c產品
- 秒殺品的庫存應該是 spu下面的sku對應總和，而我們的系統(tǒng)是將spu中的第一個sku作為賣品距淫，而沒有將spu中不同規(guī)格商品進行細分
-
秒商品列表模塊SPU庫存信息
- 單獨module 下 spu list 庫存信息查詢接口
- 批量獲取一個module 下所有spu 的庫存绞绒，保存至tair
-
獲取秒殺品詳情
- 商品信息(但是不顯示秒殺品剩余庫存信息)
-
準備參與秒殺（京東\阿里的秒殺是不需要輸入驗證碼）
- 獲取校驗碼
- 正確輸入校驗碼
-
參與秒殺
- 現(xiàn)有實現(xiàn)秒殺品到點前不允許搶購
- 點擊搶購后需要校驗 token，風控 -> 扣減庫存 -> 記錄用戶令牌 -> 記錄用戶參與信息( 這里采用單向鏈表模型榕暇，向后自動調用)
- toke 校驗蓬衡，防止刷單，降低并發(fā)請求（就是一個驗證碼）
- 風控 判斷用戶userId/設備deviceId是否已經參與過彤枢，用tair保存
- 扣取 庫存計數(shù)器 同時會將 spu 狀態(tài)也保存在tair中狰晚，如果庫存被扣完，則更新spu緩存狀態(tài)缴啡，減少計數(shù)器壓力[這里由于采用@Cacheable的方法壁晒，無法立即更新，spu的狀態(tài)可能會需要本地緩存自動更新]
- 發(fā)放用戶令牌 生成用戶唯一令牌
- 記錄用戶/設備記錄 防止用戶重復參與业栅，15分鐘內不允許再使用
-
創(chuàng)建秒殺訂單
- 我們將秒殺品下單獨立了一個判斷
- 秒殺品不允許使用 健康金/優(yōu)惠券/購物卡（京東是允許使用）坑比[非秒殺品, 是可以調用促銷中心計算促銷后訂單金額]
- 正常下單后秒咐，對用戶進行風控（同一個設備，同一個用戶碘裕，同一個spu携取，同一天內，n分鐘內娘汞，只允許購買n次）[比較合理的控制是歹茶，一個秒殺品，只允許用戶購買n次]
- 由于采用同步調用創(chuàng)建訂單服務，失敗有多種原因惊豺，如果由于庫存/商品不可用的原因燎孟，則立即清空緩存內的庫存計數(shù)器。（這種原因是使用分桶策略尸昧，有可能有些分桶還存在庫存揩页，但是總庫存已經不足，這時候應該馬上清空全部分桶庫存烹俗，同時將整個spu/sku置為不可用）
第三方組件選型
-
緩存 Spring-Cache管理
-
本地緩存 EhCache
- 場次產品信息緩存全量至本地 每隔 n分鐘, 重新從 db/第三方緩存 更新一次[這里面有n分鐘的管理信息同步問題]
- 可以做一個全局監(jiān)控爆侣，當管理端刷新后，監(jiān)控觸發(fā)自動更新本地緩存[我們還沒做這一個]
- 采用 spring 4.2.x幢妄，存在 expire 后穿透至第三方緩存問題
- 場次產品信息緩存全量至本地 每隔 n分鐘, 重新從 db/第三方緩存 更新一次[這里面有n分鐘的管理信息同步問題]
-
第三方緩存 Tair[支持持久化和非持久化]
- 持久化 重要數(shù)據(jù), 秒殺商品兔仰，庫存(保存總庫存/按策略分桶保存庫存)
- 非持久化
-
本地緩存 EhCache
-
MQ RocketMQ
- HessianUtils 對數(shù)據(jù)進行壓縮
- 注意 consumer/producer 之間序列化Object的問題，package path不對無法匹配
特殊活動應用設計的內容
-
場次+獎品(商品/現(xiàn)金)=活動
-
獎品分為 商品蕉鸳，現(xiàn)金乎赴，優(yōu)惠券
- 獎品 綁定場次，獎品不能多個場次共用(個人覺得不合理)潮尝，現(xiàn)有方案認為運營的工作量能忍受榕吼，我個人覺得模型上有問題
- 獎品 有時效性
- 我的理解，當前獎品的時效性和優(yōu)惠券的時效性沖突(如何確定真實時效性)勉失，但是實物(現(xiàn)金)又沒有時效性需要獎品時間來控制(沒理解)羹蚣。
- 業(yè)務的時效性 又被理解為活動后臺允許獲取獎品的時間段，細分了每個獎品適用的范圍段
-
商品(spu)
- 實物
- 以抵用券的形式發(fā)放
- 虛擬物(具體的物品詳細到 sku)
- 主客優(yōu)惠券(使用) - 賣家承擔成本
- 話費充值卡
- 流量充值卡
- 主客無門檻券 - 商城承擔成本
- 抵用券 協(xié)商商戶
- 實物
-
現(xiàn)金
- 需要獨立現(xiàn)金紅包系統(tǒng)
- 需要實現(xiàn) 賬本 等等實現(xiàn)
-
優(yōu)惠券
- 優(yōu)惠券系統(tǒng)
- 一個場次只會有一類優(yōu)惠券
-
獎品分為 商品蕉鸳，現(xiàn)金乎赴，優(yōu)惠券
