分布式锁_snxt分布式锁-CSDN博客

本文链接：https://blog.csdn.net/qq_43619721/article/details/116485281

Java自带锁的问题

Java可以使用Synchronized或ReentrantLock实现锁，但是这只有局限于一个程序，一个电脑。

分布式锁

为了实现在分布式场景下的资源同步，我们实现分布式锁

使用场景

实现方式

数据库实现

悲观锁

SELECT ... WHERE ... FOR UPDATE就是会将数据锁住，其他的无法访问，直到这段语句被提交，锁被释放

乐观锁

就是有个对于每个数据单独来说是唯一的字段，比如version，在update提交的时候判断一下version，如果和一开始拿到的一样，就提交，否则就提交失败。实现方法一般是：

UPDATE ... WHERE id=theId AND version=oldVersion;

使用场景

一般只有冲突很容易发生的情况下采用悲观锁

唯一索引

给某个字段添加唯一索引，会让数据库在有多个请求同时提交的时候，保证只有一个能成功

缺点

这个依赖于数据库的可用性，数据库是个单点的，如果数据库坏了，就失效了
没有失效时间，如果解锁失败，就会一直锁住，其他的线程就无法访问
这个锁只能是非阻塞的，因为如果插入失败，就会报错，那其他的线程就停止，不会继续访问了
锁是非重入的，因为当前线程没有释放锁之前，无法再次获得该锁，因为数据库中数据已经存在了

解决

利用数据库的主从关系，当一个数据库坏了，马上另一个数据库变为主表
设置一个定时任务，每隔一段时间，清楚一下超时数据
设置一个while循环，一直到insert成功再结束
记录当前获得锁的线程的id，下次如果能查到该线程的id，就直接把锁给他

Redis实现

实现思想

在获取锁的时候，使用setnx设置key，如果设置成功则表示获取到了，key的val为一个UUID。再用expire设置超时时间，然后再执行业务。
准备释放锁，先get key，判断这个key 的val是不是刚才的UUID，如果是就delete，如果不是说明已经被释放并且被其他的进程修改过了。

zookeeper实现

zookeeper会创建一个目录mylock，就是一个持久节点
线程A想要获取锁，就会在mylock目录下创建一个临时顺序节点LOCK1
然后查找mylock目录下的所有子节点，如果有比LOCK1顺序靠前的，就给比仅仅比LOCK1顺序靠前一位的LOCK0注册一个WATCHER，如果没有比LOCK1靠前的，就说明LOCK1是最先的，就获取锁
以此类推，线程B创建LOCK2，给LOCK1注册WATCHER。
线程A处理完，删除自己的LOCK1，触发了线程B的WATCHER，线程B再判断自己是不是第一顺位，再获取锁。

这里说的watcher，我看人家说是之前的线程解锁的时候，通知这个watcher，这样子挺好，不浪费资源，还快速。

服务器故障检测

每隔一段时间，客户端会ping一下服务器，告诉服务器我还活着，服务器就会刷新客户端的存活时间。超过一段时间没有接收到客户端的请求，就会清理，清理的时候会将临时会话节点删除，包括临时顺序节点，保证了不会因为客户端有问题而导致死锁

数据一致性

zookeeper服务器由一个leader节点和几个follower节点组成，读写在leader上进行。
当一个写请求过来，leader节点发起一个proposal，当大部分的follower返回ACK，leader节点再发起任务，当大部分follower都commit了，leader才会返回给客户端成功。
如果leader挂了，zookeeper的leader选举算法采用zab协议，保证数据最新的follower成为新的leader，所以新的leader会有原来leader上提交的所有数据，保证了数据一致性。

比较

数据库

缺点：

性能差，并且有锁表的风险
非阻塞操作失败后，需要用while循环，浪费CPU资源
如果长时间不commit或长时间轮询，可能会连接很多个，浪费资源

Redis

缺点：

锁删除失败的话，过期时间不好控制
非阻塞操作失败后，需要用while循环，浪费CPU资源

zookeeper

缺点：
性能不如Redis，因为写操作（获取锁和释放锁）都要在leader上进行，然后再同步给follower

性能： Redis > zookeeper >= 数据库
可靠性：zookeeper > Redis > 数据库

CAP原则

一致性Consistency, 可用性Availability, 分区容错性Partion tolerance
这三个原则最多只能同时实现两点，不能同时兼顾

解释

一致性C：
在分布式系统中的所有备份数据，是否在同一时刻都一样。（就是说每个节点能同时访问最新的数据）
可用性A：
在集群中有一部分故障后，剩余节点是否能继续响应客户端的请求，让客户端访问到想访问的数据
分区容错性P：
当发生了某些故障，有些节点之间不连通了，整个节点网络就分成了几块区域，数据分散在了这几个区域中，这就是分区。
发生了分区后，那么与某个节点不连通的部分就无法访问到这个节点的数据。
如果该数据只保存在一个节点中，那么该数据就无法访问，这是无法容忍的，分区容错性就低。
如果要解决就可以将一个数据复制在多个节点上，那么分区问题出现后，该数据可能分布在各个区域中，这就是可容忍的，分区容错性就高。

而为了将数据复制到多个节点上，就会有一致性的问题，多个节点的数据可能不一致。
而如果还要保证一致性，那么就会有可用性的问题，就是要等待数据的同步，期间导致服务不可用。
综上就是CAP只能同时实现两点。

通常实现

通过分布式缓存中各节点的最终一致性来提高系统性能。使用数据异步复制技术来实现一致性，提高了性能。
通常使用类似memcached的nosql来实现。
虽然memcached可以分布式化，但是每一份数据是存储在一个memcached服务器上，如果这台服务器故障，那么这部分的数据将不会被访问到，就是分区容错性很低。而且数据是存储在内存中，重启会导致数据丢失。

BASE

BASE是Basically Available（基本可用）、Soft state（软状态）和Eventually consistent（最终一致性）三个短语的简写。
核心思想是无法做到强一致性（Strong consistency），但是可以做到最终一致性（Eventually consistency），换取效率。