京东、淘宝的红包雨相信大家都参与过，其实业务并不复杂，在某段时间内随机发放不同的红包，用于进行抢单抽奖，直到奖品抽完。
应用场景时间随机
在一段时间内，设置一批礼品，这些礼品不定时的出现，尽量在这段时间内均匀抛出，一旦出现，就可以被抓走。类似抓红包。瞬间秒杀
用于抢单或者秒杀场景，到点后，用户一起抽奖，机会均等，谁抢的快算谁的。这个并发比较高。但是活动时间相对较短。机会随机
常见于转盘类活动。不同等级的用户，设定不同的中奖概率，一般配合设置用户最大可抽奖次数，比如5次机会， 能不能中奖，根据概率判定。一般活动时间设置的较长，比如几天。
系统要求
并发性
抽奖系统比如涉及到访问量大的问题。系统涉及所面临的第一关，即活动开始的瞬间，大批用户点击的涌入。怎样 设计系统以达到如此高并发情况下的及时响应是本项目的重中之重。库存控制
抽奖面临的必然是奖品。数量控制是必须要做到精准吻合。不允许出现设置了5个奖品，最终6人中奖这种类似的问题出现。其中的本质是奖品库存的控制。投放策略
在活动时间段内，管理员设置好的一堆奖品如何投放？红包何时出现？什么时候可以被抽中？这些都涉及到投放策略。边界控制
活动何时开始？何时结束？倒计时如何控制。这涉及到活动的边界。开始前要提防用户提前进入抽奖。结束后要即使反馈结果给用户，告知活动已结束。活动自由配置
活动的配置由后台管理员完成，可以自由配置活动的开始结束时间，主题、活动简介、有哪些奖品、不同等级的用户中奖的策略。这就要求系统必须具备足够的业务灵活度。中奖策略
每个用户参与抽奖后，要遵从后台管理员所设定的中奖策略，典型的场景是最大抽奖次数和最大中奖次数。
技术架构
技术架构拆分为调度服务、消息服务、鉴权服务、红包服务、商品服务等多个微服务，并搭建API网关、注册中心、配置中心等基础设施。
- 后台springboot启动微服务模块;前台静态文件分离，nginx或者cdn直接响应，不要再绕后台应用机器；
- 考虑并发量较高情况下，为减少带宽压力，可临时租借CDN进行挂载；
- 将模块细粒度拆分，如：调度服务、消息服务、鉴权服务、红包服务等，平台微服务化；借助k8s等容器管理功能，实现不同服务的副本部署，滚动更新；
- 多个实例之间通过nginx做负载均衡，提升并发性能；红包服务负载较高，可以考虑部署多个节点，进行负载均衡；
- 中奖后，中奖人及奖品信息要持久化到数据库。引入rabbitmq，将抽奖操作与数据库操作异步隔离。抽奖中奖后，只需要将中奖信息放入rabbitmq，并立即返回中奖信息给前端用户。后端msg模块消费rabbitmq消息，缓慢处理。
- 每隔1分钟扫描一次活动表，查询未来1分钟内将要开始的活动。将扫到的活动加载进redis，包括活动详细信息，中奖策略信息，奖品信息，抽奖令牌。活动正式开始后，基于redis数据做查询，不必再与数据库打交道。
