您已获得免费畅听价值989元全栈运营微课的资格。
一个（相对）完整的抽奖活动，都需要考虑哪些东西？
（右击，在新标签页中打开即可查看大图）
抽奖活动，应该算是最古老的运营活动之一了，无论线上还是线下，商场还是超市，大转盘都无处不在。
当然，关于留存的部分，就不只是发钱这么简单了，还需要结合其他促销活动一起才能留住真正的优质用户。
这至少说明，基于服务号的完善的抽奖系统，是具有一定价值的。当然，作为公司来讲，我们不会去赚这些小钱，毕竟我们不是程序外包公司~
那么，本篇我们就来探讨一下，一个（相对）完整的抽奖活动，都需要考虑哪些东西。
这里简单带过一些平台上可能产生的差异：
PC上需要考虑的主要是不能直接发红包的问题，电脑上的抽奖活动存在好多年，除了抽取积分、卡券、实物等，没有什么实质性的变化。
另外一点就是大量的兼容性问题，比如圆形的转盘动画在低级IE浏览器就很难实现，所以之前许多抽奖活动都是用flash解决方案。
除了兼容性问题少了一点（真的吗？）外，其他与PC特性差异不大。
这是我认为的最佳选择，撒钱真的很方便！而且开发也不复杂，服务号开发文档非常完善。
目前笔者在淘宝开放平台还没有看到第三方应用的发放红包接口，即使有这种接口，作为第三方的应用，商户资金管理和审计也比较复杂，店铺不会把这种发放资金的能力交给第三方应用开发者的。
当然，对于正规的企业来讲，这些都不是问题，正常走流程跟公司申请对公账户打款即可。
抽奖活动的界面设计主要要提现欢快热烈的活动氛围，但也不宜天马行空随意发挥，因为我们后面还有代码实现和运营的问题。比如整个页面的背景结构如果过于复杂，或者由于动效缘故要拆成若干部分，那么在更换抽奖活动主题的时候，就要做更多的改动。
对于抽奖动画我们也有很多选择，比如圆盘（指针转，圆盘转）、滚球、方盘跑马灯等。所有你在游乐场、澳门赌场等看到的抽奖玩法，都可以想办法移植到活动中来。
这是个前端开发问题。对于动画执行的时机，最简单的实现就是先去请求服务器，拿到抽奖结果之后再执行动画。缺点就是，网络慢或者服务器响应慢的时候可能会有短暂等待。
而最接近真实世界的方式，就是当用户点击抽奖时动画就启动，当获取到抽奖结果时动画就结束。显然，这事儿没那么简单。
首先，动画都是有过渡效果的，拿到抽奖结果后不可能戛然而止。其次，如果在请求抽奖结果的过程中网络卡顿一直拿不到结果怎么办？如果中间服务器报错了怎么办？请求没有响应要不要再尝试几次？在这个过程中动画怎么处理？
最后，假设我们对外宣称是『100%中奖』，那么多次尝试之后服务器确实没有响应，转盘或指针要落在哪里？什么？落在最便宜的奖品吗？那么服务器没有记录可查，用户截屏过来要奖品，你给还是不给？
这里我们的策略是：用户点击抽奖则转盘开始转动，且开始请求抽奖结果。转盘从开始转动到最后结束分为三个阶段，即加速→匀速→减速。
那么，如果最后真的报错了呢？你可以考虑让指针停在两个奖品中间，但是这样仍然会有争议。首先是太像BUG，其次用户会说他一定会得到两侧的某个奖品，只是你这个东西出错了停在了中间。
所以，最保险的方案，就是永远不要宣称『100%中奖』，永远保留『谢谢参与』用来兜底。
多数情况下，抽奖界面上都会有个类似排行榜的模块，用来展示中奖用户和诱人的奖品。这里在界面上没有太多东西，不过是各种循环滚动动画、展示用户昵称头像等，如果是手机号，记得在CGI层面打码，不要泄露用户隐私就好。
基本的表单提交需要前端的验证，对于抽奖业务中的实物奖品，则需要类似地址选择组件搜集用户收件地址。更严格一点，手机号需要验证码来验证真实性，确保能够联系到用户。
再进一步，可以利用GPS定位能力，自动获取用户所在区域，只需要补充详细地址即可。现在许多快递公司或者有外送服务的服务号，都实现了类似功能，具体不再展开。
至于openid是否作为用户的唯一标识，有许多种处理方法，一般还是建议自己维护一套用户id系统，不要直接暴露openid为好。
一来只用openid标识用户，容易被羊毛党刷单，二来如果对于价值比较高的有价产品，可能还是希望他注册。而注册之后还要绑定之前的抽奖结果，而这个过程就可能带来安全风险。
抽奖主接口主要用来获取中奖状态、奖品信息等。这个接口将会是承受压力最大的一个接口，因为总会有人试图单独刷这个接口，所以所有的防御机制都要体现在这个接口上，具体我们后面再聊。
对于接口吐出的信息多少也是要严格控制的，比如奖品的库存、中奖概率等信息。基本上，如果是简单的抽奖，那么这个接口只需要告诉用户是否中奖即可，也可以加上剩余抽奖资格等信息。
另外，部分安卓手机可能会缓存页面，如果在下一步操作中改变了抽奖资格（次数，积分变化等），再直接点击左上角返回，次数可能就不会变化。
因此，最好再抽奖动作之前先强制更新一下抽奖资格，而不是直接等待抽奖主接口返回不能抽奖的错误，因为这样会导致用户看到界面上有资格，但是每次点了之后又不能抽。这种情况下，还不如一次就让用户死心，如果真有投诉就如实相告，告诉用户手机有缓存问题。
但如果你希望再给用户开放领取入口，比如在类似“我的奖品”这样的页面再次领取的话，就需要判断用户是否领过此卡券。
这个接口只在一种情况下使用，即“未注册”之前允许抽奖，“注册”之后领奖的情况。注意这里的“未注册”和“注册”都加了双引号，是因为这两个词对于不同的平台不同的业务意义也不同，需要您自己去界定，什么是注册，什么是未注册。
该接口是否需要以及其复杂的程度，取决于您的业务需要，即抽奖活动在线时有多少需要实时运营的内容。比如用户欢迎语、抽奖成功/失败后的引导语等等，重点是如何能与自身的运营系统结合，方便运营同学使用。
抽奖活动往往有类似排行榜，参与人数等信息的展示。对于访问量较大的抽奖活动，这种信息一定是有缓存方案的，不可能每次都去查询数据库实时计算。
那么，既然有缓存，就有清除缓存操作，有时可能还涉及到冷启动造数据等，后面我们再详细讲解。
当缓存再次刷新时，即使排名顺序有变化，或者被挤出排行榜，就都是正常的展示了。而对于定期清理缓存的机制，可以使用linux系统自带的crontab或其他常驻的deamon脚本均可。
根据业务需要，抽奖活动可能还包含我的奖品、抽奖规则、抽奖结束页，通用错误页等，这些页面基本上只需要考虑运营内容和经常变化的逻辑即可。
比如新增了奖品类型，在我的奖品页要怎么展示；如果有新的活动主题，是否方便修改之前的奖品图标风格等。
另外，即使是你记着要把所有接口都关掉，但是每次全部要手动修改全部接口，就不是很方便了。
逻辑层的设计，大体与前面的接口设计对应，这里只单独拿出一些值得讨论的点说一下。
如果要实现跟手机号绑定，那就需要自己建立一套手机号与各个平台openid的对应关系。
或者单纯只有服务号的openid与自建用户体系的对应关系，向用户派发uid+ukey来识别用户，而不是直接使用openid作为用户标识。
抽奖资格可以通过多种方式实现，例如通过其他活动派发抽奖次数，甚至免费赠送抽奖次数，或者通过自建用户体系的积分体系实现抽奖资格。
而对于其他活动渠道获得的抽奖次数，则需要抽奖系统对外提供增加次数的能力，如果多个活动共用或多种获取渠道共用，则还要区分该资格来自哪个渠道。
增加次数接口如果是对外暴露的，则有被多加的风险，因此不建议前端直接使用ajax异步调用新增次数，而是要把新增次数的逻辑混合在活动的逻辑中，经过严格的判断再在CGI层面处理完成。
如果是新用户进来默认赠送次数的，则一定会导致羊毛党使用大量帐号刷单。对于这种活动的奖品和概率设置，必然是要尽量降低成本，降低概率，这样即使是羊毛党也不会使我们造成过大损失。
羊毛党其实是无法完全杜绝的，因为在系统层面看来，很多时候就是大量的真实用户。所以我们只能在成本和风险上进行控制和权衡，无法完全避免，也不能误伤太多真实用户。
如果您的抽奖活动还需要派发其他奖品，比如商家自己实现的优惠券、邮寄实物奖品、各种会员卡体验名额等，则需要结合自身业务实现发放接口，再供抽奖系统调用。
同样，仍然需要注意实际发放资格的判断是否完善，以及如何判断刷单和作弊等。
从发放奖品的大体倾向来看，一般有两种玩法。
一种是尽快把奖品都抽完，即土豪要尽量保证奖品发完。这种抽奖有时效性，虽然先来后到对概率没影响，但是晚了可能奖品被抽完；另外一种是，尽量保证更多的人次参与，奖品不要太快消耗。
这种抽奖参与人次分布相对均匀，但是对于单次活动，且没有手动调整抽奖概率的情况下，不能保证奖品都被抽完。
第一种场景的典型例子，就是公司年会，奖品固定人数固定，且要求在晚会上必须抽完。这种场景下抽奖的概率是需要系统动态计算的，根据已知的库存和原始概率，如果人次达到某个阈值还没有抽完就自动增加一点点概率。
当然，这种情况也可以用奖品来抽人，比如先固定本次抽取iPhoneX，再来随机是哪个人。什么？伪随机数不够随机？whocares~
现场抽奖重要的是公平透明，如果用了复杂的抽奖系统反倒不能服众，搞不好来个现场review代码，所以即使是伪随机数的抽奖，也比复杂系统强。
再说第二种，它的特点就是同样的奖品数量消耗较慢，那么对于长期固化的活动来说，一定是希望最小的成本获得最多的参与。即使是时效非常短的抽奖活动，也没有非要把奖品都送出去的道理。
因此，这个场景下不会让系统动态调整概率，而是采用人工控制概率的方式。对于单个抽奖用户来说，中奖区间是恒定的，即使抽了很多次，也不会扩大中奖概率。
这样也可以防止恶意刷单，一切能够通过数量提升中奖概率的活动，最后都可能被刷单，除非你不在乎这些成本。
人工控制还有个好处就是，发现刷单后可以及时调整概率防止损失扩大，另外如果奖品发放变慢，也可以人工提升概率保持活跃度。
只是要在用户身上记录一个连续不中的次数。不过，值得注意的是，如果多个抽奖活动的连续不中次数不能共用，那就要扩展多个存储字段来区分了。
对于这些只需要判定而不需要用来排序的字段，可以统一用一个扩展字段，以JSON的形式存在数据表中，避免频繁修改DB结构。
此外，如果配合管理系统，让运营同学去新建抽奖活动和新增奖品，那么就要明确标识出到底哪个奖品可以作为连续不中自动发放的。要么用明显的标记和提示，要么单独一个字段设置这种通用奖品。
如果由于提示不明显，把188元现金当成了连续不中补偿，那就有点过于土豪了。
接5.5，如果你只希望连续不中的用户提升一定的中奖概率的话，实现思路就又不同了。中奖概率本身这个事，分散到多个奖品上面，就不是简单的可以提升概率的问题了。
所以，更简单的做法是，把用户抽奖时获得的随机数扩大范围。比如我的概率范围相当于1-10000的随机数，如果用户获得的是3000这个随机数，那么10%的概率相当于1000个单位，因此给用户提升10%的中间概率可以粗略地转化为：在2500–3500之间如果有命中奖品中奖区间，就都算中奖。
上文3.3中说过，最好始终保留“谢谢参与”兜底，那么如果运营要求本次活动一定要所有都有奖品呢？
所以，如果你担心有这种需求变更的风险，最好把所有的奖品位置都设计成可以作为普通奖品，也可以作为特殊位置（谢谢参与，没有奖品等）。
那么，抽奖资格可能是10积分每次，所以用户账户中必须有10积分以上才可抽奖；如果是次数抽奖，一般来说用户账户中只要1次资格就可以抽奖。
综上，对于不同类型的奖品，是要考虑资格和库存判断标准的不同的，这里可以采用配置文件的方式将可能的奖品类型和判断标准列出即可，方便修改。
这里一定要加入uid是由于商户平台的资金流水只包含用户的openid，不方便与自身的用户体系对应，所以在业务ID中混入uid方便查询信息。当然，也可以使用红包接口的扩展字段记录用户信息。
这里的实物奖品是个通用的类型，对于一切无法通过程序直接发放给用户，或者用户不能直接通过页面领取的，都可以归为实物奖品。
因此，如果一定要走支付宝红包，可以采用抽中红包口令，但不能防止用户直接把口令发给别人。或者是抽中后，让用户输入支付宝账户，然后再想办法人肉或批量操作转账。
总之，这里每次新增一种奖品，就可能新增一部分开发工作量，因为设计情况较多无法提前兼容。
用户的抽奖记录要尽可能记录更多的信息，因为每天都会有用户以各种理由找客服投诉（除非你不给投诉入口）。
其间不乏许多无理取闹直接来骗奖品的用户，比如在移动端转盘动画旋转的的时候拖动手机让转盘暂停，或者干脆用PhotoShop合成中奖状态的。
这时候，我们唯一能依赖的就是用户的抽奖记录了，只要记录中不存在或者记录异常，就可以坚决判定本次中奖是假的。例如，用户当时的中奖随机数，奖品信息的快照（当时的文案、库存等）等。
而对于用户自身的抽奖记录，即“我的奖品”页面的展示，则要考虑大量不中的情况下，“谢谢参与”是否要隐藏。
如果谢谢参与要隐藏，那么按照5.7中的要求如果这个位置变成了普通奖品，又要以什么样的判断依据来决定是展示还是隐藏。
上文4.8讲了排行榜的缓存清除，这里我们讨论下排行榜的构成。看似简单的排行榜，其实并不简单。首先，除非你的奖品非常丰厚，中奖概率非常高，所有人皆大欢喜。
所以，排行榜上要尽量放“大奖”的用户抽奖记录才有吸引力，比如前五名都中了iPhoneX，虽然用户未必真信，但是氛围效果还是达到了。
综上，排行榜的构成不是简单的抽奖记录倒序，而是按照一定的奖品配比生成的。因此，不同的活动不同的奖品就要考虑排行榜配比不同的问题，这里也可以通过配置文件来实现。
风险控制包含很多方面，对于整个系统的全流程都有涉及。最基本的DB层面的事务处理，运营系统的金额控制，有价奖品总开关等，这些细节将会分散在各个章节。
数据层面的设计要包含上文提到的所有想关信息字段，大体上与业务逻辑是对应的，对于简单的抽奖活动，可能单表即可搞定。而要满足上文提到的大部分逻辑，那么该系统至少要包含以下数据表：
奖品表主要包含：活动ID（平台维度/活动维度），概率（区间/百分比），奖品基本信息（名称/描述/库存/图片/领券码/现金范围等），各种运营文案/按钮设置/跳转链接等。
抽奖记录表（依据数据量分表）主要包含：抽奖记录表（用户基础信息冗余/奖品信息冗余/抽奖动作快照/抽奖随机数），抽奖记录归档表（无需展示的抽奖记录定期归档）。
由于具体的表设计较少有共性可言，因此不再赘述，具体的表结构我也不粘贴了，大致思路都是类似的。
抽奖系统如果真的火了的话，会对服务器造成非常大的压力。现在无论大小公司，许多都已经采用云服务来实现，既可以方便地扩容，承受更大业务量，也可以拥有更安全的保障，更专业的服务。
如果采用阿里云的服务，一般是SLB（负载均衡）+ECS（云服务器）+RDS（云存储）+CDN（内容分发网络）组合。
这里不推荐用云服务器自建的数据库服务，一来性能有限，二来要自己写守护进程防止数据库挂掉，最后，还要自己实现各种备份脚本，成本高又不可靠，真的不如直接购买云服务。
抽奖活动推送期间，我们大概使用5-10台ECS来承接抽奖活动流量，即使真的有压力，也可以快速扩容。
对于高并发的活动DB，索引的重要性就非常突出了。平时做些小网站小打小闹可能根本不需要建立数据库索引，而在高并发的时候，一切问题都会被放大。
因此，关键数据表，关键查询，组合查询等，都要提前建立好索引。而复杂的联表查询，如能转换成两次单表查询，则效率更高。
类似用户表和抽奖记录表这种有可能单表数据量过大的情况，可以提前考虑分表，比如给用户按uid分100张表。
常用的缓存方案有许多，对于排行榜、总人数这种需求，建议采用Redis缓存，因为其用法简单，查询速度快，与各种语言结合友好。
需要注意的是Redis服务器的账户和访问权限问题，初次使用的同学很可能不设置Redis的账户和端口，那么你的缓存就很有可能被其他人直接读取甚至写入。
每个公司都有自己的基础服务监控系统，或多或少。那么抽奖活动也尽量接入这些系统，比如可用性监控，服务器性能，接口访问量/失败量/告警等。
如果本身没有类似的系统，那么也可以针对抽奖单独开发一些监控功能，但成本会相对较高了。
安全是个大课题，我也不是专家，简单说一下抽奖业务常用的一些方案吧。比如，基本的防刷机制可能包括：Nginx动态封IP，缓存层限制操作频次（防止高并发写入），数据层限制操作数量与频次，薅羊毛的度等等。
对于这种情况，一般没地方说理去。目前已知的唯一办法，就是活动不要搞太热烈，细水长流比较好。
活动管理后台可繁可简，如果在抽奖业务之前已经有了部分运营机制和能力，且能方便地用在抽奖系统就最好。
如果不能，那么可以考虑开发通用的活动管理平台，或者针对抽奖系统订制完善的运营平台。
这里简单罗列一下，抽奖的管理后台可能要考虑到哪些能力。
奖品库存，概率等属于敏感操作，是必须要有操作日志的。至于具体操作的人员通过什么来识别，可以考虑使用内部的帐号系统，或手机号等。权限控制+日志记录都是必不可少，否则很可能钱都不知道怎么没的。
另外，对于大一点的企业可能还有审计需求，审计公司会要求你实现这些记录功能，作为年终审计的依据。
前面上文说过可能存在多个平台的抽奖活动，即使只是服务号抽奖，也可能存在多个服务号的切换问题，这些都是管理后台需要考虑的。
多个平台共存的情况下，针对不同的平台也会有个性化设置，比如奖品数量可能在不同平台有差别。例如PC抽8个，H5抽6个这种情况。
创建活动要考虑多平台，多服务号的交互设计；设置奖品主要考虑奖品类型对奖品设置的影响；
奖品信息的增改查是基本操作，删除一般只改变数据状态，保留记录流水。
保存和发布操作要尽可能做成两步，即存在“预发布”状态，或者只保存，不发布的状态。
发布的时候需要注意的是，如果奖品的图片不是跟着每条奖品信息一起的单张小图，那么就要保证全部奖品信息和独立的奖品图片（转盘，背景等）同时生效。
否则这个抽奖操作可能就不是“所见即所得”，抽到了现金可能实际发了积分。
在用户投诉过来的时候，我们首先要验证用户的真实身份，以及他对应的抽奖记录是否存在。
比如通过用户的手机号来查询用户抽奖记录，或者客服系统接入用户体系，从客服聊天窗口可以获得用户的openid或uid等信息，也可以根据这些信息来查询。
最后一招，还可以根据用户的“我的奖品”界面判断：如果用户拒绝提供“我的奖品”界面截图，那说明他自己都看不到记录，纯是骗子。
排行榜问题前面已经多次提到过，这里说说冷启动，即初始排行榜的生成。有人会说，这不是造假吗？但是，血淋淋的事实是，如果排行榜上一条记录没有，很多人都会直接关掉。
相反，即使明知道排行榜有可能是假的，大家也愿意相信。毫不夸张的说，大部分抽奖活动都有这个冷启动过程。
所以，最理想的情况，是用一批内部可信的真实用户信息，根据每次活动的排行榜奖品配比，直接写入抽奖记录并生成排行榜缓存。
这样在下次刷新缓存的时候，大奖仍然屹立不倒。而当有外部真实用户抽中大奖的时候，也可以一样按照配比刷新到排行榜上方。
参数人数由于只是个数字，比较好处理。只需要给出一个初始的数值，后面每次抽奖的人次累加上去即可。
注意，所有这种需要冷启动的数字，都不能使用数据库实时count，否则只能用一次，再更新就会变回真实的数字。因此，数据库只管累加，而不要管之前是多少就好了。
每个运营活动都有许多数据需求，从基本的PV/UV，到最细节的用户行为分析。对于抽奖活动，可能需要统计实时抽奖人数/次数，甚至同时在线人数。
另外，对于每个活动，每日每周可能都会有报表需求。因此，如果有独立的报表平台支持，就非常完美了。
如果投诉的用户经过我们验证，真的是系统出了问题，那么就需要一个方便的途径去给用户补发奖品。
同数据管理一样，最好是有独立的权限管理系统可以接入，如果没有，那就只能自己开发个简单的版本。或者以抽奖活动为契机，为公司开发一套完善的权限管理系统。
一个基本的权限系统要包含：系统管理、角色管理，权限管理等等，另外还有权限的申请与审批（可能结合OA系统），要做到权责分明，出了问题有据可查。对于没有权限的，最好直接提示权限申请入口或申请途径。
一款成功的活动，需要投入大量的人力物力进行开发和运营。而对于固化的长期活动，更是需要体现运营功力的地方。
而通过砸钱过来的用户，如何能通过后续活动巩固养成，使其成为我们真正的留存用户，就没有那么简单了。
前面已经讲过排行榜的冷启动和人工干预问题，其实冷启动还包括初始没有流量时如何引流。不过对于实实在在的现金抽奖，初次流量获取相对容易，我们每天发一两万元给用户，就不信没人来。
可运营字段设计包括：主题、转盘、按钮文案、提示语，跳转链接等等，需要提前与运营同学沟通好可能出现的运营位，再结合已有的运营系统看看怎样方便接入。
当然，无论最初想得多周全，上线后也总是要缝缝补补继续增加需要运营的部分，所以，把这种事情当作常态就好。
当你的业务涉及多个平台，多个活动，多个版本的时候，在系统设计上就要考虑更多的多平台运营之间的差异，以及各种切换问题。
对于抽奖活动来说，客服的压力是比较大的，相应的开发也会消耗很多经历用来查记录，确认BUG，核实信息等。后来，我们开发了一系列的运营工具，从用户信息查询、抽奖记录查询、到补发积分、补发优惠券，甚至各种批量补发工具，都可以很方便地应对这些日常投诉。
期间最典型的例子是截图造假，用户只发个疑似“中奖”的截图过来要奖品，这时只需要查一下是否真的有抽奖记录即可。另外，客服的话术也要约定好，各种情况下要统一话术，否则就会有纠纷。
抽奖系统一定程度上是要考虑沉迷设计的，通过适当的定期鼓励来促进参与度。本文的例子中我们只实现了连续不中的必中逻辑，对于经常参与的用户会有定期的奖励回馈。更复杂的沉迷设计并不适用于web端抽奖这种相对低频的游戏操作。
跟钱打交道的业务，安全是第一位的。安全除了包含程序上的安全，还有人为因素，比如误操作等。此外，如果有内部人员恶意操作等，也是要有据可查的。
【转载说明】若上述素材出现侵权，请及时联系我们删除及进行处理：8088013@qq.com