分布式锁用于微服务中保证共享资源互斥访问，常用实现方式有基于redis、zookeeper和数据库三种。1. redis通过SET命令的NX和EX参数实现高性能加锁，配合lua脚本安全释放锁，支持超时与续期，推荐使用Redisson提升可靠性；2. ZooKeeper利用临时顺序节点实现强一致性锁，具备自动释放机制，适合高一致场景但性能较低；3. 数据库基于唯一约束实现简单锁，性能差且存单点风险，仅适用于无中间件依赖的临时场景。选型需权衡性能、一致性与运维成本，优先选用Redisson或Curator等成熟工具。
在微服务架构中，多个服务实例可能同时访问共享资源，比如库存扣减、订单状态更新等场景。为了避免并发冲突，需要使用分布式锁来保证操作的互斥性。与单机环境下的锁不同，分布式锁必须在多个节点之间协调，因此实现方式也更加复杂。
基于 Redis 实现分布式锁
Redis 因其高性能和原子操作支持，是实现分布式锁的常用选择。核心命令是 SETNX（Set if Not eXists）或更推荐的 SET 命令配合 NX 和 EX 参数。
基本实现逻辑如下：
- 使用 SET resource_name random_value NX EX 30 来尝试加锁，其中 resource_name 是锁的唯一标识（如 order:1001），random_value 是客户端生成的唯一值（用于安全释放锁），EX 30 表示锁最多持有 30 秒。
- 加锁成功后，执行业务逻辑。
- 释放锁时，需通过 Lua 脚本确保原子性：先判断当前锁的 value 是否等于自己的 random_value，如果是再执行 DEL，避免误删其他客户端的锁。
为提高可靠性，可结合 Redisson 等客户端工具，它封装了自动续期（看门狗机制）、可重入锁等功能，降低出错概率。
基于 ZooKeeper 实现分布式锁
ZooKeeper 利用临时顺序节点实现分布式锁，其一致性更强，适合对强一致性要求高的场景。
实现原理如下：
- 每个客户端尝试获取锁时，在指定的父节点下创建一个临时顺序节点。
- 检查自己创建的节点是否是当前最小的顺序节点，如果是，则获得锁。
- 如果不是最小节点，则监听前一个节点的删除事件，一旦前一个节点被删除（即锁释放），当前客户端被通知并重新判断是否可以获取锁。
ZooKeeper 的临时节点特性保证了客户端崩溃时锁能自动释放，避免死锁。但性能相对 Redis 较低，且依赖 ZK 集群的可用性。
基于数据库实现（较少使用）
可以通过数据库的唯一约束来实现简单分布式锁。例如创建一张锁表，字段包括 lock_key（唯一索引）和 owner 等。
- 加锁时插入一条记录，如果插入成功说明获取锁，失败则表示已被占用。
- 释放锁时删除该记录。
这种方式实现简单，但性能差、存在单点瓶颈，一般只在没有中间件依赖的场景下临时使用。
使用注意事项
无论采用哪种方式，都需要注意以下几点：
- 锁必须设置超时时间，防止客户端异常导致死锁。
- 释放锁的操作要具备幂等性和安全性，不能误删他人锁。
- 考虑网络分区情况下的正确性，如 Redis 主从切换可能导致多个客户端同时持有同一把锁（脑裂问题），可通过 Redlock 算法缓解，但代价高且争议大。
- 优先选择成熟的开源组件，如 Redisson、Curator，避免重复造轮子。
基本上就这些。选择哪种方案取决于你的系统对性能、一致性、运维复杂度的要求。Redis 方案更轻量，ZooKeeper 更可靠，按需选型即可。