抽獎系統設計分享心得筆記

心得來自保哥的youtube影片 >> 那些年我們實作過的抽獎系統

1. 一、抽獎在業務跟系統扮演什麼角色

抽獎是一個常見的工具

拉新 dau 日活躍人數 月活躍人數

拉活 有帳號的人，但是太久沒有用

透過活動拉新、拉活。達到預期收益
pm、markting人員 模型要確定下來
行銷預算 + 函式 = 預期收益

2. 二、機率設計

2.1. 五個維度

2.1.1. 抽獎活動的週期

確定、不確定
確定的：比如某兩個禮拜。
不確定的：比如每消費金額之後，小小抽。

2.1.2. 開獎方式

立即開獎、一段時間開獎
立即：馬上知道有沒有中獎

一段時間：一段時間公布，會需要有公證的操作或證人

2.1.3. 抽獎人數

確定、不確定
確定：通常來說公司尾牙就是確定人數
不確定：街口的雙11活動，參加人就不是確定

2.1.4. 抽獎次數

確定、不確定
確定：公司尾牙就是確定的
不確定：街口雙11或百貨公司活動就是不確定的。

2.1.5. 獎品數量

確定、不確定
確定：ps5 1台，就是確定
不確定：ubereats 新人首單 100元，就是不確定的

2.2. 獎項設計

0 ~ 0.5 中iphone ，隨機random
rand seed 常用 block chain hash

2.2.1. 大獎設計

10 台iphone 在1個禮拜內送完，但需要跟行銷討論想要的效果
有可能是每1最多抽到1台，在雙11當天活動高潮 就送5台之類。

2.2.2. 小獎設計

常見作法：機率獎品對照表

3. 三、業務風險的控管及系統的風險控制與注意事項

1. 一定要限制抽獎次數 30次，怕有bug，這個次數可以很大，但不能是無限。

2. 獎品送的狀況超出預期，需要有緊急狀況的計劃

3. 限制次數

   1. 業務層限制次數
   2. 在nginx module 限制來自某個ip的流量等等
      業務層或網管層限制某個用戶id 做限流，防止用戶大量請求。

4. 攔截一些無效流量

   無效流量的效果大神說很有感

   比如momo幣 10點搶，10點01分進來1000個用戶，前面10個做完業務邏輯，後面990個可以都不做一些邏輯判斷，減輕系統的負擔，直接return。

5. 前端的部分

   按了請求之後馬上disable按鈕，10秒後再解開之類的

6. redis使用

   如果做一個select update 或一個很大的trasaction 基本上系統就等著掛掉。流量尖鋒的資料庫壓力，超時原因都是各式各樣的資料庫鎖，很大呈度可以減少這個問題。

   因此，要搶秒殺或福袋建議大家可以看redis 的lua腳本來實現扣減庫存的方案，把需要資料庫完成的強一致性減庫存操作轉換為redis 的記憶體操作
   之後再透過某種方式再同步回資料庫，去實際做減庫存的工作。可以非常有效減緩系統壓力。

   QPS說明

   資料庫：QPS 20 左右
   redis ：QPS 幾千沒問題

4. 問題時間

4.1. Q1 資訊架構的錢怎麼預估

可以先探討是在地端還是雲端。(我們電資(電商)不能上雲)

另外就是核心關鍵業務指標來評量，比方說
日活躍人數多少?( Daily Active User，DAU )
月活躍人數多少?
小活動的用戶活動參與度多少?
手機的nofication ，用戶點擊會是多少?(街口這項是滿高的)

街口案例(假設)：

假設日活10萬、月活30萬，大型活動 日活 拉到2~3倍。

以雙11為例，11整點 抓30萬 request 流量，鋒直流量可能再用反推maybe可能是需要1000qps

1000qps 再往下分解，可能需要5台、6台機器 可能在nginx 流量截取層需不需要做一些其它節點的配置

雙11時大概20幾分鐘不能work，原因是因為我們的防火牆被打爆了，流量最大，內部系統風平浪靜
ap節點 做到 stateless 水平擴容

5. 閒聊

5.1. 壓測工具討論

• k6 javascript 寫script壓測工具 保哥推薦 ，底層是用go
• jmeter

壓測有分為單點壓測、情境壓測

cpu 超過90%沒意義，講師想糾正大家對於壓測的觀念，不是說壓測一定要把系統搞到爆才叫壓測。
cpu 50%、60% 就已經有點不穩定的感覺。

比如在cpu 20%、30% 使用率，已經有達標需求了，這樣也是壓測的很好結果。