大麦项目-用户下单压测结果

业务讲解-如何保障节目数据在缓存与数据库间的一致性

业务讲解-如何应对高并发下的购票压力 https://www.yuque.com/u22210564/ykdrdh/schg4ewp7pupbb88 业务讲解-如何对锁进行优化更好的缓解购票压力 https://www.yuque.com/u22210564/ykdrdh/fs2pbqaxyekxg9y3 业务讲解-解决高并发下购票压力的终极杀招 "无锁化!" https://www.yuque.com/u22210564/ykdrdh/zyr9pd9ogzqyas2z

这三篇文章讲解了用户购票时从分布式锁到lua的优化整个过程，总体都是围绕着用户购票生成订单的业务

业务简介

针对购票流程，大麦网项目进行使用了各种技巧来提高效率，包括幂等性、本地锁、分布式锁、redis、lua、限流算法等。 ![[Pasted image 20251230230534.png]]

幂等性保护

在此业务中为什么要做幂等性的保护，其实就是为了防止用户多次提交，前端的解决办法是将按钮置灰，但这种不靠谱。如果前端没有控制住、网络延迟、或者有人刷号直接调用接口来多次请求就会出现问题了，所以说后端也要做好幂等保护

为什么有分布式锁了还要加幂等组件？

可能小伙伴会有这样的疑惑，直接使用分布式锁不就行了，为什么还要额外设计出幂等组件？首先直接使用分布式锁是可以实现幂等的，当然业务逻辑验证也要做验证，但其实分布式锁会浪费一些性能

分布式锁的特点是多个请求并发执行，这些请求是来自不同的用户，也就是这些请求虽然要依次等待锁执行，但最终还是要把这些请求都执行完的(执行时间太长超时的异常情况排除)，总结起来就是都要获得锁，没有获得锁的请求，也要争取获得锁接着执行

幂等的特点也是多个请求并发执行，但这些请求是来自同一个用户，也就是说这些请求只要保证第一个请求能执行，其余的请求要直接拒绝掉，总结起来就是只有第一个请求获得锁执行就可以，其余的请求看到已经上了锁，那么就要直接结束掉

这个也是我在面试别人时，经常会问的问题，知道这个特点后，才真正能掌握为什么需要幂等

关于幂等性的详细介绍以及幂等组件的使用和设计，可跳转到相应的文档

https://www.yuque.com/u22210564/ykdrdh/ro5vey3tmlgzdw0p

分布式锁

分布式锁使用节目id作为锁，关于分布式锁组件的使用和详细的设计可跳转到相应的文档

组合模式的业务验证

com.damai.service.ProgramOrderService#create

//进行业务验证
compositeContainer.execute(CompositeCheckType.PROGRAM_ORDER_CREATE_CHECK.getValue(),programOrderCreateDto);

此组环是使用了组合模式和树形结构来将业务的验证逻辑进行复用并且串联起来按照树形结构执行

用户购票验证逻辑的类型为program_order_create_check，验证的逻辑有

• 验证座位参数
• 将节目缓存
• 验证缓存是否存在节目数据
• 验证用户是否存在

关于此业务验证的详细介绍，可跳转到相关文档查看

https://www.yuque.com/u22210564/ykdrdh/cee3nk1as89bt8pc

业务逻辑

在向Redis中存放的余票数据的key是 d_mai_program_ticket_remain_number_resolution_节目id_票档id

在向Redis中存放的座位数据的key是:

• d_mai_program_seat_no_sold_resolution_hash_节目id_票档id
• d_mai_program_seat_lock_resolution_hash_节目id_票档id
• d_mai_program_seat_sold_resolution_hash_节目id_票档id

在设计缓存结构的时候key命名除了节目id还有票档id

为什么缓存key命名除了节目id要额外加个票档id?

试想一下key如果只有节目id的话，那么此节目的座位数据都放到一个hash中。如果大型演唱会1w个座位的话，那么每次验证座位和更新状态都要取出这1w个座位，这对项目的压力其实不小的

所以要在节目id的基础上再加个票档id，这样每个hash存的就是节目id+票档id下的座位了，如果1w个座位有5个票档的话，那么每个hash就可需要存储2000个座位了

还有一点，如果两个用户选择不同的票档，比如第一个用户选择一等票，第二个用户选择二等票，如果在redis集群环境下，进行修改座位状态时，一等票和二等票不再同一个redis集群分片的情况下，那么这两个用户还可以实现并发执行，进一步提供了吞吐量！

获取节目演出时间、查询票档类型、

验证座位参数、验证用户存在性等。

更新缓存余票数量和修改座位状态

com.damai.service.ProgramOrderService#updateProgramCacheDataResolution

private void updateProgramCacheDataResolution(Long programId,List<SeatVo> seatVoList,OrderStatus orderStatus){
    //如果要操作的订单状态不是未支付和取消，那么直接拒绝
    if (!(Objects.equals(orderStatus.getCode(), OrderStatus.NO_PAY.getCode()) ||
            Objects.equals(orderStatus.getCode(), OrderStatus.CANCEL.getCode()))) {
        throw new DaMaiFrameException(BaseCode.OPERATE_ORDER_STATUS_NOT_PERMIT);
    }
    List<String> keys = new ArrayList<>();
    //这里key只是占位，并不起实际作用
    keys.add("#");
    
    String[] data = new String[3];
    Map<Long, Long> ticketCategoryCountMap =
            seatVoList.stream().collect(Collectors.groupingBy(SeatVo::getTicketCategoryId, Collectors.counting()));
    //更新票档数据集合
    JSONArray jsonArray = new JSONArray();
    ticketCategoryCountMap.forEach((k,v) -> {
        //这里是计算更新票档数据
        JSONObject jsonObject = new JSONObject();
        //票档数量的key
        jsonObject.put("programTicketRemainNumberHashKey",RedisKeyBuild.createRedisKey(
                RedisKeyManage.PROGRAM_TICKET_REMAIN_NUMBER_HASH_RESOLUTION, programId, k).getRelKey());
        //票档id
        jsonObject.put("ticketCategoryId",String.valueOf(k));
        //如果是生成订单操作，则将扣减余票数量
        if (Objects.equals(orderStatus.getCode(), OrderStatus.NO_PAY.getCode())) {
            jsonObject.put("count","-" + v);
            //如果是取消订单操作，则将恢复余票数量
        } else if (Objects.equals(orderStatus.getCode(), OrderStatus.CANCEL.getCode())) {
            jsonObject.put("count",v);
        }
        jsonArray.add(jsonObject);
    });
    //座位map key:票档id  value:座位集合
    Map<Long, List<SeatVo>> seatVoMap = 
            seatVoList.stream().collect(Collectors.groupingBy(SeatVo::getTicketCategoryId));
    JSONArray delSeatIdjsonArray = new JSONArray();
    JSONArray addSeatDatajsonArray = new JSONArray();
    seatVoMap.forEach((k,v) -> {
        JSONObject delSeatIdjsonObject = new JSONObject();
        JSONObject seatDatajsonObject = new JSONObject();
        String seatHashKeyDel = "";
        String seatHashKeyAdd = "";
        //如果是生成订单操作，则将座位修改为锁定状态    
        if (Objects.equals(orderStatus.getCode(), OrderStatus.NO_PAY.getCode())) {
            //没有售卖座位的key
            seatHashKeyDel = (RedisKeyBuild.createRedisKey(RedisKeyManage.PROGRAM_SEAT_NO_SOLD_RESOLUTION_HASH, programId, k).getRelKey());
            //锁定座位的key
            seatHashKeyAdd = (RedisKeyBuild.createRedisKey(RedisKeyManage.PROGRAM_SEAT_LOCK_RESOLUTION_HASH, programId, k).getRelKey());
            for (SeatVo seatVo : v) {
                seatVo.setSellStatus(SellStatus.LOCK.getCode());
            }
            //如果是取消订单操作，则将座位修改为未售卖状态
        } else if (Objects.equals(orderStatus.getCode(), OrderStatus.CANCEL.getCode())) {
            //锁定座位的key
            seatHashKeyDel = (RedisKeyBuild.createRedisKey(RedisKeyManage.PROGRAM_SEAT_LOCK_RESOLUTION_HASH, programId, k).getRelKey());
            //没有售卖座位的key
            seatHashKeyAdd = (RedisKeyBuild.createRedisKey(RedisKeyManage.PROGRAM_SEAT_NO_SOLD_RESOLUTION_HASH, programId, k).getRelKey());
            for (SeatVo seatVo : v) {
                seatVo.setSellStatus(SellStatus.NO_SOLD.getCode());
            }
        }
        //要进行删除座位的key
        delSeatIdjsonObject.put("seatHashKeyDel",seatHashKeyDel);
        //如果是订单创建，那么就扣除未售卖的座位id
        //如果是订单取消，那么就扣除锁定的座位id
        delSeatIdjsonObject.put("seatIdList",v.stream().map(SeatVo::getId).map(String::valueOf).collect(Collectors.toList()));
        delSeatIdjsonArray.add(delSeatIdjsonObject);
        //要进行添加座位的key
        seatDatajsonObject.put("seatHashKeyAdd",seatHashKeyAdd);
        //如果是订单创建的操作，那么添加到锁定的座位数据
        //如果是订单订单的操作，那么添加到未售卖的座位数据
        List<String> seatDataList = new ArrayList<>();
        //循环座位
        for (SeatVo seatVo : v) {
            //选放入座位did
            seatDataList.add(String.valueOf(seatVo.getId()));
            //接着放入座位对象
            seatDataList.add(JSON.toJSONString(seatVo));
        }
        //要进行添加座位的数据
        seatDatajsonObject.put("seatDataList",seatDataList);
        addSeatDatajsonArray.add(seatDatajsonObject);
    });
    
    //票档相关数据
    data[0] = JSON.toJSONString(jsonArray);
    //要进行删除座位的key
    data[1] = JSON.toJSONString(delSeatIdjsonArray);
    //要进行添加座位的相关数据
    data[2] = JSON.toJSONString(addSeatDatajsonArray);
    //执行lua脚本
    programCacheResolutionOperate.programCacheOperate(keys,data);
}

这段代码是一个Java方法，名为updateProgramCacheDataResolution，它的作用是更新节目缓存数据，特别是在订单状态变更时（如未支付或取消订单）对座位信息和票档数据进行相应的更新。以下是该方法的详细逻辑解析：

方法签名

private void updateProgramCacheDataResolution(Long programId, List<SeatVo> seatVoList, OrderStatus orderStatus)

• programId：节目的ID。
• seatVoList：座位信息列表。
• orderStatus：订单状态。

代码逻辑

1. 检查订单状态：

• 如果订单状态不是“未支付”或“取消”，则抛出异常，拒绝操作。

2. 初始化变量：

• keys：用于存储占位符，实际不起作用。
• data：字符串数组，用于存储JSON数据，稍后用于执行Lua脚本。

3. 票档数据更新：

• 使用seatVoList中的座位信息，通过流式处理收集每个票档ID对应的座位数量。
• 遍历ticketCategoryCountMap，为每个票档创建一个JSON对象，包含票档的Redis key、票档ID和数量变化（根据订单状态，可能是扣减或恢复）。

4. 座位状态更新：

• 根据订单状态，将座位状态更新为“锁定”或“未售卖”。
• 为每个票档ID创建两个JSON对象：一个用于删除座位ID，另一个用于添加座位数据。
• 删除座位ID的JSON对象包含未售卖或锁定座位的Redis key和座位ID列表。
• 添加座位数据的JSON对象包含添加座位的Redis key和座位数据列表（座位ID和座位对象的JSON字符串）。

5. 数据组装：

• 将票档数据、删除座位ID的JSON数组和添加座位数据的JSON数组转换为JSON字符串，存储在data数组中。

6. 执行Lua脚本：

• 使用programCacheResolutionOperate对象执行Lua脚本，传入keys和data。

这个方法主要处理在订单状态变更时对节目缓存数据的更新，包括票档数据和座位状态的更新。通过Lua脚本执行，确保操作的原子性和一致性。代码中使用了流式处理来简化集合操作，并通过JSON对象来组织和传递数据。

此方法是负责生成订单和取消订单的两种操作，这两种操作都是操作余票数量和座位状态，操作正好是彼此相反的，所以可以直接将两种操作放在一起，实现共用

生成订单是要扣减余票数量，将座位状态从未售卖修改为锁定中

取消订单是要恢复余票数量，将座位状态从锁定中修改为未售卖

本文是介绍用户购票的流程，所以只分析生成订单的操作，此方法其实就是拼接要修改redis的键和值，拼接好后统一放到lua中执行，详细的流程已经在代码中做了注释，这里把拼接好的键和值梳理出来

请注意，下面列举的键是去掉了个人前缀(默认为 **damai**)的情况下，避免小伙伴会有下面列举的键名和自己启动项目中对不上的情况

data 数组结构 是存放要修改的数据

• 第一个元素 票档数量数据，是一个数组，数组的元素是json字符串，存放着票档缓存的key、票档id、要购票的数量

programTicketRemainNumberHashKey	ticketCategoryId	count
damai-d_mai_program_ticket_remain_number_hash_resolution_1_2	2	-1

• 第二个元素 进行删除座位的key，是一个数组，数组的元素是json字符串，存放着要删除座位的hash的key、座位id集合

seatHashKeyDel	seatIdList
damai-d_mai_program_seat_no_sold_resolution_hash_1_2	1

• 第三个元素 要购买的座位数据，是一个数组，数组的元素是String的json字符串，存放着座位对象集合、要添加座位的hash的key

座位对象集合：这个数组比较特殊，不是同一个元素，而是一个座位id，一个对应的座位对象，再一个座位id，一个对应的座位对象 ...

seatDataList	seatHashKeyAdd
["1","{"colCode":1,"id":1,"price":180,"programId":1,"rowCode":1,"seatType":1,"seatTypeName":"通用座位","sellStatus":2,"ticketCategoryId":2}"]	damai-d_mai_program_seat_lock_resolution_hash_1_2

data 真实结构json形式展示

[
    "[{\"programTicketRemainNumberHashKey\":\"damai-d_mai_program_ticket_remain_number_hash_resolution_1_2\",\"ticketCategoryId\":\"2\",\"count\":\"-1\"}]",
    "[{\"seatHashKeyDel\":\"damai-d_mai_program_seat_no_sold_resolution_hash_1_2\",\"seatIdList\":[\"1\"]}]",
    "[{\"seatDataList\":[\"1\",\"{\\\"colCode\\\":1,\\\"id\\\":1,\\\"price\\\":180,\\\"programId\\\":1,\\\"rowCode\\\":1,\\\"seatType\\\":1,\\\"seatTypeName\\\":\\\"通用座位\\\",\\\"sellStatus\\\":2,\\\"ticketCategoryId\\\":2}\"],\"seatHashKeyAdd\":\"damai-d_mai_program_seat_lock_resolution_hash_1_2\"}]"
]

介绍一下这些数据在redis中的真正存储：

• d_mai_program_ticket_remain_number_hash_resolution_节目id_票档id 节目下的票档余票数量  值的存储结构为hash，hash的key为票档id，hash的value为票档数量

key	value
1	0
2	60

• d_mai_program_seat_no_sold_resolution_hash_节目id_票档id 节目下没有售卖的座位集合 值的存储结构为hash，hash的key为座位id，hash的value为座位对象

key	value
1
2
...	....

• d_mai_program_seat_lock_resolution_hash_节目id_票档id 节目下锁定的座位集合 值的存储结构为hash，hash的key为座位id，hash的value为座位对象

key	value
10
17
...	....

把这些键和数据拼接好后，就是在lua中执行了

lua脚本执行

脚本位置： resources/lua/programDataResolution.lua

-- 票档数量数据
local ticket_category_list = cjson.decode(ARGV[1])
-- 如果是订单创建，那么就扣除未售卖的座位id
-- 如果是订单取消，那么就扣除锁定的座位id
local del_seat_list = cjson.decode(ARGV[2])
-- 如果是订单创建的操作，那么添加到锁定的座位数据
-- 如果是订单订单的操作，那么添加到未售卖的座位数据
local add_seat_data_list = cjson.decode(ARGV[3])

-- 如果是订单创建，则扣票档数量
-- 如果是订单取消，则恢复票档数量
for index,increase_data in ipairs(ticket_category_list) do
    -- 票档数量的key
    local program_ticket_remain_number_hash_key = increase_data.programTicketRemainNumberHashKey
    -- 票档id
    local ticket_category_id = increase_data.ticketCategoryId
    -- 扣除的数量
    local increase_count = increase_data.count
    redis.call('HINCRBY',program_ticket_remain_number_hash_key,ticket_category_id,increase_count)
end
-- 如果是订单创建,将没有售卖的座位删除，再将座位数据添加到锁定的座位中
-- 如果是订单取消,将锁定的座位删除，再将座位数据添加到没有售卖的座位中
for index, seat in pairs(del_seat_list) do
    -- 要去除的座位对应的hash的键
    local seat_hash_key_del = seat.seatHashKeyDel
    -- 座位id集合
    local seat_id_list = seat.seatIdList
    redis.call('HDEL',seat_hash_key_del,unpack(seat_id_list))
end
for index, seat in pairs(add_seat_data_list) do
    -- 要添加的座位对应的hash的键
    local seat_hash_key_add = seat.seatHashKeyAdd
    -- 作为数据
    local seat_data_list = seat.seatDataList
    redis.call('HMSET',seat_hash_key_add,unpack(seat_data_list))
end

lua中的执行逻辑也是执行订单生成和订单取消两种操作，这里依旧只分析订单生成的流程

KEYS的数据就是传入的keys，ARGV的数据就是传入的data

如果是订单生成的流程，那么此时的键具体为

• program_ticket_remain_number_hash_key 实际为 d_mai_program_ticket_remain_number_hash_resolution_1_2
• seat_hash_key_del 实际为 d_mai_program_seat_no_sold_resolution_hash_1_2
• seat_hash_key_add 实际为 d_mai_program_seat_lock_resolution_hash_1_2

执行流程是先把对应的票档的余票数量进行扣减，然后从没有售卖的座位集合中删除掉要购买的座位，接着再将要购买的座位添加到锁定的座位集合中

执行到这里，是将余票也扣除了，座位也修改为锁定了，接下来就是组装订单数据调用订单服务创建订单的流程了

组装订单数据

com.damai.service.ProgramOrderService#doCreate

private String doCreate(ProgramOrderCreateDto programOrderCreateDto,List<SeatVo> purchaseSeatList){
    //节目id
    Long programId = programOrderCreateDto.getProgramId();
    //获取要购买的节目信息
    ProgramVo programVo = redisCache.get(RedisKeyBuild.createRedisKey(RedisKeyManage.PROGRAM, programId), ProgramVo.class);
    //查询节目演出时间
    ProgramShowTime programShowTime = redisCache.get(RedisKeyBuild.createRedisKey(RedisKeyManage.PROGRAM_SHOW_TIME
            ,programId),ProgramShowTime.class);
    //主订单参数构建
    OrderCreateDto orderCreateDto = new OrderCreateDto();
    //生成订单编号
    orderCreateDto.setOrderNumber(uidGenerator.getOrderNumber(programOrderCreateDto.getUserId(),ORDER_TABLE_COUNT));
    orderCreateDto.setProgramId(programOrderCreateDto.getProgramId());
    orderCreateDto.setProgramItemPicture(programVo.getItemPicture());
    orderCreateDto.setUserId(programOrderCreateDto.getUserId());
    orderCreateDto.setProgramTitle(programVo.getTitle());
    orderCreateDto.setProgramPlace(programVo.getPlace());
    orderCreateDto.setProgramShowTime(programShowTime.getShowTime());
    orderCreateDto.setProgramPermitChooseSeat(programVo.getPermitChooseSeat());
    BigDecimal databaseOrderPrice = 
            purchaseSeatList.stream().map(SeatVo::getPrice).reduce(BigDecimal.ZERO, BigDecimal::add);
    orderCreateDto.setOrderPrice(databaseOrderPrice);
    orderCreateDto.setCreateOrderTime(DateUtils.now());

    //购票人订单构建
    List<Long> ticketUserIdList = programOrderCreateDto.getTicketUserIdList();
    List<OrderTicketUserCreateDto> orderTicketUserCreateDtoList = new ArrayList<>();
    for (int i = 0; i < ticketUserIdList.size(); i++) {
        Long ticketUserId = ticketUserIdList.get(i);
        OrderTicketUserCreateDto orderTicketUserCreateDto = new OrderTicketUserCreateDto();
        orderTicketUserCreateDto.setOrderNumber(orderCreateDto.getOrderNumber());
        orderTicketUserCreateDto.setProgramId(programOrderCreateDto.getProgramId());
        orderTicketUserCreateDto.setUserId(programOrderCreateDto.getUserId());
        orderTicketUserCreateDto.setTicketUserId(ticketUserId);
        //给购票人绑定座位
        SeatVo seatVo = 
                Optional.ofNullable(purchaseSeatList.get(i))
                        .orElseThrow(() -> new DaMaiFrameException(BaseCode.SEAT_NOT_EXIST));
        orderTicketUserCreateDto.setSeatId(seatVo.getId());
        orderTicketUserCreateDto.setSeatInfo(seatVo.getRowCode()+"排"+seatVo.getColCode()+"列");
        orderTicketUserCreateDto.setTicketCategoryId(seatVo.getTicketCategoryId());
        orderTicketUserCreateDto.setOrderPrice(seatVo.getPrice());
        orderTicketUserCreateDto.setCreateOrderTime(DateUtils.now());
        orderTicketUserCreateDtoList.add(orderTicketUserCreateDto);
    }

    orderCreateDto.setOrderTicketUserCreateDtoList(orderTicketUserCreateDtoList);

    String orderNumber;
    ApiResponse<String> createOrderResponse = orderClient.create(orderCreateDto);
    if (Objects.equals(createOrderResponse.getCode(), BaseCode.SUCCESS.getCode())) {
        orderNumber = createOrderResponse.getData();
    }else {
        //订单创建失败将操作缓存中的数据还原
        updateProgramCacheDataResolution(programId,purchaseSeatList,OrderStatus.CANCEL);
        log.error("创建订单失败 需人工处理 orderCreateDto : {}",JSON.toJSONString(orderCreateDto));
        throw new DaMaiFrameException(createOrderResponse);
    }

    //延迟队列创建
    DelayOrderCancelDto delayOrderCancelDto = new DelayOrderCancelDto();
    delayOrderCancelDto.setOrderNumber(orderCreateDto.getOrderNumber());
    delayOrderCancelSend.sendMessage(JSON.toJSONString(delayOrderCancelDto));

    return orderNumber;
}

这里的逻辑并不复杂，先查询节目信息，然后组装主订单和购票人订单需要的数据，在组装订单人的数据过程中，将座位依次绑定到购票人上

重点要关注的就是订单编号的创建：

//生成订单编号
orderCreateDto.setOrderNumber(uidGenerator.getOrderNumber(programOrderCreateDto.getUserId(),ORDER_TABLE_COUNT));

订单表的分库分表时，采用的分片键是订单编号，而涉及到订单查询的业务有，通过订单编号查询订单详情，以及通过用户id来查询该用户下的订单列表。这是就有问题了啊，用户id不是分片键了，这不就有了读扩散的问题了吗？

解决此问题的方式可以通过再设计个订单用户表，先去用户表查询订单编号，然后再去订单编号查询订单列表，但这么做要额外再设计个表出来维护。所以最终并没有采用这种额外设计附属表的方案。

而是采用了基因法，将雪花算法和用户id融合在一起生成新的订单编号 ，通过这种方法，用订单编号对分库和分表取模的结果 和 用户id对分库和分表的取模的结果是相同的，相当于订单编号和用户id都是分片键了，解决了读扩散的问题，又不用再额外维护订单用户表

订单服务

流程图

控制层入口

com.damai.controller.OrderController#create

@ApiOperation(value = "订单创建(不提供给前端调用，只允许内部program服务调用)")
@PostMapping(value = "/create")
public ApiResponse<String> create(@Valid @RequestBody OrderCreateDto orderCreateDto) {
    return ApiResponse.ok(orderService.create(orderCreateDto));
}

service层

com.damai.service.OrderService#create

@Transactional(rollbackFor = Exception.class)
public String create(OrderCreateDto orderCreateDto) {
    LambdaQueryWrapper<Order> orderLambdaQueryWrapper = 
            Wrappers.lambdaQuery(Order.class).eq(Order::getOrderNumber, orderCreateDto.getOrderNumber());
    //如果订单存在了，那么直接拒绝
    Order oldOrder = orderMapper.selectOne(orderLambdaQueryWrapper);
    if (Objects.nonNull(oldOrder)) {
        throw new DaMaiFrameException(BaseCode.ORDER_EXIST);
    }
    Order order = new Order();
    BeanUtil.copyProperties(orderCreateDto,order);
    order.setDistributionMode("电子票");
    order.setTakeTicketMode("请使用购票人身份证直接入场");
    //转化订单对象
    List<OrderTicketUser> orderTicketUserList = new ArrayList<>();
    for (OrderTicketUserCreateDto orderTicketUserCreateDto : orderCreateDto.getOrderTicketUserCreateDtoList()) {
        OrderTicketUser orderTicketUser = new OrderTicketUser();
        BeanUtil.copyProperties(orderTicketUserCreateDto,orderTicketUser);
        orderTicketUser.setId(uidGenerator.getUid());
        orderTicketUserList.add(orderTicketUser);
    }
    //插入主订单
    orderMapper.insert(order);
    //插入购票人订单
    orderTicketUserService.saveBatch(orderTicketUserList);
    //记录用户下此节目的订单数量操作
    redisCache.incrBy(RedisKeyBuild.createRedisKey(
                RedisKeyManage.ACCOUNT_ORDER_COUNT,
                        orderCreateDto.getUserId(),
                        orderCreateDto.getProgramId()),
                orderCreateDto.getOrderTicketUserCreateDtoList().size());
    return String.valueOf(order.getOrderNumber());
}

• 看流程图就能理解了，流程很简单，先是验证订单是否存在，如果不存在，那么就生成主订单和购票人订单
• 成功生成订单后，将用户下此节目的订单数量加1操作

以上流程就是将订单创建完毕，但对于异常的情况：（用户选择座位，生成订单后才能进行支付）

• 调用订单服务失败后，将相应的余票数量和座位状态进行回滚
• 调用订单服务成功后，接着要发送订单延迟关闭消息放入延迟队列中，当达到消息的消费时间后，订单仍然没有支付，那么就将此订单取消掉

订单生成失败后如何快速回滚数据https://www.yuque.com/u22210564/ykdrdh/zuuu0ggcadzwgw0w

取消订单和延迟订单关闭后如何正确处理数据https://www.yuque.com/u22210564/ykdrdh/dfvtmyqgfz8z6nie

支付

支付宝处理支付后，回调接口的流程。这里把支付宝回调的流程图再贴出来

在整个流程中：

• 用户购票生成订单过程 把缓存中的余票数量扣除了，缓存中的座位从未售卖修改为锁定中
• 支付回调过程把缓存中的座位从锁定中修改为已售卖

之所以把这些数据存到缓存中，是因为缓存的效率执行起来比数据库要快的多，但有没有注意到，从始至终都是操作的缓存，到现在都没有关于数据库的余票数量和座位的操作啊

到这里就明确了，其实当支付回调执行把订单状态和缓存的数据都成功执行后，发送更新节目和座位的数据消息到延迟队列中，由节目服务来消费消息进行数据库中的更新，有小伙伴可能会想了，这使用延迟队列，缓存和数据库不就不能保证一致性了吗？这里先卖个关子，先继续介绍，下文中会有答案

我们再去节目服务查看，是如何消费消息的

节目服务消费消息更新数据库

消息监听器

com.damai.service.delayconsumer.DelayOperateProgramDataConsumer

@Slf4j
@Component
public class DelayOperateProgramDataConsumer implements ConsumerTask {
    
    @Autowired
    private ProgramService programService;
    
    @Override
    public void execute(String content) {
        log.info("延迟操作节目数据消息进行消费 content : {}", content);
        if (StringUtil.isEmpty(content)) {
            log.error("延迟队列消息不存在");
            return;
        }
        ProgramOperateDataDto programOperateDataDto = JSON.parseObject(content, ProgramOperateDataDto.class);
        programService.operateProgramData(programOperateDataDto);
    }
    
    @Override
    public String topic() {
        return SpringUtil.getPrefixDistinctionName() + "-" + DELAY_OPERATE_PROGRAM_DATA_TOPIC;
    }
}

com.damai.service.ProgramService#operateProgramData

这里在执行前通过节目id+座位id集合来验证是否幂等。 里面的流程比较简单，先验证状态，然后更新座位状态，再更新票档数量。这里的票档数量是使用的自定义sql来更新 这里都用上了 节目id和座位id，因为座位表是使用 节目id 作为分片键的，任何操作都要带有分片键，否则会发生读扩散的问题！

@RepeatExecuteLimit(name = CANCEL_PROGRAM_ORDER,keys = {"#programOperateDataDto.programId","#programOperateDataDto.seatIdList"})
@Transactional(rollbackFor = Exception.class)
public void operateProgramData(ProgramOperateDataDto programOperateDataDto){
    List<TicketCategoryCountDto> ticketCategoryCountDtoList = programOperateDataDto.getTicketCategoryCountDtoList();
    //从库中查询座位集合
    List<Long> seatIdList = programOperateDataDto.getSeatIdList();
    //根据节目id和座位id查询座位集合	
    LambdaQueryWrapper<Seat> seatLambdaQueryWrapper = 
                Wrappers.lambdaQuery(Seat.class)
                        .eq(Seat::getProgramId,programOperateDataDto.getProgramId())
                        .in(Seat::getId, seatIdList);
    List<Seat> seatList = seatMapper.selectList(seatLambdaQueryWrapper);
    //如果库中的座位集合为空，则抛出异常
    if (CollectionUtil.isEmpty(seatList)) {
            throw new DaMaiFrameException(BaseCode.SEAT_NOT_EXIST);
    }
    //如果库中的座位集合数量和传入的座位数量不相同，则抛出异常
    if (seatList.size() != seatIdList.size()) {
        throw new DaMaiFrameException(BaseCode.SEAT_UPDATE_REL_COUNT_NOT_EQUAL_PRESET_COUNT);
    }
    for (Seat seat : seatList) {
        //如果库中的座位有一个已经是已售卖的状态，则抛出异常
        if (Objects.equals(seat.getSellStatus(), SellStatus.SOLD.getCode())) {
            throw new DaMaiFrameException(BaseCode.SEAT_SOLD);
        }
    }
    //将库中的座位集合批量更新为售卖状态
    LambdaUpdateWrapper<Seat> seatLambdaUpdateWrapper = 
                Wrappers.lambdaUpdate(Seat.class)
                        .eq(Seat::getProgramId,programOperateDataDto.getProgramId())
                        .in(Seat::getId, seatIdList);
    Seat updateSeat = new Seat();
    updateSeat.setSellStatus(SellStatus.SOLD.getCode());
    seatMapper.update(updateSeat,seatLambdaUpdateWrapper);

    //将库中的对应票档进行更新库存
    int updateRemainNumberCount = 
            ticketCategoryMapper.batchUpdateRemainNumber(ticketCategoryCountDtoList,programOperateDataDto.getProgramId());
    if (updateRemainNumberCount != ticketCategoryCountDtoList.size()) {
        throw new DaMaiFrameException(BaseCode.UPDATE_TICKET_CATEGORY_COUNT_NOT_CORRECT);
    }
}

整体流程

为了让小伙伴对整个流程更加的清晰，本人画了张总体流程图来概括从购票到最后购买完整的执行过程 并使用不同颜色来分别代表不同的服务执行

数据库和缓存一致性问题

接下来我们说说数据库和缓存一致性问题

在开始购票流程前，都要先去查看节目详情，也就是把数据都放到了缓存中。而在流程图中可以看到，在购票流程时，始终都是先用redis的余票数量来做验证，而在对余票数量进行扣减和还原时，也都是直接使用lua+redis中进行的修改，所以并不会出现超卖的情况

也就是说 数据库和缓存的一致性带来的问题就进一步降低成了，只是显示不一致而已

如果真出现不一致了，也就是数据库余票数量大于缓存中的余票数量，用户体验就会出现明明余票有数量但是购买时会出现余票不足的提示

但这个问题正好规避掉了，因为大麦网中并不显示余票数量 哈哈

但话说回来，就算有余票数量显示的功能，数量不一致那又怎么样呢。本人在常见的订票系统像12306、携程、去哪网都订过票，发现它们的余票数量也都不是实时显示的，也会有订票了后，数量没有更新的时候，甚至过了10分钟后，数量也没更新

在大麦项目中，订单服务更新了缓存数据后，发送消息到延迟队列中，然后节目服务消费消息更新数据库中的数据，这里可以把延迟队列替换成Kafka或者其他的消息中间件，所以数据库和缓存的不一致的延迟时间取决于消息中间件的延迟时间，但消息中间件的效率执行起来非常的高，并不是想象中的那么脆弱

为什么要延迟？

解耦峰值压力

支付/下单是高并发热点：几万、几十万用户同时抢票，Redis 承受得住，但关系型数据库短时间内成千上万次写操作，很容易打满 IOPS、锁表、引起大面积延迟或死锁。延迟队列把写库操作均摊开来：消息在队列里先“缓一缓”，后台消费线程按自己的节奏、有节制地、批量或限流地把数据写入 DB，既稳又不影响主流程。

批量聚合写库

你可以把“同一个节目”或“同一个票档”的多条消息在队列里积累 100ms、200ms，然后一次性 batch update 或 batch insert，大幅降低数据库连接次数、事务开销，以及索引维护成本。

顺序一致性 & 重试机制

延迟队列自带重试和死信能力，如果写库失败（网络短暂抖动、主库切换等），可以自动重试或打到死信队列，不用在主流程里去做复杂的回滚/补偿。如果你立即消费、立刻写库，一旦写库抛出异常，就要在业务代码里处理「缓存回滚」「幂等保护」「补偿事务」……复杂度陡增。