Redis 分布式锁：核心使用场景（全是实战高频场景）
Redis 分布式锁的核心作用：在分布式、多实例、多线程环境下，保证同一时间只有一个进程执行某段代码，避免并发冲突、数据错乱、重复操作。
下面是企业开发中最常用、最核心的 6 大使用场景，都是真实业务必用场景：
1. 防止重复提交 / 重复调用（最常用）
场景 ：用户点击按钮太快、前端重试、网络波动重试、消息重复投递，导致接口被多次调用，数据重复插入。
问题 ：重复创建订单、重复充值、重复发券、重复发送短信。
锁作用：同一个用户 + 同一个请求唯一标识，只允许执行一次。
典型业务：
- 订单提交
- 支付回调
- 表单提交
- 短信/邮件发送
2. 库存超卖 / 商品秒杀（高并发核心）
场景 ：商品库存只有 10 件，1000 人同时抢购。
问题 ：多个服务同时扣减库存，导致库存变成负数（超卖）。
锁作用：同一商品同一时间只允许一个请求扣库存，强制串行化。
典型业务：
- 电商秒杀
- 优惠券库存扣减
- 票务、名额抢购
3. 定时任务重复执行（微服务必用）
场景 ：微服务部署多个实例，同一个定时任务（如 @Scheduled、XXL-Job）会在多个服务器上同时执行。
问题 ：数据重复处理、重复统计、重复推送。
锁作用：只有抢到锁的实例才能执行任务，其他实例跳过。
典型业务：
- 每日订单统计
- 定时对账
- 定时清理垃圾数据
- 定时同步数据
4. 共享资源并发修改（数据一致性）
场景 ：多个服务/线程同时修改同一条共享数据 。
问题 ：并发覆盖、脏写、数据不一致。
锁作用：修改前加锁，保证同一时间只有一个人修改。
典型业务：
- 用户余额修改
- 积分增减
- 配置信息更新
- 状态流转（如订单状态变更）
5. 接口幂等性保证
场景 ：要求接口无论调用多少次，结果都只生效一次 。
问题 ：重试、超时重传、消息重复消费导致业务异常。
锁作用：用唯一请求 ID 加锁，确保只处理一次。
6. 分布式任务串行化
场景 ：某些操作不能并行 ，必须按顺序执行。
问题 ：并行执行导致业务逻辑混乱、依赖数据未准备好。
锁作用：强制排队执行。
典型业务：
- 工单流程处理
- 数据版本更新
- 依赖型任务执行
不适合用 Redis 分布式锁的场景（避坑）
- 强一致性金融场景 （如银行转账）
Redis 锁是非强一致的（AP 模型），金融级要用 Zookeeper / etcd 或者数据库事务。 - 长时间占用锁
Redis 锁不适合锁时长超过秒级的业务，容易超时失效导致问题。 - 高可用要求极高
Redis 主从切换可能存在锁丢失风险，需要用 Redlock（不推荐）或其他方案。
一句话总结
只要你的业务是：多实例部署 + 并发 + 不能重复执行 / 不能并发修改，就用 Redis 分布式锁。
总结
- 核心价值：分布式环境下防并发、防重复、保证数据安全
- 高频场景：防重复提交、秒杀超卖、定时任务、并发修改、幂等保证
- 不适用：金融强一致、长耗时锁、极高可靠性要求