红包雨架构设计---1、技术架构

概述

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

应用场景

• 时间随机
  在一段时间内，设置一批礼品，这些礼品不定时的出现，尽量在这段时间内均匀抛出，一旦出现，就可以被抓走。类似抓红包。
• 瞬间秒杀
  用于抢单或者秒杀场景，到点后，用户一起抽奖，机会均等，谁抢的快算谁的。这个并发比较高。但是活动时间相对较短。
• 机会随机
  常见于转盘类活动。不同等级的用户，设定不同的中奖概率，一般配合设置用户最大可抽奖次数，比如5次机会， 能不能中奖，根据概率判定。一般活动时间设置的较长，比如几天。

系统要求

• 并发性
  抽奖系统比如涉及到访问量大的问题。系统涉及所面临的第一关，即活动开始的瞬间，大批用户点击的涌入。怎样 设计系统以达到如此高并发情况下的及时响应是本项目的重中之重。
• 库存控制
  抽奖面临的必然是奖品。数量控制是必须要做到精准吻合。不允许出现设置了5个奖品，最终6人中奖这种类似的问题出现。其中的本质是奖品库存的控制。
• 投放策略
  在活动时间段内，管理员设置好的一堆奖品如何投放？红包何时出现？什么时候可以被抽中？这些都涉及到投放策略。
• 边界控制
  活动何时开始？何时结束？倒计时如何控制。这涉及到活动的边界。开始前要提防用户提前进入抽奖。结束后要即使反馈结果给用户，告知活动已结束。
• 活动自由配置
  活动的配置由后台管理员完成，可以自由配置活动的开始结束时间，主题、活动简介、有哪些奖品、不同等级的用户中奖的策略。这就要求系统必须具备足够的业务灵活度。
• 中奖策略
  每个用户参与抽奖后，要遵从后台管理员所设定的中奖策略，典型的场景是最大抽奖次数和最大中奖次数。

技术架构

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

设计原则

动静分离

1. 后台springboot启动微服务模块;
2. 前台静态文件分离，nginx或者cdn直接响应，不要再绕后台应用机器；

CDN

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

微服务化

1. 将模块细粒度拆分，如：调度服务、消息服务、鉴权服务、红包服务等，平台微服务化；
2. 借助k8s等容器管理功能，实现不同服务的副本部署，滚动更新；

负载均衡

1. 多个实例之间通过nginx做负载均衡，提升并发性能；
2. 红包服务负载较高，可以考虑部署多个节点，进行负载均衡；

异步消息

1. 中奖后，中奖人及奖品信息要持久化到数据库。引入rabbitmq，将抽奖操作与数据库操作异步隔离。
2. 抽奖中奖后，只需要将中奖信息放入rabbitmq，并立即返回中奖信息给前端用户。
3. 后端msg模块消费rabbitmq消息，缓慢处理。

缓存预热

1. 每隔1分钟扫描一次活动表，查询未来1分钟内将要开始的活动。
2. 将扫到的活动加载进redis，包括活动详细信息，中奖策略信息，奖品信息，抽奖令牌。
3. 活动正式开始后，基于redis数据做查询，不必再与数据库打交道。