电商秒杀平台项目记录 Day4

Day 4 (5/27/2024):

今天做了对这个项目的数据一致性的处理

1.首先第一个处理是使用RocketMQ的延迟消息来关闭超时订单（未在规定时间内付完款所以被关闭了订单）

为什么使用延迟消息这个方法呢？原本想使用定时轮询这个方案来做，但是后面发现定时轮询有以下几个缺点：

1. 时效性差：如果每分钟轮询一次，那么订单取消的最大误差就有一分钟

2. 容易积压：如果一分钟之内有大量数据，但是一分钟内没处理完，那么下一分钟的就会顺延。

3. 效率低 ：需要遍历资源，不适合拥有大量数据的项目。

2. RocketMQ的延迟消息的功能特点：

1. 支持多等级延迟消息，但不支持自定义精度

2. 有18个延迟等级：1s 5s 10s 30s 1m 2m 3m 4m 5m 6m 7m 8m 9m 10m 20m 30m 1h 2h

3. 通过broker来配置：通过 broker 端的 messageDelayLevel 配置项确定

3. 然后实现了限购功能

首先先完善了“添加限购名单”的代码块，利用redis中的sadd的功能把购买者加入redis数据库里去。

然后还添加了一个代码块用来判断这个用户是否是在限购名单里的，利用redis中的sismember来查询该购买者是否在限购名单内

最后还添加了一个代码块用来把购买者从限购名单里移出去的代码块（如果未付款，则购买失败，移出限购名单），利用redis中的srem来把购买者从限购名单里移出去。

4. 做了对付款、库存扣减数据的一致性处理

对库存扣减时机做了一个判断：在创建订单时锁定库存，然后在用户支付时扣减库存，这样最能保证数据的一致性

这样的好处就是，当用户创建订单时，我们只是将redis中缓存的库存数据给进行锁定，然后同步调用付款接口，接着当消费者真正付款之后，我们才去数据库里将库存减1，如果付款失败的话，我们就将原先的锁定的库存解锁返还，而真正库存的数量其实并没有变化。