200人抽奖代码思路 一、分析结果 老板让做个抽奖的功能，抽奖到底该怎么做？ - 前端分析 大家都知道前端显示的数据，都是可以修改的，数据都不正确。有些抽奖逻辑代码写在前端文件中，这种只是针对不懂技术的人员，稍微懂些技术的肯定忽悠不住。 二、概率 公平性，公平性怎么做？上面的代码就是根据概率来实现，大奖概率低小奖概率低。这个就是随机的，全凭运气这个词。 不公平，这种的话就靠逻辑来实现来。比如，某个时间段提高中奖概率。还有一种情况直接代码里面判断某个用户直接中xx奖。这种就是所谓的内在用户，白名单用户。 库存 奖品千万要设置库存，千万要设置，千万要设置。好了，重要的事情已经说了三遍了 。 三、讲讲并发的场景 以前Reids没出场的时候，做起来真的麻烦。现在好了，很大并发我们可以交给Redis来扛了。Redis 官方数据官方表示Redis读的速度是110000次/s,写的速度是81000次/s 。 Redis单机支持万级别的别分可以是很轻松，一般小公司足够用了。 不会出现你们所说的超卖现象。顺便说一句如果要10万+的需求可以使用 Reids replication模式。 四、每个人只能抽奖一次 这种场景可以看看Redis Incr 命令，Redis key再加上用户的ID代表用户的唯一键，根据自增和原子性能保证唯一还能抗大并发。 Redis Incr 命令将 key 中储存的数字值增一。 如果 key 不存在，那么 key 的值会先被初始化为 0 ，然后再执行 INCR 操作。 如果值包含错误的类型，或字符串类型的值不能表示为数字，那么返回一个错误。 本操作的值限制在 64 位(bit)有符号数字表示之内。 我们线上很多场景都用到过Incr命令。 五、1个小时只能抽奖一次 这种时候用Reis 的Expire 命令，Redis Expire 命令用于设置 key 的过期时间，key 过期后将不再可用。单位以秒计。顺便说个题外话，实现原理和Redis 的Set 命令差不多， 只有当然取这个key的时候，它才会判断当前key有没有失效。也就是Expire命令过期策略是你Get用到这个可key的时候才判断当前的key有没有失效。 六、Nginx 其实Nginx也有对应的模块抗并发做拦截，根据Ip来做黑名单的拦截。当有人来刷接口，大量的黑产IP过来抽奖，这个时候就要根据你们的场景来增加抽奖门槛。比如你在我们公司注册过，或者你10天前预约过抽奖活动，这些都是例子，可以根据场景来调整。 这个就是道高一尺魔高一丈，怎么说呢？和黄牛斗其乐无穷。我们以前就遇到过很多IP来刷接口，黄牛来搞事情的场景。Nginx做一层防护，Redis再做一层防护，这样经过层层的筛选 打到数据库的流量就很少了许多。 本文来源：https://www.wddqw.com/doc/4963a1dbfbc75fbfc77da26925c52cc58bd690e4.html