红包雨架构设计---1、技术架构-灵析社区

概述

京东、淘宝的红包雨相信大家都参与过，其实业务并不复杂，在某段时间内随机发放不同的红包，用于进行抢单抽奖，直到奖品抽完。

在一段时间内，设置一批礼品，这些礼品不定时的出现，尽量在这段时间内均匀抛出，一旦出现，就可以被抓走。类似抓红包。

用于抢单或者秒杀场景，到点后，用户一起抽奖，机会均等，谁抢的快算谁的。这个并发比较高。但是活动时间相对较短。

常见于转盘类活动。不同等级的用户，设定不同的中奖概率，一般配合设置用户最大可抽奖次数，比如5次机会，能不能中奖，根据概率判定。一般活动时间设置的较长，比如几天。

抽奖系统比如涉及到访问量大的问题。系统涉及所面临的第一关，即活动开始的瞬间，大批用户点击的涌入。怎样设计系统以达到如此高并发情况下的及时响应是本项目的重中之重。

抽奖面临的必然是奖品。数量控制是必须要做到精准吻合。不允许出现设置了5个奖品，最终6人中奖这种类似的问题出现。其中的本质是奖品库存的控制。

在活动时间段内，管理员设置好的一堆奖品如何投放？红包何时出现？什么时候可以被抽中？这些都涉及到投放策略。

活动何时开始？何时结束？倒计时如何控制。这涉及到活动的边界。开始前要提防用户提前进入抽奖。结束后要即使反馈结果给用户，告知活动已结束。

活动的配置由后台管理员完成，可以自由配置活动的开始结束时间，主题、活动简介、有哪些奖品、不同等级的用户中奖的策略。这就要求系统必须具备足够的业务灵活度。

每个用户参与抽奖后，要遵从后台管理员所设定的中奖策略，典型的场景是最大抽奖次数和最大中奖次数。

技术架构拆分为调度服务、消息服务、鉴权服务、红包服务、商品服务等多个微服务，并搭建API网关、注册中心、配置中心等基础设施。

后台springboot启动微服务模块;

前台静态文件分离，nginx或者cdn直接响应，不要再绕后台应用机器；

CDN

考虑并发量较高情况下，为减少带宽压力，可临时租借CDN进行挂载；

将模块细粒度拆分，如：调度服务、消息服务、鉴权服务、红包服务等，平台微服务化；

借助k8s等容器管理功能，实现不同服务的副本部署，滚动更新；

多个实例之间通过nginx做负载均衡，提升并发性能；

红包服务负载较高，可以考虑部署多个节点，进行负载均衡；

中奖后，中奖人及奖品信息要持久化到数据库。引入rabbitmq，将抽奖操作与数据库操作异步隔离。

抽奖中奖后，只需要将中奖信息放入rabbitmq，并立即返回中奖信息给前端用户。

后端msg模块消费rabbitmq消息，缓慢处理。

每隔1分钟扫描一次活动表，查询未来1分钟内将要开始的活动。

将扫到的活动加载进redis，包括活动详细信息，中奖策略信息，奖品信息，抽奖令牌。

活动正式开始后，基于redis数据做查询，不必再与数据库打交道。