zk和redis分布式锁比较

一、zookeeper简介

统一管理分布式集群，ZooKeeper 是一个集中式服务，用于维护配置信息、命名、提供分布式同步和提供组服务。分布式应用程序以某种形式使用所有这些类型的服务。每次实现它们时，都需要进行大量工作来修复不可避免的错误和竞争条件。由于实现这些服务的难度，应用程序最初通常会吝啬它们，这使得它们在发生变化时变得脆弱且难以管理。即使正确完成，这些服务的不同实现也会导致部署应用程序时的管理复杂性。

主要是监听各个节点的情况，ZooKeeper 是分布式应用的高性能协调服务。它在一个简单的界面中公开了通用服务——例如命名、配置管理、同步和组服务，因此您不必从头开始编写它们。您可以使用现成的它来实现共识、组管理、领导者选举和出席协议。您可以根据自己的特定需求在此基础上进行构建。

节点分类

1.持久节点(PERSISTENT)

持久节点，创建后一直存在，直到主动删除此节点。

2.持久顺序节点(PERSISTENT_SEQUENTIAL)

持久顺序节点，创建后一直存在，直到主动删除此节点。在ZK中，每个父节点会为它的第一级子节点维护一份时序，记录每个子节点创建的先后顺序。

3.临时节点(EPHEMERAL)

临时节点在客户端会话失效后节点自动清除。临时节点下面不能创建子节点。

4.顺序临时节点(EPHEMERAL_SEQUENTIAL)

临时节点在客户端会话失效后节点自动清除。临时节点下面不能创建子节点。父节点getChildren会获得顺序的节点列表。

二、redis简介

Redis 与其他 key - value 缓存产品有以下三个特点：
Redis支持数据的持久化，可以将内存中的数据保存在磁盘中，重启的时候可以再次加载进行使用。
Redis不仅仅支持简单的key-value类型的数据，同时还提供list，set，zset，hash等数据结构的存储。
Redis支持数据的备份，即master-slave模式的数据备份。

Redis支持五种数据类型：string（字符串），hash（哈希），list（列表），set（集合）及zset(sorted set：有序集合)。

通过get获取值，set设置值

redis部署分类

1. 单机版，部署在一台服务器上
2. 主从复制：指定一台master，若干slave。只有mater有put权限，若master宕机只能等恢复
3. 哨兵模式：在主从复制的模式基础上，新增Sentinel(哨兵)进程是用于监控redis集群中Master主服务器工作的状态，在Master主服务器发生故障的时候，可以实现Master和Slave服务器的切换，保证系统的高可用。
4. 集群cluster模式：因为主从复制哨兵模式无法进行水平扩容，数据量存储的问题。配置多个节点存储数据，支持备份。节点之间相互监听。

三、分布式锁

1. zookeeper

首先创建一个持久化节点 /zklock
线程A：查询/zklock是否存在顺序临时节点lock，若不存在则新建此节点，并且执行同步逻辑
线程B：查询/zklock是否存在顺序临时节点lock，发现已经存在了，等待。。

2. redis

实现分布式锁按照安全等级分：

低等级

setnx lock test //上锁
del lock test //解锁
当某个key没有被占用的时候，setnx指令会返回1，否则返回0，这就是Redis中分布式锁的使用原理。当然我们还可以在上锁之后使用expire指令给锁设置过期时间。

Redis 2.8版本中加入了set指令的扩展参数，使得setnx指令和expire指令能够同时执行
set lock test ex 5 nxex
此方法效率高，容错率低

高等级

我们考虑这么一种情况：假设我们在redis的主节点上添加了一把分布式锁，不幸的是主节点挂掉了，而且主节点上的锁还没有同步到从节点上，如果此时有客户端来请求获得同一把锁，那么它将顺利地获得锁，之前那把锁会被无情地忽视掉，这就是分布式锁在Redis集群中遇到的麻烦。

Redis的作者为了解决这个问题提出了一个叫Redlock的算法：
它的原理是这样的：当上锁的时候，把set指令发送给过半的节点，只要过半的锁set成功，就认为这次加锁成功；当解锁的时候，会向所有的节点发送del指令。

redis红锁，在集群中的每个节点设置一个锁，注意锁不能重名，因为锁重名会覆盖，整个集群key不可以重复。开始在每个节点加锁，加锁完成后，当前线程开始加锁的时间，和加锁完成的时间，每个锁的剩余时间都要大于加锁完成的时间才行，保证半数以上符合以上条件即可

此方法效率低，容错率高

四、区别

众所周知，Redis标榜的是轻量级，直观上分布式锁是比较好实现的，比如使用setnx，但一旦加入高可用这个属性，Redis锁的实现难度就会爆炸式上升。

Redis，使用redisson封装的RedLock
Zk，使用curator封装的InterProcessMutex

实现难度上：Zookeeper >= redis
服务端性能：redis > Zookeeper
客户端性能：Zookeeper > redis
可靠性：Zookeeper > redis

最后是自己实现的gitee 的redis红锁的api

https://gitee.com/shenshuxin01/first_-spring-boot_-demo/tree/master/Redisson_RedLock_Demo