java抽奖系统（八）

9. 抽奖模块

9.1 抽奖设计

        抽奖过程是抽奖系统中最重要的核⼼环节，它需要确保公平、透明且⾼效。以下是详细的抽奖过程设计：

        对于前端来说，负责控制抽奖的流程，确定中奖的人员

        对于后端来说：

                接口1：查询完整的活动信息

                接口2： 前端确定好中奖的人员之后奖人员信息发送给后端，后端完整的保存好中奖信息。（扭转活动，奖品，人员状态，有的奖品抽完了，有的人员中奖了就不能参加下一个等级的抽奖了，这个活动是不是已经抽奖结束了）（完成中奖人员通知的操作）

                接口三：查询中奖列表。

9.2 查询活动完整信息接口

        activityDetailDTO类里面包含抽奖活动所需要的所有参数。

        前端：向后端发起请求，从redis中查询相关的数据（如果没有存储，或者redis中的缓存过期，就会查询相关的数据库表，整合所需要的所有数据，再一次存放到redis中），最后奖数据返回给前端。

controller：

 @RequestMapping("/activity-detail/find")public CommonResult<GetActivityDetailResult> getActivityDetail(Long activityId) {logger.info("ActivityController getActivityDetail activityId:{}", activityId);ActivityDetailDTO detailDTO = activityService.getActivityDetail(activityId);return CommonResult.success(convertToGetActivityDetailResult(detailDTO));}private GetActivityDetailResult convertToGetActivityDetailResult(ActivityDetailDTO detailDTO) {if (detailDTO == null) {throw new ControllerException(ControllerErrorCodeConstants.GET_ACTIVITY_DETAIL_ERROR);}GetActivityDetailResult result = new GetActivityDetailResult();result.setActivityId(detailDTO.getActivityId());result.setActivityName(detailDTO.getActivityName());result.setDescription(detailDTO.getDesc());result.setValid(detailDTO.valid());// 抽奖顺序：一等奖、二、三result.setPrizes(detailDTO.getPrizeDTOList().stream().sorted(Comparator.comparingInt(prizeDTO -> prizeDTO.getTiers().getCode()))//按照奖品code1,2,3等奖来进行从小到大的排序.map(prizeDTO -> {GetActivityDetailResult.Prize prize = new GetActivityDetailResult.Prize();prize.setPrizeId(prizeDTO.getPrizeId());prize.setName(prizeDTO.getName());prize.setImageUrl(prizeDTO.getImageUrl());prize.setPrice(prizeDTO.getPrice());prize.setDescription(prizeDTO.getDescription());prize.setPrizeTierName(prizeDTO.getTiers().getMessage());prize.setPrizeAmount(prizeDTO.getPrizeAmount());prize.setValid(prizeDTO.valid());return prize;}).collect(Collectors.toList()));result.setUsers(detailDTO.getUserDTOList().stream().map(userDTO -> {GetActivityDetailResult.User user = new GetActivityDetailResult.User();user.setUserId(userDTO.getUserId());user.setUserName(userDTO.getUserName());user.setValid(userDTO.valid());return user;}).collect(Collectors.toList()));return result;}

service：

ActivityDetailDTO getActivityDetail(Long activityId);@Overridepublic ActivityDetailDTO getActivityDetail(Long activityId) {if (activityId == null) {logger.warn("查询活动详细信息失败，activityId为空！");return null;}// 查询 redisActivityDetailDTO detailDTO = getActivityFromCache(activityId);if (detailDTO != null) {logger.info("查询活动详细信息成功！detailDTO={}",JacksonUtil.writeValueAsString(detailDTO));return detailDTO;}// 如果redis不存在，查表// 活动表ActivityDO aDO = activityMapper.selectById(activityId);// 活动奖品表List<ActivityPrizeDO> apDOList =  activityPrizeMapper.selectByActivityId(activityId);// 活动人员表List<ActivityUserDO> auDOList = activityUserMapper.selectByActivityId(activityId);// 奖品表: 先获取要查询的奖品idList<Long> prizeIds = apDOList.stream().map(ActivityPrizeDO::getPrizeId).collect(Collectors.toList());List<PrizeDO> pDOList = prizeMapper.batchSelectByIds(prizeIds);// 整合活动详细信息，存放redisdetailDTO = convertToActivityDetailDTO(aDO, auDOList, pDOList, apDOList);cacheActivity(detailDTO);// 返回return detailDTO;}

dao：

@Select("select * from activity_prize where activity_id = #{activityId}")List<ActivityPrizeDO> selectByActivityId(@Param("activityId") Long activityId);@Select("select * from activity_user where activity_id = #{activityId}")List<ActivityUserDO> selectByActivityId(@Param("activityId") Long activityId);

postman进行测试：

返回结果如下：

{"code": 200,"data": {"activityId": 26,"activityName": "测试抽奖活动2.0","description": "测试抽奖活动2.0","valid": true,"prizes": [{"prizeId": 23,"name": "snh48演唱会门票","imageUrl": "bc10a8f2-eb31-4e1e-8a72-2883b3968f0c.jpg","price": 498.00,"description": "演唱会门票","prizeTierName": "一等奖","prizeAmount": 1,"valid": true},{"prizeId": 21,"name": "奥迪a6","imageUrl": "a1452970-b709-4a51-8343-e969f5ac5c64.jpg","price": 260000.00,"description": "一个四轮车子","prizeTierName": "二等奖","prizeAmount": 1,"valid": true}],"users": [{"userId": 44,"userName": "王奕","valid": true},{"userId": 45,"userName": "周诗雨","valid": true}]},"msg": ""
}

9.3 抽奖接口分析

        抽奖场景：当确定中奖人员信息之后，处于用户体验，需要当前页面马上显示出相关的人员信息，但是前端将相关中奖人确定的信息传入到后端之后，后端要进行（保存中奖信息，扭转对协应的转态，完成通知），之后才会将先关数据发送到前端显示的页面上，这样会极大地消耗时间，这就是同步接口，该接口完全不符合当前的抽奖接口。

        异步接口：

        前端：确定中间人之后前往后端。

        后端：前端来请求之后直接返回数据，对上面三个步骤进行异步处理。

        异步处理流程，会另找时间完成后端所要完成的三个步骤。 

9.3.1 异步处理业务流程图

9.3.2 业务逻辑分析

1、抽奖请求处理（重要）

         随机抽取：前端随机选择后端提供的参与者，确保每次抽取的结果是公平的。

        请求提交：在活动进⾏时，管理员可发起抽奖请求。请求包含活动ID、奖品ID和中奖⼈员等附加 信息。

         消息队列通知：有效的抽奖请求被发送⾄MQ队列中，等待MQ消费者真正处理抽奖逻辑。

         请求返回：抽奖的请求处理接⼝将不再完成任何的事情，直接返回。

2、 抽奖结果公布

        前端展⽰：中奖名单通过前端随机抽取的⼈员，公布展⽰出来。 

3、 抽奖逻辑执⾏（重要）

         消 息消费：MQ消费者收到异步消息，系统开始执⾏以下抽奖逻辑。

4、 中奖结果处理（重要）

        请求验证：

                 ◦ 系统验证抽奖请求的有效性，如是否满⾜系统根据设定的规则（如奖品数量、每⼈中奖次数 限制等）等；

                ◦ 幂等性：若消息多发，已抽取的内容不能再次抽取

        状态扭转：根据中奖结果扭转活动/奖品/参与者状态，如奖品是否已被抽取,⼈员是否已中奖等。

        结果记录：中奖结果被记录在数据库中，并同步更新Redis缓存。

5、 中奖者通知

         通知中奖者：通知中奖者和其他相关系统（如邮件发送服务）。

        奖品领取：中奖者根据通知中的指引领取奖品。

6、 抽奖异常处理

         回滚处理：当抽奖过程中发⽣异常，需要保证事务⼀致性。

        补救措施：抽奖⾏为是⼀次性的，因此异步处理抽奖任务必须保证成功，若过程异常，需采取补 救措施

        技术实现细节：

        异步处理：提⾼抽奖性能，不影响抽奖流程，将抽奖处理放⼊队列中进⾏异步处理，且保证了幂 等性。

        活动状态扭转处理：状态扭转会涉及活动及奖品等多横向维度扭转，不能避免未来不会有其他内 容牵扯进活动中，因此对于状态扭转处理，需要⾼扩展性（设计模式）与维护性。         并发处理：中奖者通知，可能要通知多系统（邮箱和手机两种方式），但相互解耦，可以设计为并发处理，加快抽奖效率 作⽤。

         事务处理：在抽奖逻辑执⾏时，如若发⽣异常，需要确保数据库表原⼦性、事务⼀致性，因此要 做好事务处理。

        本次的异步处理操作使用rabbitmq工具来实现。

9.4  mq

        MQ( Message queue ),从字⾯意思上看,本质是个队列,FIFO先⼊先出，只不过队列中存放的内容 是消息(message)⽽已.消息可以⾮常简单,⽐如只包含⽂本字符串,JSON等,也可以很复杂,⽐如内嵌对象. MQ多⽤于分布式系统之间进⾏通信，系统之间的调⽤通常有两种⽅式:

        1. 同步通信

        直接调⽤对⽅的服务,数据从⼀端发出后⽴即就可以达到另⼀端.

        2. 异步通信

        数据从⼀端发出后，先进⼊⼀个容器进⾏临时存储，当达到某种条件后，再由这个容器发送给另⼀端. 容器的⼀个具体实现就是MQ( message queue）

        RabbitMQ 就是MQ的⼀种实现

9.4.1 MQ主要作用        

        MQ主要⼯作是接收并转发消息,在不同的应⽤场景下可以展现不同的作⽤：

        1. 异步解耦:

        在业务流程中,⼀些操作可能⾮常耗时,但并不需要即时返回结果.可以借助MQ把这些操 作异步化,⽐如⽤⼾注册后发送注册短信或邮件通知,可以作为异步任务处理,⽽不必等待这些操作 完成后才告知⽤⼾注册成功.

        2. 流量削峰:

        在访问量剧增的情况下,应⽤仍然需要继续发挥作⽤,但是是这样的突发流量并不常⻅.如 果以能处理这类峰值为标准⽽投⼊资源,⽆疑是巨⼤的浪费.使⽤MQ能够使关键组件⽀撑突发访问压 ⼒,不会因为突发流量⽽崩溃.⽐如秒杀或者促销活动,可以使⽤MQ来控制流量,将请求排队,然后系 统根据⾃⼰的处理能⼒逐步处理这些请求.

        3. 异步通信:

        在很多时候应⽤不需要⽴即处理消息,MQ提供了异步处理机制,允许应⽤把⼀些消息放⼊ MQ中,但并不⽴即处理它,在需要的时候再慢慢处理.

        4. 消息分发:

        当多个系统需要对同⼀数据做出响应时,可以使⽤MQ进⾏消息分发.⽐如⽀付成功后,⽀ 付系统可以向MQ发送消息,其他系统订阅该消息,⽽⽆需轮询数据库.

        5. 延迟通知:

        在需要在特定时间后发送通知的场景中,可以使⽤MQ的延迟消息功能,⽐如在电⼦商务平 台中，如果⽤⼾下单后⼀定时间内未⽀付，可以使⽤延迟队列在超时后⾃动取消订单

9.4.2 rabbitmq核心概念

       如下图所示，生产者和消费者是通过网络进行连接的，网络之中是有信道的，发送的消息是存放在队列中遵循先进先出的规则，交换机的作用是用来路由消息的，消息由生产者发送到网络中，由交换机经过路由将消息传递给队列（交换机绑定的队列）。

        消费者消费消息，就是去相应对的队列里面进行拿取相应的消息。

        多个消费者可以订阅同一个队列。

9.4.3 . web界⾯操作

RabbitMQ Management访问

RabbitMQ 介绍.pdf 基本步骤见文件

9.4.4 rabbitmq的配置与使用

1、引入依赖：

<!-- RabbitMQ --><dependency><groupId>org.springframework.boot</groupId><artifactId>spring-boot-starter-amqp</artifactId></dependency>

2、application.properties 配置 MQ

## mq ##
spring.rabbitmq.host=49
spring.rabbitmq.port=5672
spring.rabbitmq.username=admin
spring.rabbitmq.password=111111
#消息确认机制，默认auto
spring.rabbitmq.listener.simple.acknowledge-mode=auto
#设置失败重试 5次
spring.rabbitmq.listener.simple.retry.enabled=true
spring.rabbitmq.listener.simple.retry.max-attempts=5

3、DirectRabbitConfig 配置类

@Configuration
public class DirectRabbitConfig {public static final String QUEUE_NAME = "DirectQueue";public static final String EXCHANGE_NAME = "DirectExchange";public static final String ROUTING = "DirectRouting";public static final String DLX_QUEUE_NAME = "DlxDirectQueue";public static final String DLX_EXCHANGE_NAME = "DlxDirectExchange";public static final String DLX_ROUTING = "DlxDirectRouting";/*** 队列 起名：DirectQueue** @return*/@Beanpublic Queue directQueue() {// durable:是否持久化,默认是false,持久化队列：会被存储在磁盘上，当消息代理重启时仍然存在，暂存队列：当前连接有效// exclusive:默认也是false，只能被当前创建的连接使用，而且当连接关闭后队列即被删除。此参考优先级高于durable// autoDelete:是否自动删除，当没有生产者或者消费者使用此队列，该队列会自动删除。//   return new Queue("DirectQueue",true,true,false);// 一般设置一下队列的持久化就好,其余两个就是默认falsereturn new Queue(QUEUE_NAME,true);// 普通队列绑定死信交换机
//        return QueueBuilder.durable(QUEUE_NAME)
//                .deadLetterExchange(DLX_EXCHANGE_NAME)
//                .deadLetterRoutingKey(DLX_ROUTING).build();}/*** Direct交换机 起名：DirectExchange** @return*/@BeanDirectExchange directExchange() {return new DirectExchange(EXCHANGE_NAME,true,false);}/*** 绑定  将队列和交换机绑定, 并设置用于匹配键：DirectRouting** @return*/@BeanBinding bindingDirect() {return BindingBuilder.bind(directQueue()).to(directExchange()).with(ROUTING);}/*** 死信队列** @return*/@Beanpublic Queue dlxQueue() {// durable:是否持久化,默认是false,持久化队列：会被存储在磁盘上，当消息代理重启时仍然存在，暂存队列：当前连接有效// exclusive:默认也是false，只能被当前创建的连接使用，而且当连接关闭后队列即被删除。此参考优先级高于durable// autoDelete:是否自动删除，当没有生产者或者消费者使用此队列，该队列会自动删除。//   return new Queue("DirectQueue",true,true,false);// 一般设置一下队列的持久化就好,其余两个就是默认falsereturn new Queue(DLX_QUEUE_NAME,true);}/*** 死信交换机** @return*/@BeanDirectExchange dlxExchange() {return new DirectExchange(DLX_EXCHANGE_NAME,true,false);}/*** 绑定死信队列与交换机** @return*/@BeanBinding bindingDlx() {return BindingBuilder.bind(dlxQueue()).to(dlxExchange()).with(DLX_ROUTING);}@Beanpublic MessageConverter jsonMessageConverter(){return new Jackson2JsonMessageConverter();}
}

在当前生产消费的模块中，生产者是前端的抽奖接口，消费者是处理抽奖流程的方法。