分布式锁实现原理
redis分布式锁到底安全吗
转载：https://mp.weixin.qq.com/s/ybiN5Q89wI0CnLURGUz4vw
缓存穿透
转载：https://mp.weixin.qq.com/s?__biz=Mzg4MjYzMjI1MA==&mid=2247528072&idx=1&sn=019a5d448702b5cbe13571f6564539db&chksm=cf519dddf82614cb8ae118e7c7e7f46c6a331f7fcec4e535166cd8d41c97649ccc03897a7827&scene=132#wechat_redirect
分布式锁，是控制分布式系统之间同步访问共享资源的一种方式。
在分布式系统中，常常需要协调他们的动作。如果不同的系统或是同一个系统的不同主机之间共享了一个或一组资源，那么访问这些资源的时候，往往需要互斥来防止彼此干扰来保证一致性，在这种情况下，便需要使用到分布式锁。
1、Redis实现分布式锁的原理：
setnx 是『SET if Not eXists』(如果不存在，则 SET)的简写。 命令格式：SETNX key value；使用：只在键 key 不存在的情况下，将键 key 的值设置为 value 。若键 key 已经存在， 则 SETNX 命令不做任何动作。返回值：命令在设置成功时返回 1 ，设置失败时返回 0 。
getset 命令格式：GETSET key value，将键 key 的值设为 value ，并返回键 key 在被设置之前的旧的value。返回值：如果键 key 没有旧值， 也即是说， 键 key 在被设置之前并不存在， 那么命令返回 nil 。当键 key 存在但不是字符串类型时，命令返回一个错误。
expire 命令格式：EXPIRE key seconds，使用：为给定 key 设置生存时间，当 key 过期时(生存时间为 0 )，它会被自动删除。返回值：设置成功返回 1 。 当 key 不存在或者不能为 key 设置生存时间时(比如在低于 2.1.3 版本的 Redis 中你尝试更新 key 的生存时间)，返回 0 。
del 命令格式：DEL key [key …]，使用：删除给定的一个或多个 key ，不存在的 key 会被忽略。返回值：被删除 key 的数量。
1.通过setnx(lock_timeout)实现，如果设置了锁返回1， 已经有值没有设置成功返回0
2.死锁问题：通过实践来判断是否过期，如果已经过期，获取到过期时间get(lockKey)，然后getset(lock_timeout)判断是否和get相同，相同则证明已经加锁成功，因为可能导致多线程同时执行getset(lock_timeout)方法，这可能导致多线程都只需getset后，对于判断加锁成功的线程， 再加expire(lockKey, LOCK_TIMEOUT, TimeUnit.MILLISECONDS)过期时间，防止多个线程同时叠加时间，导致锁时效时间翻倍
代码：
public class RedisLockTest {
public static final String url = "jdbc:mysql://127.0.0.1:3306/ly?characterEncoding=UTF-8";
public static final String name = "com.mysql.jdbc.Driver";
public static final String user = "root";
public static final String password = "";
public static void main(String[] args) {
Integer count = 50;
while (count > 0) {
count--;
new Thread(new Runnable() {
@Override
public void run() {
Jedis jedis = new Jedis("127.0.0.1", 6379);
jedis.auth("1234");
String lock = lock(jedis);
if (lock != null) {
Statement statement = null;
Connection conn = null;
ResultSet resultSet = null;
try {
Class.forName(name);// 指定连接类型
conn = DriverManager.getConnection(url, user, password);// 获取连接
statement = conn.createStatement();// 准备执行语句
String querySql = "SELECT id,name,count FROM production WHERE id=2";
resultSet = statement.executeQuery(querySql);
int count = 0;
while (resultSet.next()) {
System.out.println(Thread.currentThread().getName() + "抢到了锁 id: " + resultSet.getString("id")
+ " name: " + resultSet.getString("name")
+ " count: " + resultSet.getString("count"));
count = Integer.valueOf(resultSet.getString("count"));
}
String updateSql = "UPDATE production SET count=" + (count - 1) + " WHERE id=2";
int rows = statement.executeUpdate(updateSql);
if (rows > 0) {
System.out.println("更新成功" + Thread.currentThread().getName() + " 库存剩余：" + (count - 1));
System.out.println(Thread.currentThread().getName() + " === > >开始解锁");
boolean unlock = unlock(jedis, lock);
if (unlock) System.out.println(Thread.currentThread().getName() + " === > >解锁成功");
} else {
System.out.println("更新失败" + Thread.currentThread().getName());
}
} catch (Exception e) {
e.printStackTrace();
} finally {
try {
if (conn != null) conn.close();
if (statement != null) statement.close();
if (resultSet != null) resultSet.close();
} catch (Exception e) {
e.printStackTrace();
}
}
}
}
}, "线程" + count).start();
}
}
public static String lock(Jedis jedis) {
try {
while (true) {
String lockTime = Long.valueOf(jedis.time().get(0)) + 5 + "";
if (jedis.setnx("lock", lockTime) == 1) {
jedis.expire("lock", 5);
return lockTime;
}
String lock = jedis.get("lock");
if (!StringUtils.isEmpty(lock) && Long.valueOf(lock) < Long.valueOf(jedis.time().get(0))) {
String oldLockTime = jedis.getSet("lock", lockTime);
if (!StringUtils.isEmpty(oldLockTime) && oldLockTime.equals(lock)) {
return lockTime;
}
}
Thread.sleep(100);
}
} catch (Exception e) {
e.printStackTrace();
}
return null;
}
public static boolean unlock(Jedis jedis, String lockTag) {
if (lockTag.equals(jedis.get("lock"))) {
jedis.del("lock");
return true;
}
return false;
}
}
运行结果如下图：
2、zookeeper分布式锁实现原理
2.1、zookeeper的角色
leader(领导者) 负责进行投票的发起和决议，更新系统状态
learner(学习者) ，学习者主要包含了follower(观察者) 和(observer) 观察者，
- follower用于接受客户端请求并向客户端返回结果，在选主过程中参与投票
Follower主要有四个功能
- 向Leader发送请求（PING消息、REQUEST消息、ACK消息、REVALIDATE消息）；
- 接收Leader消息并进行处理；
- 接收Client的请求，如果为写请求，发送给Leader进行投票；
- 返回Client结果。
Follower的消息循环处理如下几种来自Leader的消息：
- PING消息： 心跳消息；
- PROPOSAL消息：Leader发起的提案，要求Follower投票；
- COMMIT消息：服务器端最新一次提案的信息；
- UPTODATE消息：表明同步完成；
- REVALIDATE消息：根据Leader的REVALIDATE结果，关闭待revalidate的session还是允许其接受消息；
- SYNC消息：返回SYNC结果到客户端，这个消息最初由客户端发起，用来强制得到最新的更新。
- observer可以接受客户端链接，并将请求转发给leader，但是observer不参与投票过程，只同步leader的状态，observer的目的是为了扩展系统，提高读取速度
client(客户端) 请求发起者
-
Zookeeper的核心是原子广播，这个机制保证了各个Server之间的同步。实现这个机制的协议叫做Zab协议。Zab协议有两种模式，它们分别是恢复模式（选主）和广播模式（同步）。当服务启动或者在领导者崩溃后，Zab就进入了恢复模式，当领导者被选举出来，且大多数Server完成了和leader的状态同步以后 ，恢复模式就结束了。状态同步保证了leader和Server具有相同的系统状态。
-
为了保证事务的顺序一致性，zookeeper采用了递增的事务id号（zxid）来标识事务。所有的提议（proposal）都在被提出的时候加上了zxid。实现中zxid是一个64位的数字，它高32位是epoch用来标识leader关系是否改变，每次一个leader被选出来，它都会有一个新的epoch，标识当前属于那个leader的统治时期。低32位用于递增计数。
-
每个Server在工作过程中有三种状态：
LOOKING：当前Server不知道leader是谁，正在搜寻
LEADING：当前Server即为选举出来的leader
FOLLOWING：leader已经选举出来，当前Server与之同步
2.2、zookeeper的读写机制
zookeeper是一个由多个server组成的集群 一个leader，多个 follower
每个server保存一份数据的副本
全局数据一致
分布式读写
更新请求转发由leader实施
2.3、zookeeper的保证
- 更新请求顺序进行，来自同一个client的更新请求按其发送顺序依次执行
- 数据更新原子性，一次数据更新要么成功，要么失败
- 全局唯一数据视图，client无论连接到哪个server，数据视图都是一致的
- 实时性，在一定事件范围内，client能读到最新数据
2.4、Zookeeper节点数据操作流程
1、在Client向Follwer发出一个写的请求
2、Follwer把请求发送给Leader
3、Leader接收到以后开始发起投票并通知Follwer进行投票
4、Follwer把投票结果发送给Leader
5、Leader将结果汇总后如果需要写入，则开始写入同时把写入操作通知给Leader，然后commit;
6、Follwer把请求结果返回给Client
2.5、分布式锁
了解了zk的设计思想后我们开始尝试 思考为什么zookeeper可以实现分布式锁
转载。https://blog.csdn.net/xiaoxiaole0313/article/details/107011095/
首先我们要知道zk的模型是这样的：zk包含一系列的节点，叫做znode，就好像文件系统一样每个znode表示一个目录
2.5.1、znode的特性
-
有序节点：假如当前有一个父节点为
/lock，我们可以在这个父节点下面创建子节点；zookeeper提供了一个可选的有序特性，例如我们可以创建子节点“/lock/node-”并且指明有序，那么zookeeper在生成子节点时会根据当前的子节点数量自动添加整数序号
也就是说，如果是第一个创建的子节点，那么生成的子节点为
/lock/node-0000000000，下一个节点则为/lock/node-0000000001，依次类推。 -
临时节点：客户端可以建立一个临时节点，在会话结束或者会话超时后，zookeeper会自动删除该节点。
-
事件监听：在读取数据时，我们可以同时对节点设置事件监听，当节点数据或结构变化时，zookeeper会通知客户端。当前zookeeper有如下四种事件：节点创建，节点删除，节点数据修改，子节点变更
2.5.2、分布式锁落地方案
使用zk的临时节点和有序节点，每个线程获取锁就是在zk创建一个临时有序的节点，比如在/lock/目录下。
创建节点成功后，获取/lock目录下的所有临时节点，再判断当前线程创建的节点是否是所有的节点的序号最小的节点
如果当前线程创建的节点是所有节点序号最小的节点，则认为获取锁成功。
如果当前线程创建的节点不是所有节点序号最小的节点，则对节点序号的前一个节点添加一个事件监听。
比如当前线程获取到的节点序号为
/lock/003,然后所有的节点列表为[/lock/001,/lock/002,/lock/003],则对/lock/002这个节点添加一个事件监听器。
3、两种分布式锁各自的优缺点
- redis的分布式锁缺点：
- 它获取锁的方式简单粗暴，获取不到锁直接不断尝试获取锁，比较消耗性能。
- 另外来说的话，redis的设计定位决定了它的数据并不是强一致性的，在某些极端情况下，可能会出现问题。锁的模型不够健壮
- 即便使用redlock算法来实现，在某些复杂场景下，也无法保证其实现100%没有问题，关于redlock的讨论可以看How to do distributed locking
- redis分布式锁，其实需要自己不断去尝试获取锁，比较消耗性能。
- redis的分布式锁优点：
- 大部分情况下都不会遇到所谓的“极端复杂场景,并且redis的性能很高，可以支撑高并发的获取、释放锁操作。
- zk分布式锁优点:
- zookeeper天生设计定位就是分布式协调，强一致性。锁的模型健壮、简单易用、适合做分布式锁。
- 如果获取不到锁，只需要添加一个监听器就可以了，不用一直轮询，性能消耗较小。
- zk分布式锁缺点:
如果有较多的客户端频繁的申请加锁、释放锁，对于zk集群的压力会比较大。相比于redis并发会低
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
