主要解决问题
问题一：性能瓶颈问题
减少锁的竞争
降低数据库行锁开销
雪崩
问题二：数据一致性问题
原子扣减(双重保障)
异步落库的一致性保障
幂等处理
库存回滚
问题三：缓存和数据库双写不一致问题
延时双删（针对先删缓存、再更新数据库的优化）
基于消息队列的异步更新（最终一致性）
强一致性方案（分布式锁 / 读写锁）
问题四：其他相关业务问题
幂等性设计
库存扣减补偿机制
主要解决问题
锁粒度 性能瓶颈问题
锁竞争、数据库行锁开销、雪崩
事务ACID 数据一致性问题
超卖、少卖、库存不一致
缓存和数据库双写不一致问题
数据不一致、库存预热与回退问题
高并发 其他相关业务问题
重复扣款、下单、恶意请求
问题一：性能瓶颈问题
减少锁的竞争
库存分片，通过hash或轮询随机算法等将库存数据分片存储到不同的数据库实例中
如库存总量 1000，分为 10 个段，每段 100）
锁粒度(乐观锁代替悲观锁)
数据库层面使用版本号（version）或 CAS（Compare And Set）方式，避免长事务持有行锁
UPDATE stock SET count = count - #{num}, version = version + 1
WHERE id = #{id} AND version = #{oldVersion} AND count >= #{num}
降低数据库行锁开销
缓存预热 + 异步同步
将库存预热到 Redis，扣减请求先在 Redis 中完成，然后通过消息队列（如 RocketMQ、Kafka）异步将最终结果落库
请求到达 → Redis 扣减（Lua 脚本保证原子性） → 返回成功
发送“库存扣减成功”消息到 MQ
消费端批量消费消息，合并更新数据库（如每 100 条一次批量 update）
数据库行锁优化
确保扣减 SQL 走索引（如主键或唯一索引），避免表锁或间隙锁
使用 SELECT ... FOR UPDATE 时，务必在事务中尽快提交，减少锁持有时间
雪崩
限流->将请求拦截在系统前端，避免直接冲击数据库
(使用令牌桶、漏桶算法，限制单位时间内的请求量，保护后端系统)
熔断降级->当依赖的 Redis 或数据库出现超时、异常时，启动熔断器
多级缓存->
问题二：数据一致性问题
异步落库(导致数据库库存未扣减)
重复扣减
部分失败(扣减库存后，后续业务（如创建订单）失败)
缓存与数据库同步延迟(期间查询可能出现不一致)
原子扣减(双重保障)
Redis Lua 脚本
数据库乐观锁：落库时再次校验库存，防止异步过程中出现超卖
异步落库的一致性保障
本地消息表：在业务数据库中建一张消息表，将扣减记录和消息状态放在同一本地事务中
事务消息
幂等处理
全局唯一流水号：每次扣减操作生成唯一 ID（如订单号+商品ID），在消费端根据流水号去重
Redis 预检查：消费前先查 Redis 是否已处理过该流水号
库存回滚
消息驱动回滚：发送“库存回滚”消息，消费端执行库存增加
定时对账补偿：扫描超时未支付的订单，调用回滚接口
TCC 分布式事务：若业务要求强一致性
通常秒杀场景可接受短暂不一致（最终一致），优先保证高并发
问题三：缓存和数据库双写不一致问题
延时双删（针对先删缓存、再更新数据库的优化）
允许短时间不一致，但希望最终一致
先删除缓存。
更新数据库。
延时一段时间（如 500ms），再次删除缓存
redis.delete(key);
database.update(data);
// 延迟执行，可采用线程池或消息队列
executor.schedule(() -> redis.delete(key), 500, TimeUnit.MILLISECONDS);
基于消息队列的异步更新（最终一致性）
对一致性要求较高，可接受短暂不一致，但需保证最终一致
更新数据库后，发送一条“更新缓存”的消息到消息队列，由消费者异步更新缓存。
若更新失败，可重试
解耦，可靠性高（消息持久化），重试机制保证最终一致性
@Transactional
public void updateData(Data data) {
database.update(data);
// 事务提交后发送消息
transactionSynchronization.registerSynchronization(new TransactionSynchronization() {
public void afterCommit() {
mqSender.send("cache_update", data);
}
});
}
// 消费者
@RabbitListener
public void handleCacheUpdate(Data data) {
redis.set(data.getId(), data);
}
强一致性方案（分布式锁 / 读写锁）
对一致性要求极高（如金融交易），但并发量较低
对同一数据的读写操作加分布式锁，保证同一时刻只有一个线程能读写数据
问题四：其他相关业务问题
幂等性设计
全局唯一流水号：每次扣减请求携带唯一标识（如订单号、业务流水号），在服务端记录已处理的流水号
Redis 去重：使用 Redis SETNX 命令，将流水号作为 key 存储，
设置合理过期时间，重复请求直接拒绝。
数据库去重表：建一张去重表，以流水号作为唯一索引，
扣减前先插入，若主键冲突则说明已处理。
业务状态机：订单状态流转（如待支付、已支付、已取消），只有在特定状态才允许扣减库存，避免重复操作
库存扣减补偿机制
定时任务扫描
定期扫描超时未支付的订单，调用库存服务回滚接口（增加库存）。注意要处理并发问题，避免重复释放
延迟消息
下单成功后发送一条延迟消息
状态机驱动
订单状态变更时（如取消、超时关闭），主动触发库存回滚