本文來自作者 姬光 在 GitChat 上分享 「300 萬粉絲的秘密：微信抽獎活動從架構到運營」，「閱讀原文」查看交流實錄。
「文末高能」
編輯 | 哈比
抽獎活動，應該算是最古老的運營活動之一了，無論線上還是線下，商場還是超市，大轉盤都無處不在。
然而，在微信紅包出現以後，抽獎活動便發生了質的飛躍，因為用戶抽到的紅包可以直接發放到零錢中，這可是真金白銀的活動，而且立馬可以體驗到好處，刺激反饋非常實時。所以，基於微信的紅包抽獎想不火都不行。
早在 2015 年初的時候，我司的運營同學策劃了基於微信服務號的『天天大抽獎』活動，在那樣的蠻荒時期，朋友圈活動還不會打擊得特別嚴厲，因此藉助於此固化活動，我們獲得了數百萬粉絲留存。
當然，關於留存的部分，就不只是發錢這麼簡單了，還需要結合其他促銷活動一起才能留住真正的優質用戶。
曾經在很長的一段時間內，業界並未見到類似的微信抽獎活動，所以有好幾家公司試圖出巨資（數十萬）購買我們的全套抽獎活動系統。
這至少說明，基於服務號的完善的抽獎系統，是具有一定價值的。當然，作為公司來講，我們不會去賺這些小錢，畢竟我們不是程序外包公司 ~
那麼，本篇我們就來探討一下，一個（相對）完整的抽獎活動，都需要考慮哪些東西。
溫馨提示：本文全長約 16000 字，預計閱讀時間 20 分鐘以上。
1. 平臺的選擇首先我們來說一下平臺的選擇，目前我們可以選擇的主流平臺大致有 PC、H5（移動端網頁版）、APP、微信平臺的服務號、微信小程序、阿里平臺的天貓、手淘應用，甚至支付寶小程序等。
至於具體選用哪個平臺，要基於自身用戶群體的分布，以及研發團隊的技術積累，還要考慮一些新興的處於風口的平臺類型，比如微信小程序。
這裡簡單帶過一些平臺上可能產生的差異：
1.1 PCPC 上需要考慮的主要是不能直接發紅包的問題，電腦上的抽獎活動存在好多年，除了抽取積分、卡券、實物等，沒有什麼實質性的變化。
另外一點就是大量的兼容性問題，比如圓形的轉盤動畫在低級 IE 瀏覽器就很難實現，所以之前許多抽獎活動都是用 flash 解決方案。
1.2 H5除了兼容性問題少了一點（真的嗎？）外，其他與 PC 特性差異不大。
1.3 APP眾所周知，APP 版本在各個應用市場存在審核時間的問題，但如果固話活動不經常修改，且變動部分都能由運營熱更新實現的話，也是個不錯的選擇。因為原生 APP 可以實現更多流暢的交互體驗，更多炫酷的效果。
1.4 微信服務號這是我認為的最佳選擇，撒錢真的很方便！而且開發也不複雜，服務號開發文檔非常完善。
1.5 天貓、手淘應用在淘寶開放平臺上可以作為獨立開發者（ISV）創建應用，然後授權給其他店鋪使用，做得好還可以賺錢。不過，同樣的問題就是，在成本一樣的情況下，任何其他的獎品都沒有微信紅包誘惑大。
目前筆者在淘寶開放平臺還沒有看到第三方應用的發放紅包接口，即使有這種接口，作為第三方的應用，商戶資金管理和審計也比較複雜，店鋪不會把這種發放資金的能力交給第三方應用開發者的。
1.6 微信小程序微信小程序目前只有支付能力，即收錢的能力，暫時還沒有開放發錢的能力。不過如果一定要在小程序裡玩，可以考慮通過 unionid 打通小程序和服務號的用戶，在用戶中獎時獲取該用戶在對應服務號下的 openid 再調用服務號的紅包發放接口發放紅包。
1.7 支付寶小程序：你說啥？本文的案例始於 2015 年，彼時服務號方興未艾，微信也將許多資源傾向於服務號的能力擴展，就像現如今的小程序一樣，大家都沒有想好怎麼玩。
所以，對於微信服務號這個平臺，我們除了要做基本的『服務』之外，也希望嘗試更多的玩法，加之微信紅包接口已經開放，故，基於微信服務號開發的『天天抽大獎』活動應運而生。
2. 前期準備2.1 服務號認證抽獎活動至少需要服務號獲得網頁授權能力，這也意味著必須使用通過了微信認證的服務號才能玩得起來。而微信認證只針對個體工商戶、企事業單位、政府組織等。這意味著你只要要能使用其中一種資質的證明材料。
而對於一般的企業型帳戶，獲取微信認證需要通過對公帳戶打款進行註冊主體驗證，也就是說至少要有對公帳戶。
當然，對於正規的企業來講，這些都不是問題，正常走流程跟公司申請對公帳戶打款即可。
另外，每次認證需要繳納 300 元 費用，詳見微信文檔。
2.2 服務商平臺既然要做紅包抽獎，那必須要有錢可以發放。服務商平臺（https://pay.weixin.qq.com/）就是你可以充錢的地方，同樣，申請服務商平臺也需要提交對應資質，所有關於用戶支付、企業打款、紅包等功能均在此管理。對於開發人員來講，發放用戶紅包還需要在此平臺下載證書部署到伺服器。
另外，大家可以參考下前一陣 @Javen 的 chat 《微信支付接入的那點事兒》，裡面有詳細的支付接入流程。
3. 界面設計 & 前端開發3.1 界面設計抽獎活動的界面設計主要要提現歡快熱烈的活動氛圍，但也不宜天馬行空隨意發揮，因為我們後面還有代碼實現和運營的問題。比如整個頁面的背景結構如果過於複雜，或者由於動效緣故要拆成若干部分，那麼在更換抽獎活動主題的時候，就要做更多的改動。
3.2 轉盤對於抽獎動畫我們也有很多選擇，比如圓盤（指針轉，圓盤轉）、滾球、方盤跑馬燈等。所有你在遊樂場、澳門賭場等看到的抽獎玩法，都可以想辦法移植到活動中來。
這裡值得一提的是，前一段時間京東凹凸實驗室開發了一款推金幣領券的遊戲活動，其 3D 效果異常逼真，以至於被微信給屏蔽了 … 感興趣的讀者可以搜索『凹凸實驗室』公眾號查看相關文章。
3.3 動畫時機這是個前端開發問題。對於動畫執行的時機，最簡單的實現就是先去請求伺服器，拿到抽獎結果之後再執行動畫。缺點就是，網絡慢或者伺服器響應慢的時候可能會有短暫等待。
當然，也可以用有趣的進度條或者加載動畫等縮短用戶對這個時間的感知。類似的，先執行動畫，當動畫結束後再去請求伺服器也是差不多一樣的效果，當動畫結束之後，也可能有短暫的等待時間需要處理。
而最接近真實世界的方式，就是當用戶點擊抽獎時動畫就啟動，當獲取到抽獎結果時動畫就結束。顯然，這事兒沒那麼簡單。
首先，動畫都是有過渡效果的，拿到抽獎結果後不可能戛然而止。其次，如果在請求抽獎結果的過程中網絡卡頓一直拿不到結果怎麼辦？如果中間伺服器報錯了怎麼辦？請求沒有響應要不要再嘗試幾次？在這個過程中動畫怎麼處理？
最後，假設我們對外宣稱是『100% 中獎』，那麼多次嘗試之後伺服器確實沒有響應，轉盤或指針要落在哪裡？什麼？落在最便宜的獎品嗎？那麼伺服器沒有記錄可查，用戶截屏過來要獎品，你給還是不給？
這裡我們的策略是：用戶點擊抽獎則轉盤開始轉動，且開始請求抽獎結果。轉盤從開始轉動到最後結束分為三個階段，即加速-> 勻速-> 減速。
嘗試多次請求或或網絡延遲等問題，都可以在勻速階段處理，如出現問題則適當延長勻速時間，對於用戶來說只是感覺轉盤轉動比較久而已，想想《盜夢空間》中的陀螺。
那麼，如果最後真的報錯了呢？你可以考慮讓指針停在兩個獎品中間，但是這樣仍然會有爭議。首先是太像 BUG，其次用戶會說他一定會得到兩側的某個獎品，只是你這個東西出錯了停在了中間。
所以，最保險的方案，就是永遠不要宣稱『100% 中獎』，永遠保留『謝謝參與』用來兜底。
3.4 排行榜多數情況下，抽獎界面上都會有個類似排行榜的模塊，用來展示中獎用戶和誘人的獎品。這裡在界面上沒有太多東西，不過是各種循環滾動動畫、展示用戶暱稱頭像等，如果是手機號，記得在 CGI 層面打碼，不要洩露用戶隱私就好。
3.5 用戶信息收集基本的表單提交需要前端的驗證，對於抽獎業務中的實物獎品，則需要類似地址選擇組件搜集用戶收件地址。更嚴格一點，手機號需要驗證碼來驗證真實性，確保能夠聯繫到用戶。
再進一步，可以利用 GPS 定位能力，自動獲取用戶所在區域，只需要補充詳細地址即可。現在許多快遞公司或者有外送服務的服務號，都實現了類似功能，具體不再展開。
4. 接口設計對於接口的設計，首先要考慮平臺是否有需要整合的基礎能力，比如公司主站的登錄態與微信授權打通等，這裡每個公司具體業務不同，不便展開討論，我們只討論一下抽獎強相關的接口設計。
4.1 微信網頁授權基於服務號的微信網頁授權可以獲取用戶在該服務號下的 openid，作為用戶在該服務號下的唯一標識，具體可以查看服務號開發文檔。
至於 openid 是否作為用戶的唯一標識，有許多種處理方法，一般還是建議自己維護一套用戶 id 系統，不要直接暴露 openid 為好。
起碼在資料庫中，int 的查找要比 string 快。至於具體的授權流程以及 token 維護等，則是微信服務號開發的內容，不展開。
4.2 授權後操作微信授權只是獲取 openid 或其他用戶信息的第一步，根據自身業務的需要，可能還需要用戶繼續註冊或綁定手機等，才能真正算是你的用戶。
在本文的案例中，我們也曾嘗試過不要求用戶註冊，只要簡單的授權即可抽獎的活動，但事實證明，這會帶來許多問題。
一來只用 openid 標識用戶，容易被羊毛黨刷單，二來如果對於價值比較高的有價產品，可能還是希望他註冊。而註冊之後還要綁定之前的抽獎結果，而這個過程就可能帶來安全風險。
因此，經過一段時間的嘗試和權衡，我們把抽獎活動改成了必須先關注和綁定手機才能抽獎的形式。雖然參與度會有所下降，但也避免了許多不必要的麻煩。
對於授權後的綁定手機，手機登錄還是帳號密碼登錄，是否需要驗證碼等，請參考自身平臺的用戶體系建設。
4.3 抽獎主接口抽獎主接口主要用來獲取中獎狀態、獎品信息等。這個接口將會是承受壓力最大的一個接口，因為總會有人試圖單獨刷這個接口，所以所有的防禦機制都要體現在這個接口上，具體我們後面再聊。
對於接口吐出的信息多少也是要嚴格控制的，比如獎品的庫存、中獎概率等信息。基本上，如果是簡單的抽獎，那麼這個接口只需要告訴用戶是否中獎即可，也可以加上剩餘抽獎資格等信息。
4.4 獲取可抽獎次數一般情況下，抽獎資格的獲取可以混合到抽獎主接口中，不過也有一些場景需要單獨判斷抽獎資格，即是否允許抽獎以及能抽幾次。比如用戶剛剛進入抽獎界面時，或者執行了 「關注」，「綁定」 等操作後刷新資格的時候。
另外，部分安卓手機可能會緩存頁面，如果在下一步操作中改變了抽獎資格（次數，積分變化等），再直接點擊左上角返回，次數可能就不會變化。
因此，最好再抽獎動作之前先強制更新一下抽獎資格，而不是直接等待抽獎主接口返回不能抽獎的錯誤，因為這樣會導致用戶看到界面上有資格，但是每次點了之後又不能抽。這種情況下，還不如一次就讓用戶死心，如果真有投訴就如實相告，告訴用戶手機有緩存問題。
4.5 更新獎品狀態如果你的獎品設置了領取狀態（抽獎領獎動作分離 / 註冊前抽獎 / 微信卡包領取狀態 / 優惠券領取狀態） ，那麼還需要一個更新獎品狀態的接口，用來修改獎品的領取狀態。
舉個例子，如果你用了微信卡包的 API 去實現發券功能，那麼用戶會進入微信實現的卡券領取界面，在這個界面用戶也可以選擇不領取，當然你也可以就此視為用戶放棄。
但如果你希望再給用戶開放領取入口，比如在類似 「我的獎品」 這樣的頁面再次領取的話，就需要判斷用戶是否領過此卡券。
而當用戶終於點擊了領取，把卡券放到自己的微信卡包之後，微信會執行一個回調函數，在這裡，你可以去更新用戶的獎品狀態並關閉領取入口了。
4.6 關聯用戶這個接口只在一種情況下使用，即 「未註冊」 之前允許抽獎，「註冊」 之後領獎的情況。注意這裡的 「未註冊」 和 「註冊」 都加了雙引號，是因為這兩個詞對於不同的平臺不同的業務意義也不同，需要您自己去界定，什麼是註冊，什麼是未註冊。
關聯用戶有一定的風險，尤其是對於價值比較高的獎品。因為你只能根據某個特定的條件來判定註冊前後兩個帳戶是否真的是同一個人。比如通過 openid 判定註冊前後用了同一個微信號；再比如用特定算法生成的機器碼判定註冊前後是同一臺設備等。
以 openid 為例，如果每個用戶進來，我們都使用微信授權接口去微信那裡授權，勢必會有嚴重的性能瓶頸，因為微信的接口對於我們來說是外部接口。更嚴重的情況，還有可能達到微信 API 的每日調用上限，導致全部 API 無法使用。
因此，我們最初的簡易版方案並沒有每次都去授權獲取 openid，而是緩存了第一次授權的 openid，且沒有其他輔助的 ukey 來綜合校驗，導致用戶在抽獎的時候，我們實際上並不能確認這是個真實的用戶，甚至不能確認這是個真實存在的微信號的 openid，只能說明這段字符串符合 openid 的長度。
這個漏洞的可乘之機是要刷微信紅包，如果不是真實的 openid，是無法收到微信紅包的。所以，羊毛黨來刷紅包的時候，一定用的是真實的 openid，因此這個 bug 不能造成太大的傷害。不過我們還是及時加入了 ukey 驗證。
並且，對於抽中後再來實名關聯的用戶，也會再次驗證其微信帳戶是否有疑似作弊行為，這就是為什麼所有活動都要加上 「最終解釋權歸 xx 所有」 的緣故，因為總有羊毛黨來搗亂。
注意，羊毛黨一般都是有大量真實微信號在手裡的，這種大量真實微信號的操作，是無法通過簡單手段識別出來的。
4.7 運營文案接口該接口是否需要以及其複雜的程度，取決於您的業務需要，即抽獎活動在線時有多少需要實時運營的內容。比如用戶歡迎語、抽獎成功 / 失敗後的引導語等等，重點是如何能與自身的運營系統結合，方便運營同學使用。
4.8 清除緩存抽獎活動往往有類似排行榜，參與人數等信息的展示。對於訪問量較大的抽獎活動，這種信息一定是有緩存方案的，不可能每次都去查詢資料庫實時計算。
那麼，既然有緩存，就有清除緩存操作，有時可能還涉及到冷啟動造數據等，後面我們再詳細講解。
對於排行榜的刷新時間也是要權衡的，緩存久的話緩存利用率高，但是用戶如果真抽中了，發現沒有上排行榜，定會對系統產生懷疑。
因此，緩存時間不宜過長，或可採用表面方案，如果用戶中獎，則直接在頁面中處理排行榜的展示效果，用戶可以直接看到自己進入了排行榜。
當緩存再次刷新時，即使排名順序有變化，或者被擠出排行榜，就都是正常的展示了。而對於定期清理緩存的機制，可以使用 linux 系統自帶的 crontab 或其他常駐的 deamon 腳本均可。
4.9 日誌記錄除了用戶抽獎本身的記錄之外，一般還需要記錄其他一些重要信息。比如，微信紅包接口屬於外部接口，因此調用微信紅包接口的返回內容就最好記錄一下方便定位，否則有的時候會很難確定問題。
比如擴容多臺機器，但有個別機器的 CA 證書沒有帶上，導致微信紅包接口調用失敗。
再比如微信商戶平臺中餘額不足，導致發放失敗等，都需要通過日誌記錄。這些錯誤是不方便直接展示給用戶的，因此在用戶側一般是直接告知未抽中即可。
4.10 其他功能頁根據業務需要，抽獎活動可能還包含我的獎品、抽獎規則、抽獎結束頁，通用錯誤頁等，這些頁面基本上只需要考慮運營內容和經常變化的邏輯即可。
比如新增了獎品類型，在我的獎品頁要怎麼展示；如果有新的活動主題，是否方便修改之前的獎品圖標風格等。
4.11 頁面入口權限控制在抽獎活動的各個階段，可能需要對某些頁面入口進行統一控制，具體可以通過活動時間，資格等手段控制。
唯一需要注意的是，最好設計成頁面和相關異步接口可以統一開關，否則經常容易犯的低級錯誤就是，頁面雖然不能訪問，但是接口仍然可以單獨調用。
另外，即使是你記著要把所有接口都關掉，但是每次全部要手動修改全部接口，就不是很方便了。
5. 邏輯層設計邏輯層的設計，大體與前面的接口設計對應，這裡只單獨拿出一些值得討論的點說一下。
5.1 用戶體系前面也提到過標識用戶的重要性，明確標識用戶而不只是依賴微信的 openid 體系，可以一定程度上防止刷單。另外，手機號註冊基本算是終極方案，但是用戶參與成本也高很多，需要權衡。
一個相對摺中的方案是，使用與 openid 有映射關係的用戶體系，這樣方便用戶綁定微信，且在微信上可以實現 「自動登錄」 的效果。微信開放平臺提供了 unionId 體系，可以幫助打通各個服務號 / 小程序等的用戶。
如果要實現跟手機號綁定，那就需要自己建立一套手機號與各個平臺 openid 的對應關係。
或者單純只有服務號的 openid 與自建用戶體系的對應關係，向用戶派發 uid + ukey 來識別用戶，而不是直接使用 openid 作為用戶標識。
5.2 抽獎資格抽獎資格可以通過多種方式實現，例如通過其他活動派發抽獎次數，甚至免費贈送抽獎次數，或者通過自建用戶體系的積分體系實現抽獎資格。
與之對應的，抽獎動作則是消耗對應的抽獎次數或消耗某種積分，比如招商銀行的信用卡積分抽獎。對於自建用戶體系的積分抽獎，可以通過打卡籤到，電商購物等獲得。
而對於其他活動渠道獲得的抽獎次數，則需要抽獎系統對外提供增加次數的能力，如果多個活動共用或多種獲取渠道共用，則還要區分該資格來自哪個渠道。
增加次數接口如果是對外暴露的，則有被多加的風險，因此不建議前端直接使用 ajax 異步調用新增次數，而是要把新增次數的邏輯混合在活動的邏輯中，經過嚴格的判斷再在 CGI 層面處理完成。
如果是新用戶進來默認贈送次數的，則一定會導致羊毛黨使用大量帳號刷單。對於這種活動的獎品和概率設置，必然是要儘量降低成本，降低概率，這樣即使是羊毛黨也不會使我們造成過大損失。
羊毛黨其實是無法完全杜絕的，因為在系統層面看來，很多時候就是大量的真實用戶。所以我們只能在成本和風險上進行控制和權衡，無法完全避免，也不能誤傷太多真實用戶。
5.3 獎品類型上文討論的獎品類型，主要都圍繞微信紅包和微信卡券。這兩種虛擬商品都是基於微信平臺的實現，相對比較容易。
如果您的抽獎活動還需要派發其他獎品，比如商家自己實現的優惠券、郵寄實物獎品、各種會員卡體驗名額等，則需要結合自身業務實現發放接口，再供抽獎系統調用。
同樣，仍然需要注意實際發放資格的判斷是否完善，以及如何判斷刷單和作弊等。
5.4 抽獎概率算法從發放獎品的大體傾向來看，一般有兩種玩法。
一種是儘快把獎品都抽完，即土豪要儘量保證獎品發完。這種抽獎有時效性，雖然先來後到對概率沒影響，但是晚了可能獎品被抽完；另外一種是，儘量保證更多的人次參與，獎品不要太快消耗。
這種抽獎參與人次分布相對均勻，但是對於單次活動，且沒有手動調整抽獎概率的情況下，不能保證獎品都被抽完。
第一種場景的典型例子，就是公司年會，獎品固定人數固定，且要求在晚會上必須抽完。這種場景下抽獎的概率是需要系統動態計算的，根據已知的庫存和原始概率，如果人次達到某個閾值還沒有抽完就自動增加一點點概率。
當然，這種情況也可以用獎品來抽人，比如先固定本次抽取 iPhoneX，再來隨機是哪個人。什麼？偽隨機數不夠隨機？who cares~
現場抽獎重要的是公平透明，如果用了複雜的抽獎系統反倒不能服眾，搞不好來個現場 review 代碼，所以即使是偽隨機數的抽獎，也比複雜系統強。
再說第二種，它的特點就是同樣的獎品數量消耗較慢，那麼對於長期固化的活動來說，一定是希望最小的成本獲得最多的參與。即使是時效非常短的抽獎活動，也沒有非要把獎品都送出去的道理。
因此，這個場景下不會讓系統動態調整概率，而是採用人工控制概率的方式。對於單個抽獎用戶來說，中獎區間是恆定的，即使抽了很多次，也不會擴大中獎概率。
這樣也可以防止惡意刷單，一切能夠通過數量提升中獎概率的活動，最後都可能被刷單，除非你不在乎這些成本。
人工控制還有個好處就是，發現刷單後可以及時調整概率防止損失擴大，另外如果獎品發放變慢，也可以人工提升概率保持活躍度。
5.5 連續不中補償（必中）如果你的抽獎活動也是固化活動，會有一大波忠實粉絲定期參與，那麼為了保證粉絲的活躍度，可能要對運氣一直不好的用戶有些補償。比如連續抽獎 N 次都不中的，我們要補發某些獎品給用戶。補發邏輯沒有什麼特別，
只是要在用戶身上記錄一個連續不中的次數。不過，值得注意的是，如果多個抽獎活動的連續不中次數不能共用，那就要擴展多個存儲欄位來區分了。
對於這些只需要判定而不需要用來排序的欄位，可以統一用一個擴展欄位，以 JSON 的形式存在數據表中，避免頻繁修改 DB 結構。
此外，如果配合管理系統，讓運營同學去新建抽獎活動和新增獎品，那麼就要明確標識出到底哪個獎品可以作為連續不中自動發放的。要麼用明顯的標記和提示，要麼單獨一個欄位設置這種通用獎品。
如果由於提示不明顯，把 188 元 現金當成了連續不中補償，那就有點過於土豪了。
5.6 連續不中提升中獎概率（權重提升）接 5.5，如果你只希望連續不中的用戶提升一定的中獎概率的話，實現思路就又不同了。中獎概率本身這個事，分散到多個獎品上面，就不是簡單的可以提升概率的問題了。
所以，更簡單的做法是，把用戶抽獎時獲得的隨機數擴大範圍。比如我的概率範圍相當於 1-10000 的隨機數，如果用戶獲得的是 3000 這個隨機數，那麼 10% 的概率相當於 1000 個單位，因此給用戶提升 10% 的中間概率可以粗略地轉化為：在 2500 - 3500 之間如果有命中獎品中獎區間，就都算中獎。
5.7 默認獎品設置上文 3.3 中說過，最好始終保留 「謝謝參與」 兜底，那麼如果運營要求本次活動一定要所有都有獎品呢？
如果說用戶投訴，截圖直接索取獎品都能接受呢？這時，之前設定的謝謝參與的位置，就要變成普通的獎品，從而導致一切跟不中獎相關的邏輯以及判定條件都可能要修改。
所以，如果你擔心有這種需求變更的風險，最好把所有的獎品位置都設計成可以作為普通獎品，也可以作為特殊位置（謝謝參與，沒有獎品等）。
5.8 獎品庫存判斷一般來說，庫存都是整數單位，但每次操作的數量未必是 1 個 / 件 / 積分 / 元。假設你的獎品涵蓋積分、微信紅包、優惠券等。
那麼，抽獎資格可能是 10 積分每次，所以用戶帳戶中必須有 10 積分以上才可抽獎；如果是次數抽獎，一般來說用戶帳戶中只要 1 次資格就可以抽獎。
獎品庫存的判斷也類似，微信紅包的限制是每次至少發放 1 元，一般金額的存儲不建議用 float，因為會產生精度問題。所以我們一般以分為單位存儲，那麼如果想發放紅包，則該獎品的庫存至少要大於等於 100（分）才可發放。
綜上，對於不同類型的獎品，是要考慮資格和庫存判斷標準的不同的，這裡可以採用配置文件的方式將可能的獎品類型和判斷標準列出即可，方便修改。
5.9 微信紅包邏輯目前的微信紅包，需要通過用戶在該服務號下的 openid 發放（可以不關注），這裡最好為所有的紅包發放邏輯設置全局開關，用來在遇到重大安全隱患時臨時手動關閉有價獎品。微信的紅包接口需要一個唯一的業務 ID，這裡可能出現的坑就是大並發時業務 ID 重複。
因此，如果並發不是很大可以採用毫秒級時間戳 +uid，如果不能滿足需求還可以繼續加入隨機數，或者使用一定長度的 UUID+uid，只要注意別超過業務 ID 本身的長度限制即可。
這裡一定要加入 uid 是由於商戶平臺的資金流水只包含用戶的 openid，不方便與自身的用戶體系對應，所以在業務 ID 中混入 uid 方便查詢信息。當然，也可以使用紅包接口的擴展欄位記錄用戶信息。
5.10 實物獎品邏輯這裡的實物獎品是個通用的類型，對於一切無法通過程序直接發放給用戶，或者用戶不能直接通過頁面領取的，都可以歸為實物獎品。
典型的例子就是，某個活動希望用戶抽的是支付寶紅包，那麼在微信平臺上顯然這是不可能的。
因此，如果一定要走支付寶紅包，可以採用抽中紅包口令，但不能防止用戶直接把口令發給別人。或者是抽中後，讓用戶輸入支付寶帳戶，然後再想辦法人肉或批量操作轉帳。
對於其他實物獎品也類似，需要郵寄的要留下地址電話，需要領取碼的要在抽中後的接口內再返回領取碼。
總之，這裡每次新增一種獎品，就可能新增一部分開發工作量，因為設計情況較多無法提前兼容。
5.11 抽獎記錄用戶的抽獎記錄要儘可能記錄更多的信息，因為每天都會有用戶以各種理由找客服投訴（除非你不給投訴入口）。
其間不乏許多無理取鬧直接來騙獎品的用戶，比如在移動端轉盤動畫旋轉的的時候拖動手機讓轉盤暫停，或者乾脆用 PhotoShop 合成中獎狀態的。
這時候，我們唯一能依賴的就是用戶的抽獎記錄了，只要記錄中不存在或者記錄異常，就可以堅決判定本次中獎是假的。例如，用戶當時的中獎隨機數，獎品信息的快照（當時的文案、庫存等）等。
而對於用戶自身的抽獎記錄，即 「我的獎品」 頁面的展示，則要考慮大量不中的情況下，「謝謝參與」 是否要隱藏。
如果謝謝參與要隱藏，那麼按照 5.7 中的要求如果這個位置變成了普通獎品，又要以什麼樣的判斷依據來決定是展示還是隱藏。
5.12 排行榜展示上文 4.8 講了排行榜的緩存清除，這裡我們討論下排行榜的構成。看似簡單的排行榜，其實並不簡單。首先，除非你的獎品非常豐厚，中獎概率非常高，所有人皆大歡喜。
否則，如果排行榜是自然生成且按時間倒序，那麼一定是滿滿的謝謝參與或者微不足道的小獎品。排行榜的作用並不是真的要排行，而是吸引用戶參與，營造氣氛。
所以，排行榜上要儘量放 「大獎」 的用戶抽獎記錄才有吸引力，比如前五名都中了 iPhoneX，雖然用戶未必真信，但是氛圍效果還是達到了。
綜上，排行榜的構成不是簡單的抽獎記錄倒序，而是按照一定的獎品配比生成的。因此，不同的活動不同的獎品就要考慮排行榜配比不同的問題，這裡也可以通過配置文件來實現。
5.13 風險控制風險控制包含很多方面，對於整個系統的全流程都有涉及。最基本的 DB 層面的事務處理，運營系統的金額控制，有價獎品總開關等，這些細節將會分散在各個章節。
5.14 活動類邏輯這裡的活動指作為一個運營活動的一些基本邏輯判斷，比如用戶屬性判斷（VIP/ 等級 / 活動資格） ，抽獎次數來源 / 渠道 / 限制判斷 ，抽獎活動判斷（區分活動 / 上下線時間） ，時效性活動（會員日半價抽獎） ，強制判斷關注 / 強制判斷分享等，具體暫不展開。
6. 數據層設計數據層面的設計要包含上文提到的所有想關信息欄位，大體上與業務邏輯是對應的，對於簡單的抽獎活動，可能單表即可搞定。而要滿足上文提到的大部分邏輯，那麼該系統至少要包含以下數據表：
獎品表主要包含：活動 ID（平臺維度 / 活動維度） ，概率（區間 / 百分比），獎品基本信息（名稱 / 描述 / 庫存 / 圖片 / 領券碼 / 現金範圍等） ，各種運營文案 / 按鈕設置 / 跳轉連結等。
用戶表（依據數據量分表） 主要包含： 用戶基礎信息（依賴平臺用戶體系），用戶擴展信息（抽獎次數 / 籤到 / 分享次數 / 評論 / 點讚 / 連續不中次數 / 手機號 / 收貨地址等） 。
抽獎記錄表（依據數據量分表） 主要包含： 抽獎記錄表（用戶基礎信息冗餘 / 獎品信息冗餘 / 抽獎動作快照 / 抽獎隨機數） ，抽獎記錄歸檔表（無需展示的抽獎記錄定期歸檔） 。
數據統計相關（獨立系統） ，用戶行為上報 ，管理員操作日誌 等。
由於具體的表設計較少有共性可言，因此不再贅述，具體的表結構我也不粘貼了，大致思路都是類似的。
7. 運維相關抽獎系統如果真的火了的話，會對伺服器造成非常大的壓力。現在無論大小公司，許多都已經採用雲服務來實現，既可以方便地擴容，承受更大業務量，也可以擁有更安全的保障，更專業的服務。
7.1 伺服器選擇如果採用阿里雲的服務，一般是 SLB（負載均衡）+ECS（雲伺服器）+RDS（雲存儲）+CDN（內容分發網絡）組合。
這裡不推薦用雲伺服器自建的資料庫服務，一來性能有限，二來要自己寫守護進程防止資料庫掛掉，最後，還要自己實現各種備份腳本，成本高又不可靠，真的不如直接購買雲服務。
抽獎活動推送期間，我們大概使用 5-10 臺 ECS 來承接抽獎活動流量，即使真的有壓力，也可以快速擴容。
7.2 數據表索引對於高並發的活動 DB，索引的重要性就非常突出了。平時做些小網站小打小鬧可能根本不需要建立資料庫索引，而在高並發的時候，一切問題都會被放大。
因此，關鍵數據表，關鍵查詢，組合查詢等，都要提前建立好索引。而複雜的聯表查詢，如能轉換成兩次單表查詢，則效率更高。
類似用戶表和抽獎記錄表這種有可能單表數據量過大的情況，可以提前考慮分表，比如給用戶按 uid 分 100 張表。
7.3 數據緩存常用的緩存方案有許多，對於排行榜、總人數這種需求，建議採用 Redis 緩存，因為其用法簡單，查詢速度快，與各種語言結合友好。
需要注意的是 Redis 伺服器的帳戶和訪問權限問題，初次使用的同學很可能不設置 Redis 的帳戶和埠，那麼你的緩存就很有可能被其他人直接讀取甚至寫入。
7.4 基礎服務監控（獨立系統）每個公司都有自己的基礎服務監控系統，或多或少。那麼抽獎活動也儘量接入這些系統，比如可用性監控，伺服器性能，接口訪問量 / 失敗量 / 告警等。
如果本身沒有類似的系統，那麼也可以針對抽獎單獨開發一些監控功能，但成本會相對較高了。
7.5 安全安全 是個大課題，我也不是專家，簡單說一下抽獎業務常用的一些方案吧。比如，基本的防刷機制 可能包括：Nginx 動態封 IP ，緩存層限制操作頻次（防止高並發寫入） ，數據層限制操作數量與頻次 ，薅羊毛的度 等等。
再比如，第三方登錄校驗合法性 ，驗證是否合法的 openid 等。此外，一定程度上的學費總是難免的，沒有殺死我們的只會讓我們更強大（健壯）。
7.6 應急預案除了前面說到的這些安全問題，有時候還會有一些 「飛來橫禍」，比如微信忽然把活動 URL 封了，分享到朋友圈後別人看不到。
在早期的應急預案中，我們可以考慮使用 Nginx Rewrite 路徑隨機串躲避，類似 https://xxx.yourname.com/Er52d6z/lottery 的形式。
還可以提前準備多個域名共存，可以實時切換，類似 https://xxx.yourname0.com/lottery，https://xxx.yourname1.com/lottery，https://xxx.yourname2.com/lottery 等。
這種方案實現成本略高一點，要準備多個域名，切代碼可以無縫切換，比較麻煩的就是微信 JS Api 的安全域名設置，最多只能三個，所以還是要慎重。
最後想說的是，這些方案現在都不管用了，因為只要微信判斷你某段時間通過誘導分享獲得了大量用戶，那就直接刪用戶。比如搞個活動本來只拉來了 1w 用戶，然後被微信判定誘導分享，損失 2w 用戶，勞民傷財還虧了 1w 用戶 …
對於這種情況，一般沒地方說理去。目前已知的唯一辦法，就是活動不要搞太熱烈，細水長流比較好。
8. 活動管理後臺活動管理後臺可繁可簡，如果在抽獎業務之前已經有了部分運營機制和能力，且能方便地用在抽獎系統就最好。
如果不能，那麼可以考慮開發通用的活動管理平臺，或者針對抽獎系統訂製完善的運營平臺。
這裡簡單羅列一下，抽獎的管理後臺可能要考慮到哪些能力。
8.1 操作日誌查詢獎品庫存，概率等屬於敏感操作，是必須要有操作日誌的。至於具體操作的人員通過什麼來識別，可以考慮使用內部的帳號系統，或手機號等。權限控制 + 日誌記錄 都是必不可少，否則很可能錢都不知道怎麼沒的。
另外，對於大一點的企業可能還有審計需求，審計公司會要求你實現這些記錄功能，作為年終審計的依據。
8.2 平臺選擇前面上文說過可能存在多個平臺的抽獎活動，即使只是服務號抽獎，也可能存在多個服務號的切換問題，這些都是管理後臺需要考慮的。
多個平臺共存的情況下，針對不同的平臺也會有個性化設置，比如獎品數量可能在不同平臺有差別。例如 PC 抽 8 個，H5 抽 6 個這種情況。
8.3 創建活動 / 設置獎品 / 概率 / 運營欄位 / 是否需要關注分享 / 獎品信息即時修改創建活動要考慮多平臺，多服務號的互動設計；設置獎品主要考慮獎品類型對獎品設置的影響；
概率可以採用百分比，也可以直接設置中將區間，比如使用 1-10000 的數字來界定抽獎概率。至於運營欄位和是否需要關注、是否需要分享等細節，就有業務自己決定了。
獎品信息的增改查是基本操作，刪除一般只改變數據狀態，保留記錄流水。
8.4 發布操作保存和發布操作要儘可能做成兩步，即存在 「預發布」 狀態，或者只保存，不發布的狀態。
發布的時候需要注意的是，如果獎品的圖片不是跟著每條獎品信息一起的單張小圖，那麼就要保證全部獎品信息和獨立的獎品圖片（轉盤，背景等）同時生效。
否則這個抽獎操作可能就不是 「所見即所得」，抽到了現金可能實際發了積分。
8.5 用戶信息查詢 / 抽獎記錄查詢 / 緊急拉黑在用戶投訴過來的時候，我們首先要驗證用戶的真實身份，以及他對應的抽獎記錄是否存在。
比如通過用戶的手機號來查詢用戶抽獎記錄，或者客服系統接入用戶體系，從客服聊天窗口可以獲得用戶的 openid 或 uid 等信息，也可以根據這些信息來查詢。
最後一招，還可以根據用戶的 「我的獎品」 界面判斷：如果用戶拒絕提供 「我的獎品」 界面截圖，那說明他自己都看不到記錄，純是騙子。
如果他能提供記錄，那麼至少可以通過抽獎記錄的時間戳來查詢抽獎記錄。在秒級時間節點上同步抽獎的人數畢竟有限，查出後再通過獎品等信息進行篩查，一般是騙不到我們的。
8.6 冷啟動相關設置（排行榜 / 參與人數）排行榜問題前面已經多次提到過，這裡說說冷啟動，即初始排行榜的生成。有人會說，這不是造假嗎？但是，血淋淋的事實是，如果排行榜上一條記錄沒有，很多人都會直接關掉。
相反，即使明知道排行榜有可能是假的，大家也願意相信。毫不誇張的說，大部分抽獎活動都有這個冷啟動過程。
最簡單的辦法，是讓大量的內部用戶抽，只是不發獎。但是微信紅包想不發就比較麻煩，要關掉紅包接口，還要讓他能獲得抽中的記錄展示。
所以，最理想的情況，是用一批內部可信的真實用戶信息，根據每次活動的排行榜獎品配比，直接寫入抽獎記錄並生成排行榜緩存。
這樣在下次刷新緩存的時候，大獎仍然屹立不倒。而當有外部真實用戶抽中大獎的時候，也可以一樣按照配比刷新到排行榜上方。
參數人數由於只是個數字，比較好處理。只需要給出一個初始的數值，後面每次抽獎的人次累加上去即可。
注意，所有這種需要冷啟動的數字，都不能使用資料庫實時 count，否則只能用一次，再更新就會變回真實的數字。因此，資料庫只管累加，而不要管之前是多少就好了。
8.7 數據需求每個運營活動都有許多數據需求，從基本的 PV/UV，到最細節的用戶行為分析。對於抽獎活動，可能需要統計實時抽獎人數 / 次數，甚至同時在線人數。
另外，對於每個活動，每日每周可能都會有報表需求。因此，如果有獨立的報表平臺支持，就非常完美了。
8.8 獎品補發工具如果投訴的用戶經過我們驗證，真的是系統出了問題，那麼就需要一個方便的途徑去給用戶補發獎品。
比如微信紅包，可以在管理後臺直接調用紅包接口把錢補發給用戶，積分也一樣。而實物獎品，則是正常走郵寄流程發貨了。
8.9 權限管理同數據管理一樣，最好是有獨立的權限管理系統可以接入，如果沒有，那就只能自己開發個簡單的版本。或者以抽獎活動為契機，為公司開發一套完善的權限管理系統。
一個基本的權限系統要包含：系統管理、角色管理，權限管理等等，另外還有權限的申請與審批（可能結合 OA 系統），要做到權責分明，出了問題有據可查。對於沒有權限的，最好直接提示權限申請入口或申請途徑。
9. 運營相關一款成功的活動，需要投入大量的人力物力進行開發和運營。而對於固化的長期活動，更是需要體現運營功力的地方。
抽獎活動初期，如果只是瘋狂砸錢的話，是毫無疑問可以拉到粉絲的，但運營的意義就是在有限資金下獲得更好的效果，只砸錢誰不會呢？
而通過砸錢過來的用戶，如何能通過後續活動鞏固養成，使其成為我們真正的留存用戶，就沒有那麼簡單了。
我們先來了解一下什麼是誘導關注。根據《微信公眾平臺運營規範》第 3.3.2 誘導關注為：通過外鏈、公眾號群發或二維碼等方式，以獎勵或其他方式，強制或誘導用戶關注公眾號的行為。
獎勵的方式包括但不限於：實物獎品、虛擬獎品（積分、信息）等。若違反相關協議，微信會根據公眾帳號違規情況，對公眾帳號限制或禁止使用全部或部分功能、帳號封禁 / 註銷等相應處罰（http://kf.qq.com/faq/120911VrYVrA150916bYvUJR.html）。
是不是很可怕？大體上就是不能通過獎勵強制或誘導用戶關注公眾號，常見的就是先抽紅包再關注領現金的騙局。所以，我們是關注之後再抽，而且直接發錢。但是，樹大難免招風，帶有誘導關注的活動小打小鬧沒關係，微信不會注意到。一旦做大，就有風險，請大家自行把握。
9.2 冷啟動前面已經講過排行榜的冷啟動和人工幹預問題，其實冷啟動還包括初始沒有流量時如何引流。不過對於實實在在的現金抽獎，初次流量獲取相對容易，我們每天發一兩萬元給用戶，就不信沒人來。
9.3 可運營欄位設計可運營欄位設計包括：主題、轉盤、按鈕文案、提示語，跳轉連結等等，需要提前與運營同學溝通好可能出現的運營位，再結合已有的運營系統看看怎樣方便接入。
當然，無論最初想得多周全，上線後也總是要縫縫補補繼續增加需要運營的部分，所以，把這種事情當作常態就好。
9.4 多平臺共用 / 多活動並存 / 多版本並存 / 多狀態切換當你的業務涉及多個平臺，多個活動，多個版本的時候，在系統設計上就要考慮更多的多平臺運營之間的差異，以及各種切換問題。
9.5 客服對接對於抽獎活動來說，客服的壓力是比較大的，相應的開發也會消耗很多經歷用來查記錄，確認 BUG，核實信息等。後來，我們開發了一系列的運營工具，從用戶信息查詢、抽獎記錄查詢、到補發積分、補發優惠券，甚至各種批量補發工具，都可以很方便地應對這些日常投訴。
期間最典型的例子是截圖造假，用戶只發個疑似 「中獎」 的截圖過來要獎品，這時只需要查一下是否真的有抽獎記錄即可。另外，客服的話術也要約定好，各種情況下要統一話術，否則就會有糾紛。
9.6 沉迷設計抽獎系統一定程度上是要考慮沉迷設計的，通過適當的定期鼓勵來促進參與度。本文的例子中我們只實現了連續不中的必中邏輯，對於經常參與的用戶會有定期的獎勵回饋。更複雜的沉迷設計並不適用於 web 端抽獎這種相對低頻的遊戲操作。
9.7 審計需求跟錢打交道的業務，安全是第一位的。安全除了包含程序上的安全，還有人為因素，比如誤操作等。此外，如果有內部人員惡意操作等，也是要有據可查的。
因此，所有具有權限的人員操作流水，包括時間和結果等都要記錄在案。尤其是對於有價物品的發放日誌，補發積分、紅包、優惠券等操作記錄。對於公司年底審計的時候，也需要提供各種操作流水給審計公司。
最後，附上文章整體大綱結構
近期熱文
《高可用、高性能？ 接口設計的 16 個原則》
《【釣魚】與【反釣魚】的技術剖析》
《快速了解 Java 9 平臺模塊系統》
《機器人的「語料」，如何獲取？》
《一頁紙，梳理你的商業模式 ，奇妙的「精益畫布」》
引爆你的品牌
「閱讀原文」看交流實錄，你想知道的都在這裡