分布式锁详解（数据库、Redis实现）

最新推荐文章于 2022-12-05 23:32:58 发布

人生苦短，及时编码

最新推荐文章于 2022-12-05 23:32:58 发布

阅读量245

点赞数 1

分类专栏：分布式文章标签： java

本文链接：https://blog.csdn.net/ProgrammerChe/article/details/118148197

版权

分布式专栏收录该内容

1 篇文章 0 订阅

订阅专栏

分布式CAP理论

什么是CAP？

CAP原则又称为CAP理论。主要思想为任意分布式系统都无法同时满足CAP。

C代表Consistency（一致性）：所有节点在同一时间看到的数据是一样的。

Available（可用性）：请求就一定能接收到响应。

Partion Tolerance（分区容错性）：系统任意分区后，网络不稳定或异常情况下仍能操作。

CAP之间的取舍

CA（without P）

保证一致性和可用性，不允许分区。但其实分区会始终存在，因此CA的系统基本都是允许分区后各个子系统保证了CA。

常见例子：单站点数据库，集群数据库等。

CP（without A）

保证了一致性和分区容错性，牺牲可用性。CP可保证一致性和分区容错性，但会因为牺牲可用性导致同步数据时间无限延长，直到同步数据完成后才能正常使用。很多传统的数据库分布式事务都是属于这个模式。

常见例子：分布式数据库，分布式锁等。

AP（without C）

保证了可用性和分区容错性，牺牲一致性。一旦分区发生，节点之间可能失去联系，每个节点只能提供当前本地数据的服务，导致全局数据出现不一致。现在很多NOSQL都属于这种模式。

常见例子：Web缓存，NOSQL等。

CAP总结

在系统架构时，应该根据具体的业务场景来权衡CAP，就拿大多数的门户网站来说，因为机器数量庞大，部署节点分散，网络故障时常态，可用性是必须要保证的，所以在设计的时候就会考虑舍弃一些一致性而选择AP模型。但是对于数据一致性较高的银行系统来说，可以用于系统临时不可用，但是数据必须要保持一致来说，选择CP模型无可厚非。

什么是分布式锁？

分布式锁是用来控制分布式系统之间进行同步访问共享资源的一种方式。在分布式系统中，常常需要协调他们的动作。如果不同的系统或是同一个系统的不同主机之间共享了一个或一组资源，那么访问这些资源的时候，往往需要互斥来防止彼此干扰来保证一致性，这个时候，便需要使用到分布式锁。

为什么需要分布式锁？

目前基本上大型网站都是基于分布式进行部署的，而对于分布式场景中的数据一致性一直都是一个较为火热的话题，在很多情况下我们为了保证数据的最终一致性，则需要很多技术方案来执行，比如分布式事务、分布式锁等。分布式与单机最大的不同不是多线程，而是多进程。在分布式模型下，我们需要通过锁来控制在某一时刻修改数据的进程数。

分布式锁需要具备的条件？

在分布式系统环境下，一个方法在同一时间只能被一个机器的一个线程执行；
高可用的获取锁与释放锁；
高性能的获取锁与释放锁；
具备可重入特性；
具备锁失效机制，防止死锁；
具备非阻塞锁特性，即没有获取到锁将直接返回获取锁失败。

分布式锁实现方式

数据库实现

基于乐观锁

基于表主键唯一性实现

DROP TABLE IF EXISTS `table_lock`
CREATE TABLE `table_lock`(
    `lock_id` int(10) unsigned NOT NULL AUTO_INCREMENT COMMENT '主键id',
    `lock_method` varchar(255) NOT NULL COMMENT '获取锁的方法',
    `description` varchar(255) NOT NULL DEFAULT '方法备注信息',
    `update_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '保存数据时间',
    PRIMARY KEY (`lock_id`),
    UNIQUE KEY `my_lock_method` (`lock_method`) USING BTREE
) ENGINE=InnoDB DEFAULT CHARSET=UTF8

当请求时向表table_lock中插入数据：

insert into table_lock(lock_method,description) values('method','methodDescription');
//method代表当前发出请求时的方法名称。
//methodDescription代表需要对于当前方法名称添加的备注信息。

当基于分布式系统的发送多个请求提交到数据库时，数据库通过方法名唯一性约束可保证只有一个操作成功插入，而对于成功插入数据的这个请求也称其获得了锁，当方法执行完毕后，通过删除插入的数据完成释放锁。

通过以上的简单方法实现分布式锁有以下问题：

锁强依赖数据库的可用性，如果当前数据库属于单点数据库，一旦宕机会导致系统服务不可用。
锁没有失效时间，一旦当前进程的线程解锁操作失败，数据库就一直存在当前记录，其他进程也无法再使用当前方法获取锁。
锁为非阻塞性的，当前进程插入失败则直接报错，需要再次出发获取锁的操作。
锁为非重用性，当前线程未释放锁之前无法在获取该锁。
锁为非公平锁，所有等待锁的线程都是凭运气争夺锁。
采用主键冲突防重，大并发情况下可能会导致锁表现象。

针对于出现问题的解决方法：

单点问题—避免单点宕机，使用多个数据库，数据进行双向同步，一旦宕机则切换另一个库。
失效时间问题—设置一个定时任务，每隔一段时间清理一次超时的数据。
非阻塞型问题—使用while循环当插入失败后重试直到成功。
非重用性问题—数据库表添加operation_info（保存获取锁的当前机器的主机信息和线程信息），下次需要获取锁的时候先查询数据库，匹配当前operation_ino的内容成功后直接分配锁。
非公平问题—建一张中间表，将等待锁的线程信息保存下来，当前一个线程释放锁后将锁根据时间排序分配锁。
主键冲突防重问题—在程序中生产主键进行防重。

基于表字段版本号（version）实现

这个策略源于 mysql 的 mvcc 机制，这个策略唯一的问题就是对数据表侵入较大，我们要为每个表设计一个版本号字段，然后写一条判断 sql 每次进行判断，增加了数据库操作的次数，在高并发的要求下，对数据库连接的开销也是无法忍受的。

DROP TABLE IF EXISTS `user`
CREATE TABLE `user`(
    `id` int(10) unsigned NOT NULL AUTO_INCREMENT COMMENT '主键id',
    `username` varchar(255) NOT NULL COMMENT '获取锁的方法',
    `truename` varchar(255) NOT NULL DEFAULT '方法备注信息',
    `reversion` int(10) NOT NULL DEFAULT 1 COMMENT '乐观锁版本号'
    PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=UTF8

获取锁信息

select id,username,truename,version from user;
//结果: 
id  username  truename version
1  zhangzhang zhangsan    1

占有锁

update user set truename = 'zhangzhang' where reversion= #{reversion}
//当前reversion是上一个查询出来的reversion值作为条件进行更新,更新失败则表示在你的操作过程中,有人已经修改过当前数据值

该方法实现分布式锁出现问题和解决方法同基于数据库主键唯一情况相同。

基于悲观锁

排他锁实现

for update是作用于数据库行级的排他锁，当一个事务的操作未完成之前，其他事务只能读取无法写入。查询语句后加上for update，数据库会在查询过程中给数据库加上排他锁，当前线程增加排他锁后其他线程就无法在该条记录上再加排他锁。

select * from user where id = 1 for update;

我们可以认为获得排他锁的线程即可获得分布式锁，当获取到锁之后，可以执行方法的业务逻辑，执行完方法之后，通过connection.commit()操作来释放锁。

这种方法可以有效的解决上面提到的无法释放锁和阻塞锁的问题。

阻塞锁？ for update语句会在执行成功后立即返回，在执行失败时一直处于阻塞状态，直到成功。
锁定之后服务宕机，无法释放？使用这种方式，服务宕机之后数据库会自己把锁释放掉。

优点：简单，便于理解

缺点：

排他锁还是无法解决数据库单点问题和可重入问题。
字段名使用唯一索引 + for update，MySQL会对查询进行优化，即便在条件中使用了索引字段，但是否使用索引来检索数据是由 MySQL 通过判断不同执行计划的代价来决定的，如果 MySQL 认为全表扫效率更高，比如对一些很小的表，它就不会使用索引，这种情况下 InnoDB 将使用表锁，而不是行锁。
使用排他锁进行分布式锁的lock，如果当前线程长时间不提交，就会一直占用数据库连接，一旦这种情况过多，就会导致连接池爆满。

Redis实现

为什么要选用Redis实现分布式锁？

Redis是基于内存的高性能数据库
Redis命令特性支持，实现较为方便

命令详解

SETNX

语法：SETNX key val

内容：当且仅当key不存在时，set一个key为val的字符串，返回1；若key存在，则什么都不做，返回0。

EXPIRE

语法：EXPIRE key timeout

内容：为key设置一个超时时间，超过设置时间后当前key自动删除。

DELETE

语法：DELETE key

内容：删除key

实现思想

获取锁的时候，使用setnx加锁，并使用expire命令为锁添加一个超时时间，超过该时间则自动释放锁，锁的value值为一个随机生成的UUID，通过此在释放锁的时候进行判断。
获取锁的时候还设置一个获取的超时时间，若超过这个时间则放弃获取锁。
释放锁的时候，通过UUID判断是不是该锁，若是该锁，则执行delete进行锁释放。

人生苦短，及时编码

关注

1
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
分布式锁详解（数据库、Redis实现）

分布式CAP理论什么是CAP？ CAP原则又称为CAP理论。主要思想为任意分布式系统都无法同时满足CAP。C代表Consistency（一致性）：所有节点在同一时间看到的数据是一样的。Available（可用性）：请求就一定能接收到响应。Partion Tolerance（分区容错性）：系统任意分区后，网络不稳定或异常情况下仍能操作。CAP之间的取舍CA（without P）保证一致性和可用性，不允...
复制链接

扫一扫