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);

@Override
    public ActivityDetailDTO getActivityDetail(Long activityId) {
        if (activityId == null) {
            logger.warn("查询活动详细信息失败，activityId为空！");
            return null;
        }
        // 查询 redis
        ActivityDetailDTO 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);

        // 奖品表: 先获取要查询的奖品id
        List<Long> prizeIds = apDOList.stream()
                .map(ActivityPrizeDO::getPrizeId)
                .collect(Collectors.toList());
        List<PrizeDO> pDOList = prizeMapper.batchSelectByIds(prizeIds);
        // 整合活动详细信息，存放redis
        detailDTO = 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
     */
    @Bean
    public Queue directQueue() {
        // durable:是否持久化,默认是false,持久化队列：会被存储在磁盘上，当消息代理重启时仍然存在，暂存队列：当前连接有效
        // exclusive:默认也是false，只能被当前创建的连接使用，而且当连接关闭后队列即被删除。此参考优先级高于durable
        // autoDelete:是否自动删除，当没有生产者或者消费者使用此队列，该队列会自动删除。
        //   return new Queue("DirectQueue",true,true,false);

        // 一般设置一下队列的持久化就好,其余两个就是默认false
         return new Queue(QUEUE_NAME,true);

        // 普通队列绑定死信交换机
//        return QueueBuilder.durable(QUEUE_NAME)
//                .deadLetterExchange(DLX_EXCHANGE_NAME)
//                .deadLetterRoutingKey(DLX_ROUTING).build();
    }

    /**
     * Direct交换机 起名：DirectExchange
     *
     * @return
     */
    @Bean
    DirectExchange directExchange() {
        return new DirectExchange(EXCHANGE_NAME,true,false);
    }

    /**
     * 绑定  将队列和交换机绑定, 并设置用于匹配键：DirectRouting
     *
     * @return
     */
    @Bean
    Binding bindingDirect() {
        return BindingBuilder.bind(directQueue())
                .to(directExchange())
                .with(ROUTING);
    }

    /**
     * 死信队列
     *
     * @return
     */
    @Bean
    public Queue dlxQueue() {
        // durable:是否持久化,默认是false,持久化队列：会被存储在磁盘上，当消息代理重启时仍然存在，暂存队列：当前连接有效
        // exclusive:默认也是false，只能被当前创建的连接使用，而且当连接关闭后队列即被删除。此参考优先级高于durable
        // autoDelete:是否自动删除，当没有生产者或者消费者使用此队列，该队列会自动删除。
        //   return new Queue("DirectQueue",true,true,false);

        // 一般设置一下队列的持久化就好,其余两个就是默认false
        return new Queue(DLX_QUEUE_NAME,true);
    }

    /**
     * 死信交换机
     *
     * @return
     */
    @Bean
    DirectExchange dlxExchange() {
        return new DirectExchange(DLX_EXCHANGE_NAME,true,false);
    }

    /**
     * 绑定死信队列与交换机
     *
     * @return
     */
    @Bean
    Binding bindingDlx() {
        return BindingBuilder.bind(dlxQueue())
                .to(dlxExchange())
                .with(DLX_ROUTING);
    }



    @Bean
    public MessageConverter jsonMessageConverter(){
        return new Jackson2JsonMessageConverter();
    }
}

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