分布式锁|消息队列 Redis用锁还是队列，redis用锁还是队列如何选择

🔒 Redis用锁还是队列？分布式场景下的选择艺术

场景引入：
凌晨3点，你的电商系统突然告警——秒杀活动开始后，100台限量手机被超卖成了120台！😱 检查代码发现：多个订单服务实例同时扣库存，谁都没“打招呼”，直接导致数据混乱，这时候你拍大腿：“早该用分布式锁或队列啊！”… 但到底选哪个？

先分清“锁”和“队列”的本质

分布式锁🔐：独占权控制

• 核心思想：同一时间只允许一个进程操作资源（比如改库存）
• Redis实现：SETNX key value + 过期时间（防死锁）
• 适用场景：
  • 强一致性要求高（如支付扣款）
  • 操作耗时极短（抢到锁后10ms内完成）

# 伪代码示例：用Redis锁防止超卖
if redis.setnx("lock:sku_123", 1, ex=5):  # 抢锁
    try:
        if stock > 0:
            stock -= 1  # 扣库存
    finally:
        redis.delete("lock:sku_123")  # 释放锁

消息队列📤：任务调度与缓冲

• 核心思想：把请求排成队，逐个消费（比如订单排队处理）
• Redis实现：LPUSH + BRPOP（或Stream数据结构）
• 适用场景：
  • 允许短暂延迟（如发短信通知）
  • 流量削峰（瞬间1万请求→队列慢慢消化）

# 伪代码示例：用Redis队列处理订单
redis.lpush("order_queue", json.dumps(order_data))  # 生产者入队
while True:
    order = redis.brpop("order_queue", timeout=30)  # 消费者阻塞读
    process_order(order)  # 异步处理

关键决策因素 🧐

实战选型建议 🛠️

✅ 选锁的场景

• 需要严格互斥：“这个库存必须立刻锁住，别人不能碰！”
• 操作非常快：比如更新数据库某行的状态字段
• Redis推荐方案：Redlock算法（多节点防单点故障）

✅ 选队列的场景

• 允许异步：“订单慢慢处理，只要今天发完货就行”
• 流量波动大：大促时先塞队列，避免服务被打崩
• Redis推荐方案：Stream数据结构（支持消费者组、ACK机制）

❌ 千万别用错

• 用锁处理耗时任务 → 系统卡死（锁占用太久）
• 用队列处理实时交易 → 用户等半天发现没响应

高级技巧 💡

混合使用

比如秒杀系统：

• 锁：快速拦截超卖（库存扣减）
• 队列：后续订单异步生成（通知、物流）

Redis的隐藏坑

• 锁的过期时间设置太短 → 业务没执行完锁就没了
• 队列消息堆积 → 内存爆炸（记得设置最大长度）

：没有银弹！锁像独木桥（一次一人过），队列像流水线（排队慢慢来），根据你的业务脾气（实时性、吞吐量）来选，甚至组合拳出击！ 🥊

ℹ️ 本文技术点参考Redis 2025年官方文档及分布式系统设计实践,部分案例来自电商行业真实故障复盘。