Redis系列四 锁

来都来了 2020-11-25 16:07:08 ⋅ 1237 阅读

 

本文目标

1. 熟悉乐观锁ABA概念
2. 理解掌握redis事务以及watch回滚;
3. 实战redis锁


乐观锁

乐观锁是一种不会阻塞其他线程并发的机制,它不会使用数据库的锁进行实现,它的设计里面由于不阻塞其他线程,所以并不会引发线程频繁挂起和恢复,这样便能够提高并发能力,所以也有人把它称为非阻塞锁,那么它的机制是怎么样的呢?

CAS 原理概述

在 CAS 原理中,对于多个线程共同的资源,先保存一个旧值(Old Value),比如进入线程后,查询当前存量为 100 个红包,那么先把旧值保存为 100,然后经过一定的逻辑处理。

当需要扣减红包的时候,先比较数据库当前的值和旧值是否一致,如果一致则进行扣减红包的操作,否则就认为它已经被其他线程修改过了,不再进行操作,CAS 原理流程如图 1 所示。

CAS 原理并不排斥并发,也不独占资源,只是在线程开始阶段就读入线程共享数据,保存为旧值。当处理完逻辑,需要更新数据的时候,会进行一次比较,即比较各个线程当前共享的数据是否和旧值保持一致。

如果一致,就开始更新数据;如果不一致,则认为该数据已经被其他线程修改了,那么就不再更新数据,可以考虑重试或者放弃。有时候可以重试,这样就是一个可重入锁,但是 CAS 原理会有一个问题,那就是 ABA 问题,下面先来讨论一下 ABA 问题。

ABA 问题

对于乐观锁而言,我们之前讨论了存在 ABA 的问题,那么什么是 ABA 问题呢?下面看看表 1 的两个线程发生的场景。

时 刻 线程1 线程2 备 注
T0 —— —— 初始化 X=A
T1 读入X=A —— ——
T2 —— 读入X=A ——
T3 处理线程 1 的业务逻辑 X=B 修改共享变量为 B
T4 处理线程 1 的业务逻辑 处理线程 2 业务逻辑第一段 此时线程1在 X=B 的情况下运行逻辑
T5 处理线程 1 的业务逻辑 X=A 还原变量为 A
T6 因为判断 X=A,所以更新数据 处理线程 2 业务逻辑第二段 此时线程 1 无法知道线程 2 是否修改过 X,引发业务逻辑错误
T7 —— 更新数据 ——

在 T3 时刻,由于线程 2 修改了 X=B,此时线程 1 的业务逻辑依旧执行,但是到了 T5 时刻,线程 2 又把 X 还原为 A,那么到了 T6 时刻,使用 CAS 原理的旧值判断,线程 1 就会认为 X 值没有被修改过,于是执行了更新。

我们难以判定的是在 T4 时刻,线程 1 在 X=B 的时候,对于线程 1 的业务逻辑是否正确的问题

由于 X 在线程 2 中的值改变的过程为 A->B->A,才引发这样的问题,因此人们形象地把这类问题称为 ABA 问题。

ABA 问题的发生,是因为业务逻辑存在回退的可能性。如果加入一个非业务逻辑的属性,比如在一个数据中加入版本号(version),对于版本号有一个约定,就是只要修改 X 变量的数据,强制版本号(version)只能递增,而不会回退,即使是其他业务数据回退,它也会递增,那么 ABA 问题就解决了,如表 2 所示。

表 2 用版本号消除 ABA 问题

时刻 线程1 线程2 备 注
T0 —— —— 初始化 X=A,version=0
T1 读入X=A —— 线程1旧值:version=0
T2 —— 读入X=A 线程2旧值:version=0
T3 处理线程1的业务逻辑 X=B 修改共享变量为 B,version=1
T4 处理线程1的业务逻辑 处理线程 2 业务逻辑第一段 ——
T5 —— X=A 还原变量为A,version=2
T6 判断 version == 0,由于线程 2 两次更新数据,导致数据 version=2,所以不再更新数据 处理线程 2 业务逻辑第二段 此时线程 1 知道旧值 version 和当前 version 不一致,将不更新数据
T7 —— 更新数据 ——

只是这个 version 变量并不存在什么业务逻辑,只是为了记录更新次数,只能递增,帮助我们克服 ABA 问题罢了,有了这些理论,我们就可以开始使用乐观锁来完成抢红包业务了。

redis 事务

在 Redis 中,存在多个客户端同时向 Redis 系统发送命令的并发可能性,因此同一个数据,可能在不同的时刻被不同的线程所操纵,这样就出现了并发下的数据一致的问题。为了保证异性数据的安全性,Redis 为提供了事务方案。而 Redis 的事务是使用 MULTI-EXEC 的命令组合,使用它可以提供两个重要的保证:

  1. 事务是一个被隔离的操作,事务中的方法都会被 Redis 进行序列化并按顺序执行,事务在执行的过程中不会被其他客户端发生的命令所打断。
  2. 事务是一个原子性的操作,它要么全部执行,要么就什么都不执行。

Redis 通过MULTI 、EXEC、WATCH等命令来实现事务功能。事物提供了一种将多个命令请求打包,然后一次性、按顺序的执行多个命令的机制,并且在事物执行期间,服务器不会中断事务而去执行其他客户端的命令请求,它会将事物中所有的命令都执行完毕。

流程

  1. 开启事务
  2. 命令进入队列
  3. 执行事务。

Redis事物不支持回滚操作,所以事物队列中某个命令执行错误,整个事物也会继续执行下去。

# 开启事务
127.0.0.1:6379> MULTI
OK
# 入队
127.0.0.1:6379> set key1 v1
QUEUED
127.0.0.1:6379> INCR key1
QUEUED
127.0.0.1:6379> set key2 v2
QUEUED
127.0.0.1:6379> set key1 v3
QUEUED
# 执行
127.0.0.1:6379> EXEC
1) OK
# INCR 失败
2) (error) ERR value is not an integer or out of range
3) OK
4) OK
# key1 变为最后的v3
127.0.0.1:6379> GET key1
"v3"
# key2 set 成功
127.0.0.1:6379> GET key2
"v2"
 

watch

watch 命令可以决定事务是执行还是回滚,可以在 multi 命令之前使用 watch 命令监控某些键值对,然后使用 multi 命令开启事务,执行各类对数据结构进行操作的命令,这个时候这些命令就会进入队列。

如下图,在执行之前,更改了version的值,导致事务回滚,

是否可以避免 ABA 问题呢?如下图:

Redis 的机制是不会产生 ABA 问题的,这样就有利于在保证数据一致的基础上,提高高并发系统的数据读/写性能。

分布式锁

分布式锁的实现,目前常用的方案有以下三类:

  1. 数据库乐观锁;
  2. 基于分布式缓存实现的锁服务,典型代表有 Redis 和基于 Redis 的 RedLock;
  3. 基于分布式一致性算法实现的锁服务,典型代表有 ZooKeeper、Chubby 和 ETCD。

为了确保锁服务可用,通常,分布式锁需同时满足以下四个约束条件。

  1. 互斥性:在任意时刻,只有一个客户端能持有锁;
  2. 安全性:即不会形成死锁,当一个客户端在持有锁的期间崩溃而没有主动解锁的情况下,其持有的锁也能够被正确释放,并保证后续其它客户端能加锁;
  3. 可用性:就 Redis 而言,当提供锁服务的 Redis Master 节点发生宕机等不可恢复性故障时,Slave 节点能够升主并继续提供服务,支持客户端加锁和解锁;对基于分布式一致性算法实现的锁服务(如 ETCD)而言,当 Leader 节点宕机时,Follow 节点能够选举出新的 Leader 继续提供锁服务;
  4. 对称性:对于任意一个锁,其加锁和解锁必须是同一个客户端,即客户端 A 不能把客户端 B 加的锁给解了。

代码部分

上锁部分,

/**
* 上锁🔒
* @param lockName 锁名字
* @param randomVale 随机值, 为解锁是校验持有者
* @param expireTime 过期时间,单位秒, 过期后自动删除
* !保证上锁的安全--一条命令保证安全性
*/
public async lock(lockName: string, randomVale: string, expire: number) {
const start = Date.now();
const self = this;

return (async function intranetLock(this: any): Promise<any> {
try {
// 核心代码
//* 1. 如果key不存在,则设置key-value, 且value的唯一性,保证删除的时候同样可以校验
// * 2. 如果key存在,NX 保证不做任何操作
const result = await self.redis.set(lockName, randomVale, self.expiryMode, expire | self.lockLeaseTime, self.setMode);
// 上锁成功
if (result === 'OK') {
console.log(`${lockName} ${randomVale} 上锁成功`);
return true;
}
// 锁超时
if (Math.floor((Date.now() - start) / 1000) > self.lockTimeout) {
console.log(`${lockName} ${randomVale} 上锁重试超时结束`);
return false;
}
// 循环等待重试
console.log(`${lockName} ${randomVale} 等待重试`);
await sleep(3);
console.log(`${lockName} ${randomVale} 开始重试`);
return intranetLock();
} catch (err) {
throw new Error(err);
}
})();

}
 

解锁部分

/**
* 解锁
*/
public async unLock(lockName: string, randomValue: string) {
try {
// Watch 命令监控锁。监控锁对应的 key(lockName),事务开启后,如果其它的客户端对这个 Key 进行了更改,
// 那么本次事务会被取消而不会执行 redis.watch(lockName)。
await this.redis.watch(lockName);
const value = await this.redis.get(lockName);
// 如果获取到🔒对应的值,与 randomValue 相等
if (randomValue === value) {
// 开启事务,删除锁🔒
const result = await this.redis.multi().del(lockName).exec();
if (DistributedLock.RELEASE_SUCCESS === result.length) {
console.log('解锁成功');
return true;
}
} else {
console.log('value 不相等,解锁失败');
}
} catch (error) {
console.log('解锁error', error);

}
}
 

返回值

➜  5锁 git:(main) ✗ ts-node index.ts
name1 b9ccabe0-2ec7-11eb-b965-933ad584a1de 上锁成功
name1 b9cdbd50-2ec7-11eb-b965-933ad584a1de 等待重试
name1 b9cdbd50-2ec7-11eb-b965-933ad584a1de 开始重试
name1 b9cdbd50-2ec7-11eb-b965-933ad584a1de 等待重试
解锁成功
unLock: name1 b9ccabe0-2ec7-11eb-b965-933ad584a1de true
name1 b9cdbd50-2ec7-11eb-b965-933ad584a1de 开始重试
name1 b9cdbd50-2ec7-11eb-b965-933ad584a1de 上锁成功
解锁成功
unLock: name1 b9cdbd50-2ec7-11eb-b965-933ad584a1de true
 

具体的实例代码:https://github.com/simuty/Integration/blob/main/Redis/

参考链接

Redis乐观锁解决高并发抢红包的问题


全部评论: 0

    我有话说:

    Redis系列 GEO附近的人

    分成4个部分。 我们先将平面切割成个正方形,然...

    Martian框架发布 3.0.3 版本,Redis分布式

    项目简介 Martian 是一个声明式 API 编程(DAP)框架,可以帮助你快速开发后端服务。 以HttpServer作为 http服务,彻底脱离Tomcat这一类的Web容器和Servlet,同时也让项目减少了几个依赖 声明式API,让Co...

    Redis系列六 Lua

      本文目标 学习lua基本语法 能够采用redis+lua lua 基本语法 Lua 是一种轻量小巧的脚本语言,用标准C语言编写并以源代码形式开放, 其设计目的是为了嵌入应用

    Redis系列七 Debug Lua

      调试redis+lua 学了lua的基本语法,了解了redis+lua的配套用法,但是却不知道怎么断点调试。学就学全面点, 官网中有dubug相关说明。地址:Redis Lua

    Redis系列一 基本用法&应用场景

        说明 redis的最基本使用方法以及使用场景。 字符串 // stringasync function stringFun() { const [key

    Redis系列八 抢红包

      本文概述 掌握红包的两种常见生成算法 掌握lua+redis 实现原子性抢红包 项目中还有mysql相关内容 了解jmeter的基本用法 遗留问题 redis同步DB时机问题

    Redis系列二:位图实战,实现打卡签到

    前言 如果要统计一篇文章的阅读量,可以直接使用 Redis 的 incr 指令来完成。 如果要求阅读量必须按用户去重,那就可以使用 set 来记录阅读了这篇文章的所有用户 id,获取

    Redis系列九 推荐系统-布隆过滤器

      布隆过滤器 概念 布隆过滤器是一种空间利用率较高的概率型数据结构,用来测试一个元素是否在集合中。但是存在一定可能,导致结果误判。当布隆过滤器说某个值存在时,这个值可能不存在;当它说不存在时,那就肯定不存在. 特性: 与哈希表不同,...

    为什么单线程的Redis能够达到百万级的QPS?

    作者:在江湖中coding链接:https://juejin.im/post/5e6097846fb9a07c9f3fe744 性能测试报告 查看了下阿里云 Redis 的性能测试报告如下,能够

    Redisson 3.13.6 发布,官方推荐的 Redis 客户端

    Redisson 3.13.6 已发布,这是一个 Java 编写的 Redis 客户端,具备驻内存数据网格(In-Memory Data Grid)功能,并获得了 Redis 的官方推荐

    Redis多线程演进

    Redis作为一个基于内存的缓存系统,一直以高性能著称,因没有上下文切换以及无操作,即使在单线程处理情况下,读速度仍可达到11万次/s,写速度达到8.1万次/s。但是,单线程的设计也给Redis

    商城系统 DBShop V3.0 Beta 发布

    全新重构,首次亮相。 系统简介 DBShop企业级商城系统,使用PHP语言基于Laminas(Zendframework 3) + Doctrine 2 组合框架开发完成。可定制、多终端、多场景、多

    BAT大牛Redis客户端与服务端交互原理

    Redis实例运行在单独的进程中,应用系统Redis客户端)通过Redis协议和Redis Server

    京东技术:如何实现靠谱的分布式?(附SharkLock的设计选择)

    分布式,是用来控制分布式系统中互斥访问共享资源的一种手段,从而避免并行导致的结果不可控。

    Redis 5.0.11、6.0.11、6.2 发布,修复 32 位系统上的整数溢出

    Redis 同时发布了 5.0.11、6.0.11 和 6.2 版本。对于使用 32 位 Redis 的用户来说,此次更新解决了一个重要的安全问题,即 32 位系统上的整数溢出((CVE-2021

    「基本功」不可不说的Java“”事

    并发编程是Java程序员必备基本功,今天“基本功”专栏向大家推荐一篇深入解析Java机制的文章。Enjoy! 前言 Java提供了种类丰富的,每种因其特性的不同,在适当的场景下能够展现出非常高

    Node&RabbitMQ系列 X场景解构

    目标 先设想购票的场景:用户注册成功后,三天内未登陆,则短信提醒。 三段式场景: A-B-C可以延伸至: 发起购票—>时间+未付款—>短信提醒⏰、取消订单 发起退款—>时间+未处理—>通知相关人员⏰ 总的来说,满足A...