SpringBoot电商秒杀项目优化知识点总结(第八章)

最新推荐文章于 2024-04-06 10:15:59 发布

Shijie Peng

最新推荐文章于 2024-04-06 10:15:59 发布

阅读量569

点赞数 1

分类专栏： SpringBoot项目文章标签： spring boot java 数据库

本文链接：https://blog.csdn.net/psj_1161885042/article/details/125941919

版权

SpringBoot项目专栏收录该内容

9 篇文章 1 订阅

订阅专栏

这里写目录标题

8-1 事务型消息（上）
8-2 事务型消息应用（下）
8-3 库存流水状态（1）
8-7 库存售罄处理方案
8-8 后置流程总结

8-1 事务型消息（上）

缺点:在createOrder()的订单入库及后续步骤中若发生异常导致回滚给消息队列发送的消息无法撤回导致数据库库存显示比实际的少
修改:等事务提交成功后再发送消息将异步发送消息的语句后移到createOrder()的return前
缺点:@Transactional只有等到方法返回的时候才会commit 如果return失败依旧会发生相同的问题
修改:将消息放入此种:

TransactionSynchronizationManager.registerSynchronization(new TransactionSynchronization() {
    @Override
    public void afterCommit() {
    }
});

问题:此时事务完全提交之后才发送消息但是若发送消息时或者在afterCommit()中发送消息之前失败则不能回滚
解决:TransactionProducer:换了个producer构造方法另外开了一个线程注册了一个transactionListener 投递了sendMessageInTransaction 最后使用注册了一个transactionListener消费

8-2 事务型消息应用（下）

发送事务型消息:二阶段提交
transactionMQProducer.sendMessageInTransaction(message,null);
发送一个prepare状态的消息 broker可以接收到该消息但consumer不会处理该消息同时回调executeLocalTransaction()方法在此方法中执行真正的业务逻辑根据执行结果的不同返回COMMIT_MESSAGE,ROLLBACK_MESSAGE或UNKNOW 从而决定该事务型消息的状态

若消息一直为UNKNOW或者prepare状态 producer会定期回调checkLocalTransaction方法可在此处验证下单状态是否为成功从而重置消息的状态因此需要引入库存流水

异步同步数据库问题:
(1) 异步消息发送失败
(2）扣减操作执行失败
(3）下单失败无法正确回补库存:需要库存操作流水

操作流水数据类型:
主业务数据:master data
操作型数据:log data (库存流水)

8-3 库存流水状态（1）

DROP TABLE IF EXISTS `stock_log`;
CREATE TABLE `stock_log`  (
  `stock_log_id` varchar(64) NOT NULL,
  `item_id` int(11) NOT NULL DEFAULT 0,
  `amount` int(11) NOT NULL DEFAULT 0,
  `status` int(11) NOT NULL DEFAULT 0 COMMENT '//1表示初始状态 2表示下单扣减库存成功 3表示下单回滚',
  PRIMARY KEY (`stock_log_id`) USING BTREE
) ENGINE = InnoDB CHARACTER SET = utf8 COLLATE = utf8_bin ROW_FORMAT = Compact;

//在下单之前初始化库存流水将库存流水的id一步步传入checkLocalTransaction方法中从而定期检查根据每一条流水的状态设定消息的状态

@Override
@Transactional
public String initStockLog(Integer itemId, Integer amount) {
    StockLogDO stockLogDO = new StockLogDO();
    stockLogDO.setStockLogId(UUID.randomUUID().toString().replace("-",""));
    stockLogDO.setItemId(itemId);
    stockLogDO.setAmount(amount);
    stockLogDO.setStatus(1);

    stockLogDOMapper.insertSelective(stockLogDO);
    return stockLogDO.getStockLogId();
}

//在orderservice的createorder方法中设置库存流水状态为成功 由于该方法有@Transactional注解 所以保持事务的一致性
StockLogDO stockLogDO = stockLogDOMapper.selectByPrimaryKey(stockLogId);
if (stockLogDO == null) {
    throw new BusinessException(EmBusinessError.UNKNOWN_ERROR);
}
stockLogDO.setStatus(2);
stockLogDOMapper.updateByPrimaryKeySelective(stockLogDO);

//修改MqProducer.java
@PostConstruct
public void init() throws MQClientException {
    //mq producer的初始化
    producer = new DefaultMQProducer("producer_group");
    producer.setNamesrvAddr(nameAddr);
    producer.start();

    transactionMQProducer = new TransactionMQProducer("transaction_producer_group");
    transactionMQProducer.setNamesrvAddr(nameAddr);
    transactionMQProducer.start();


    transactionMQProducer.setTransactionListener(new TransactionListener() {
        @Override
        public LocalTransactionState executeLocalTransaction(Message message, Object arg) {
            //真正要做的事 创建订单
            Integer userId = (Integer) ((Map)arg).get("userId");
            Integer itemId = (Integer) ((Map)arg).get("itemId");
            Integer promoId = (Integer) ((Map)arg).get("promoId");
            Integer amount = (Integer) ((Map)arg).get("amount");
            String stockLogId = (String) ((Map)arg).get("stockLogId");

            try {
                orderService.createOrder(userId,itemId,promoId,amount,stockLogId);
            } catch (BusinessException e) {
                e.printStackTrace();
                //设置对应的stockLog为回滚状态
                StockLogDO stockLogDO = stockLogDOMapper.selectByPrimaryKey(stockLogId);
                stockLogDO.setStatus(3);
                stockLogDOMapper.updateByPrimaryKeySelective(stockLogDO);
                return LocalTransactionState.ROLLBACK_MESSAGE;
            }
            return LocalTransactionState.COMMIT_MESSAGE;
        }

        @Override
        public LocalTransactionState checkLocalTransaction(MessageExt msg) {
            //根据扣减库存是否成功 来判断要返回COMMIT_MESSAGE COMMIT_MESSAGE 还是UNKNOW
            String jsonString = new String(msg.getBody());
            Map<String, Object> map = JSON.parseObject(jsonString,Map.class);
            String stockLogId = (String) map.get("stockLogId");
            StockLogDO stockLogDO = stockLogDOMapper.selectByPrimaryKey(stockLogId);
            if (stockLogDO == null) {
                return LocalTransactionState.UNKNOW;
            }
            if (stockLogDO.getStatus().intValue() == 2) {
                return LocalTransactionState.COMMIT_MESSAGE;
            } else if (stockLogDO.getStatus().intValue() == 1) {
                return LocalTransactionState.UNKNOW;
            }
            return LocalTransactionState.ROLLBACK_MESSAGE;
        }
    });
}

目前对createorder方法的改造:
1.ItemModel的验证修改为缓存验证
2.UserModel的验证修改为缓存验证
3.校验活动信息修改为内存校验
4.落单减库存修改为缓存修改
5.订单入库必须使用数据库修改
6.商品销量在后续步骤中优化
7.新增了对库存流水数据库表的查找和更新操作:实际上没有减少对数据库性能的优化之前都在对item表进行操作都在item表中使用行锁这里单独在sotck_log表中使用行锁不需要锁并发的机制性能消耗小

库存数据库最终一致性保证方案︰
(1)引入库存操作流水
(2)引入事务性消息机制
此时的问题:
(1)redis不可用时如何处理:在保证所有异步消息的同步状态都完成下可以回源到数据库
(2)扣减流水错误如何处理:让用户下单直接失败或者等待

业务场景决定高可用技术实现
设计原则∶
-宁可少卖，不能超卖
方案∶
(1)redis可以比实际数据库中少但是若redis产生问题则绝对不能回源到数据库
(2)超时释放:若createorder方法长时间不返回则不断的产生状态为UNKNOW的订单但是redis中却一直在减少库存导致少卖很多需要设计超时释放的功能在用户长时间不确定下单或者下单卡死时将redis中的额库存加回去

8-7 库存售罄处理方案

此时无论库存为多少都一定会产生新的库存流水
库存售罄:
库存售罄标识
售罄后不去操作后续流程
售罄后通知各系统售罄来清除缓存
回补上新

8-8 后置流程总结

后置流程:
1.销量逻辑异步化:将item模型的销量字段加一同样会产生行锁解决方案一致
2.交易单逻辑异步化:当冻结库存成功之后直接返回交易成功并且将所有操作修改为异步化操作
(1)生成交易单sequence后直接异步返回:下单操作可以异步但支付操作不能异步只能在支付操作前生成交易订单相关信息
(2)前端轮询异步单状态:本质为假异步化体验较差一般不采用异步下单模型而是异步同步库存模型