Redis实现购物秒杀及分布式锁

全局唯一ID

Redis自增ID策略

ID构造是：时间戳 + 计数器

每天一个key，方便统计订单量

业务实现

获取指定时间的秒数

LocalDateTime timeBegin = LocalDateTime.of(2024, 1, 1, 0, 0, 0);
long second = timeBegin.toEpochSecond(ZoneOffset.UTC);

获取当前时间的秒数

long now = LocalDateTime.now().toEpochSecond(ZoneOffset.UTC);

全局唯一ID业务代码

public Long getID(String key) {// 获取时间戳long now = LocalDateTime.now().toEpochSecond(ZoneOffset.UTC);long timestamp = now - TIMESTAMP_BEGIN;// 利用redis实现自增长String date = new SimpleDateFormat("yyyyMMdd").format(new Date());Long inc = redisTemplate.opsForValue().increment("ID:" + key + ":" + date);// 拼接并返回return timestamp << 32 | inc;
}

实现秒杀下单

秒杀下单逻辑流程

业务实现

@Transactional
public String getProduct(Long id) {// 判断商品是否存在Product pro = getById(id);if (pro == null) {throw new BusinessException(400, "商品不存在");}// 判断库存int num = pro.getNum();if (num <= 0) {throw new BusinessException(400, "库存不足");}// 库存 - 1pro.setNum(num - 1);update(pro, new QueryWrapper<>());// 下订单Ordertable order = new Ordertable();order.setOrderID(idUtil.getID("order").toString());order.setUserID(123);ordertableService.save(order);return order.getOrderID();
}

“超卖”问题

问题复现

在多线程并发会产生问题

使用5000个线程进行测试

20个库存卖了210个订单

原因分析

锁的类型

超卖问题是典型的多线程安全问题，针对这一问题的常见解决方案就是加锁

悲观锁：认为线程安全问题一定会发生，因此在操作数据之前先获取锁，确保线程串行执行。

• 例如Synchronized、Lock都属于悲观锁

乐观锁：认为线程安全问题不一定会发生，因此不加锁，只是在更新数据时去判断有没有其它线程对数据做了修改。

• 如果没有修改则认为是安全的，自己才更新数据。
• 如果已经被其它线程修改说明发生了安全问题，此时可以重试或异常。

乐观锁

乐观锁的关键是判断之前查询得到的数据是否有被修改过。（CAS法）

代码实现