zk分布式锁流程图

<think>好的，用户之前问了乐观锁和悲观锁在数据库应对秒杀场景的优缺点，现在接着问ZooKeeper和Redisson实现分布式锁应对秒杀的情况。这说明用户可能在设计秒杀系统，需要选择合适的分布式锁方案。 首先，我需要回忆ZooKeeper和Redisson的基本原理。ZooKeeper通过ZNode和Watcher机制实现分布式锁，比如顺序临时节点。Redisson是基于Redis的客户端，使用Lua脚本和看门狗机制实现锁。 用户可能想了解两者的优缺点对比，以及在高并发秒杀中的适用性。需要比较它们的性能、可靠性、实现复杂度等方面。 考虑到秒杀场景的特点：高并发、低延迟、高可用。ZooKeeper的写操作（比如创建节点）可能性能不如Redis，因为ZooKeeper保证强一致性，每次写需要多数节点确认，而Redis是内存存储，速度更快。但ZooKeeper的临时节点能有效处理客户端崩溃导致的锁释放问题，而Redis可能需要额外的机制来避免死锁。 Redisson的看门狗机制可以自动续期锁，避免业务执行时间过长导致锁过期。而ZooKeeper的临时节点在会话结束时会自动删除，这可能更可靠。 另外，秒杀场景中，锁的粒度也很重要。比如库存分片，减少锁竞争。可能需要提到如何结合这两种锁方案进行优化。 还要注意网络分区的情况，比如Redis的AP模型在脑裂时可能锁失效，而ZooKeeper是CP，可能更可靠但可用性降低。用户可能需要根据业务需求权衡。 最后，给出实际应用中的建议，比如在高并发下优先使用Redisson，因为性能更高；如果对一致性要求极高，考虑ZooKeeper，或者结合其他方案如缓存预减库存。</think>在应对秒杀场景时，ZooKeeper和Redisson实现分布式锁的方案对比如下（附典型架构和优化策略）： --- ### 一、Redisson分布式锁（基于Redis） **实现原理**：通过Lua脚本保证原子性操作 + 看门狗自动续期 ```java // 典型使用代码 RLock lock = redisson.getLock("secKillLock"); try { if(lock.tryLock(1, 10, TimeUnit.SECONDS)) { // 业务逻辑：库存判断与扣减 if(redis.decr("stock") >= 0) { sendToMQ(order); // 异步落库 } } } finally { lock.unlock(); } ``` #### 优势： 1. **高性能**：单节点TPS可达5万+（集群模式更高） 2. **自动续期**：看门狗机制防止业务未完成锁过期 3. **可重入设计**：支持同一线程多次加锁 4. **故障转移**：主从切换时通过多重机制保证锁安全 #### 缺陷： 1. **网络分区风险**：脑裂时可能出现双写（需配置redlock算法） 2. **时钟依赖**：依赖系统时间一致性（需NTP同步） 3. **锁粒度控制**：需自行设计细粒度锁（如按商品ID分片） --- ### 二、ZooKeeper分布式锁（基于临时顺序节点） **实现原理**：创建临时顺序节点 + Watcher监听机制 ```java // Curator框架示例 InterProcessMutex lock = new InterProcessMutex(client, "/locks/secKill"); if (lock.acquire(1, TimeUnit.SECONDS)) { try { // 业务逻辑 if(zookeeper.checkStock()) { createOrderNode(); } } finally { lock.release(); } } ``` #### 优势： 1. **强一致性**：基于ZAB协议保证CP特性 2. **自动清理**：会话断开时临时节点自动删除 3. **公平锁**：节点顺序天然实现先到先得 4. **可视化**：可通过zkCli查看锁状态 #### 缺陷： 1. **性能瓶颈**：写操作TPS约1万左右（3节点集群） 2. **惊群效应**：大量Watcher通知可能引发性能抖动 3. **运维成本**：需维护ZK集群，客户端需处理会话超时 --- ### 三、秒杀场景关键指标对比 | 维度 | Redisson | ZooKeeper | |---------------------|-----------------------|-----------------------| | 锁类型 | 非公平锁 | 公平锁 | | 性能（TPS） | 5万+ | 1万左右 | | 一致性模型 | AP（默认） | CP | | 锁释放机制 | 超时自动释放 | 会话断开自动释放 | | 实现复杂度 | 低（客户端封装完善） | 中（需处理会话管理） | | 典型适用场景 | 高频短时操作 | 低频强一致性操作 | --- ### 四、秒杀优化组合方案 #### 分层锁设计（推荐架构）： 1. **第一层：本地锁** ```java ConcurrentHashMap<String, Object> segmentLocks = new ConcurrentHashMap<>(); Object segmentLock = segmentLocks.computeIfAbsent(productId, k -> new Object()); synchronized(segmentLock) { // 本地库存预判 } ``` 2. **第二层：分布式锁** - 使用Redisson执行快速库存扣减 ```lua if redis.call('exists', KEYS[1]) == 1 then local stock = tonumber(redis.call('get', KEYS[1])) if stock > 0 then redis.call('decr', KEYS[1]) return 1 end end return 0 ``` 3. **第三层：最终校验** - 用ZooKeeper做最终全局一致性检查（兜底方案） #### 性能优化技巧： 1. **锁分片**：按商品ID哈希分片（如将1000库存拆分为10个Redisson锁） ```java int shard = productId.hashCode() % 10; RLock shardLock = redisson.getLock("LOCK_" + shard); ``` 2. **热点分离**： - 独立Redis集群处理秒杀商品 - 使用物理隔离的ZK集群 3. **降级策略**： ```java // Hystrix降级示例 @HystrixCommand(fallbackMethod = "fallbackSecKill") public String secKill(String productId) { // 正常业务流程 } ``` --- ### 五、选型建议 1. **纯Redis方案适用**： - 秒杀峰值超过10万QPS - 允许极少数超卖（后续补偿） - 示例：限量电子优惠券发放 2. **ZooKeeper方案适用**： - 库存量极少（如限量版商品） - 要求绝对不超卖 - 示例：茅台酒限量抢购 3. **混合方案最佳实践**： - 用Redisson处理99%的请求 - 用ZooKeeper做最终库存同步 - 架构图： ``` 用户请求 → 限流层 → Redis库存预扣 → MQ削峰 → ZooKeeper最终校验 → 数据库落单 ``` --- ### 六、异常处理指南 1. **Redisson锁常见问题**： - **锁续期失败**：增加看门狗超时阈值（默认30秒） - **主从切换丢锁**：启用MultiLock（需性能权衡） ```java RLock lock1 = redisson.getLock("lock1"); RLock lock2 = redisson.getLock("lock2"); RedissonMultiLock lock = new RedissonMultiLock(lock1, lock2); ``` 2. **ZooKeeper锁注意事项**： - **会话超时**：合理设置sessionTimeout（建议3-5秒） - **节点清理**：定期执行zkCleanup.sh清理历史节点 - **重试策略**：使用Curator的RetryNTimes策略 实际生产环境中，**建议优先采用Redisson方案**，在极端情况下配合ZooKeeper做二次校验，既能保障高并发性能，又能实现最终强一致性。