1.第一种方式通过创建相同节点，谁能创建成功谁获取到锁，解锁删除节点，没获取到的线程进行自旋操作，直到获取到锁，这种方式跟redis一样，比较耗费cup
2.创建临时序列化节点，判断自己是否是节点下最小序列节点，如果是那就加锁，不是就监听前一个节点。这种是公平锁，如果zk心跳检测不到java客户端，就会把临时节点给删除掉，所以不存在死锁的情况。
redis分布式锁也可以实现阻塞方式,通过发布订阅方式来实现阻塞
使用 Redis 和 Zookeeper 实现分布式锁是两种常见的方式，它们在实现原理、性能、可靠性和适用场景上有显著的区别。以下是它们的详细对比：
1. 实现原理
Redis 分布式锁
基于 SETNX 命令：
使用
SETNX（SET if Not eXists）命令尝试设置一个键值对，如果键不存在则设置成功，表示获取锁。通常结合
EXPIRE命令设置锁的超时时间，避免死锁。
Redlock 算法：
Redis 官方推荐的分布式锁算法，通过在多个 Redis 节点上获取锁来提高可靠性。
Zookeeper 分布式锁
基于临时顺序节点：
在 Zookeeper 中创建一个临时顺序节点，节点编号最小的客户端获取锁。
如果客户端释放锁（会话结束或主动删除节点），Zookeeper 会自动删除临时节点。
Watch 机制：
客户端通过 Watch 机制监听前一个节点的删除事件，当前一个节点被删除时，尝试获取锁。
2. 性能
Redis 分布式锁
高性能：
Redis 基于内存操作，读写速度极快，适合高并发场景。
网络开销：
每次获取锁和释放锁都需要与 Redis 服务器通信，网络延迟可能影响性能。
Zookeeper 分布式锁
较低性能：
Zookeeper 的写操作需要持久化到磁盘，性能低于 Redis。
Watch 机制开销：
Watch 机制需要维护客户端与服务器的长连接，可能增加系统开销。
3. 可靠性
Redis 分布式锁
可靠性较低：
Redis 是内存数据库，数据可能丢失（即使开启 AOF 或 RDB 持久化，也存在数据丢失的风险）。
如果 Redis 主从切换，可能导致锁失效。
Redlock 提高可靠性：
Redlock 算法通过多个 Redis 节点提高可靠性，但实现复杂，且在某些极端情况下仍可能失效。
Zookeeper 分布式锁
高可靠性：
Zookeeper 采用 ZAB 协议（类似 Paxos），保证数据的一致性和可靠性。
临时节点的特性确保客户端崩溃时锁会自动释放，避免死锁。
强一致性：
Zookeeper 提供强一致性，锁的状态在所有客户端中是一致的。
4. 适用场景
Redis 分布式锁
高并发场景：
适合对性能要求高、允许偶尔锁失效的场景（如缓存、限流等）。
短时任务：
适合锁持有时间较短的场景。
Zookeeper 分布式锁
高可靠性场景：
适合对可靠性要求高、不允许锁失效的场景（如分布式任务调度、资源分配等）。
长时任务：
适合锁持有时间较长的场景。
5. 实现复杂度
Redis 分布式锁
简单易用：
实现简单，适合快速集成。
Redlock 复杂：
Redlock 算法实现复杂，需要考虑多个 Redis 节点的协调。
Zookeeper 分布式锁
实现复杂：
需要理解 Zookeeper 的临时节点和 Watch 机制，实现相对复杂。
客户端支持：
Zookeeper 客户端库（如 Curator）提供了分布式锁的实现，简化了开发。
6. 总结对比
| 特性 | Redis 分布式锁 | Zookeeper 分布式锁 |
|---|---|---|
| 实现原理 | 基于 SETNX 和 Redlock 算法 | 基于临时顺序节点和 Watch 机制 |
| 性能 | 高性能，适合高并发场景 | 较低性能，适合可靠性要求高的场景 |
| 可靠性 | 较低，可能存在锁失效 | 高可靠性，强一致性 |
| 适用场景 | 高并发、短时任务 | 高可靠性、长时任务 |
| 实现复杂度 | 简单（SETNX）或复杂（Redlock） | 较复杂，但客户端库支持 |
7. 选择建议
选择 Redis：
如果对性能要求高，且可以接受偶尔的锁失效。
适合缓存、限流等场景。
选择 Zookeeper：
如果对可靠性要求高，且需要强一致性。
适合分布式任务调度、资源分配等场景。
希望这些信息能帮助你更好地选择适合的分布式锁实现方案！