Redis如何保证并发访问时的数据正确性

最新推荐文章于 2024-04-24 17:58:21 发布

后端工程狮

最新推荐文章于 2024-04-24 17:58:21 发布

阅读量594

点赞数

分类专栏： redis学习 java知识文章标签： redis lua 数据库

本文链接：https://blog.csdn.net/qq_49662572/article/details/129108415

版权

java知识同时被 2 个专栏收录

3 篇文章 0 订阅

订阅专栏

redis学习

2 篇文章 0 订阅

订阅专栏

背景

在使用Redis时不可避免地会遇到并发访问的问题，比如多个用户同时下单，就会对缓存中的商品库存数据进行并发更新。一旦有了并发写操作，数据就会被修改，如果没有做好并发控制，就会导致数据被修改错误，影响到业务的正常使用。（例如秒杀场景下的超卖情况） （即并发修改Redis中的数据）

 为了保证并发访问(并发修改数据）的正确性，Redis提供了两个方法，分别是加锁和原子操作。

原子操作：是指执行过程中保持原子性的操作，而且原子操作执行时并不需要再加锁，实现了无锁操作。这样既保证了并发控制，还能减少对系统并发性能的影响。（在原子操作执行过程中，不会有其他Redis命令被执行）

Redis加锁会有两个问题，一方面是加锁操作多，会降低系统的并发访问性能。另一方面Redis客户端加锁时，需要用到分布式锁，而这需要额外的存储系统来提供加解锁的操作。

原子操作

并发控制针对的操作范围主要是数据修改操作。当有多个客户端对同一份数据执行RMW（Read-Modify-Write）操作时，我们就需要RMW操作涉及的代码以原子性方式执行。访问同一份数据的RMW操作代码，就叫做临界区代码，并且同一时间只会有一个客户端的临界区代码会被执行。RMW操作即是指客户端要对数据做修改操作时所需要执行的步骤，即要先读取Redis中的内存数据到客户端中，然后根据读取到的数据判断是否要修改，然后在本地修改，最后写入到Redis服务中。而这部分操作就是指临界区的操作逻辑了。

Redis 的两种原子操作方法

 为了实现并发控制要求的临界区代码互斥执行。Redis的原子操作采用了两种方法：

把多个操作封装成Redis中的一条命令，也就是单命令操作；
把多个操作写到一个Lua脚本中，以原子性方式执行单个Lua脚本。

单命令操作（用的少）

虽然Redis的单个命令可以原子性执行（Redis是单线程执行的，同一时间最多只有一条Redis命令被执行），但实际操作中数据修改包含了多个命令的操作，包括数据读取、数据增减、写回数据三个操作。

这种情况就需要使用Redis提供的单命令操作了。例如INCR/DECR命令就可以实现数据的增减操作，而且因为它们本身就是单个命令操作（这两个命令它里面就做到了读取当前数据，当前数据+1，然后写到Redis中），所以在执行它们时，就保证了它们的互斥性。

Lua脚本

如果只是简单的增减操作，那么就可以使用单命令保证其原子性了。但是可能会有更复杂的判断逻辑或者其它操作，那么就需要通过封装多个命令在Lua脚本执行操作了。(它是把一批Redis命令封装到一个脚本中，然后由Redis当做一条命令去执行的。Redis命令是单线程执行的（同一时间最多执行一个命令，其他命令将被阻塞直到当前命令执行完成）（而LUA脚本能够把多条Redis命令整合成一个单命令去执行）故他能保证在执行当前LUA脚本期间，其它客户端或者本客户端发送的其他命令或者LUA脚本将被阻塞，直到当前LUA脚本被执行完，这样在LUA脚本执行期间，就不会出现并发修改当前数据的问题）

Redis 会把整个 Lua 脚本作为一个整体执行，在LUA脚本执行的过程中不会被其他命令打断，Redis也不会去执行其他的命令，从而保证了 Lua 脚本中操作的原子性。但是如果把很多操作都放在 Lua 脚本中原子执行，会导致 Redis 执行脚本的时间增加，同样也会降低 Redis 的并发性能。所以在编写Lua脚本时需要避免把不需要做并发控制的操作写入脚本中。

LUA脚本的简介

Redis从2.6.0版本开始提供了eval命令，通过内置的Lua解释器，可以让用户执行一段Lua脚本并返回数据。因为Redis单线程模型的特点，可以保证多个命令的原子性.

LUA脚本的原子执行

Lua脚本在Redis中是以原子方式执行的，在Redis服务器执行EVAL命令时，在命令执行完毕并向调用者返回结果之前，只会执行当前命令指定的Lua脚本包含的所有逻辑，其它客户端发送的命令将被阻塞，直到EVAL命令执行完毕为止。因此LUA脚本不宜编写一些过于复杂了逻辑，必须尽量保证Lua脚本的效率，否则会影响其它客户端。

Redis命令是单线程执行的（同一时间最多执行一个命令，其他命令将被阻塞直到当前命令执行完成）（而LUA脚本能够把多条Redis命令整合成一个单命令去执行）故他能保证在执行当前LUA脚本期间，其它客户端或者本客户端发送的其他命令或者LUA脚本将被阻塞，直到当前LUA脚本被执行完，那么意味着这个LUA脚本执行期间能做到（Read-Modify-Write）（取出数据，根据数据判断是否修改数据，再写入数据）不会有间隙问题（不可能在当前LUA脚本执行期间，lua脚本取出指定数据时，指定数据被其他命令修改的情况，LUA脚本中取出的数据就是最新的数据），LUA脚本执行期间不可能会有其他Redis命令能够去执行（也就不可能出现并发修改数据的问题）

Redis Lua脚本执行遇到异常时，已经执行过的逻辑是不会回滚的

使用lua脚本的好处

lua脚本是作为一个整体执行的.所以中间不会被其他命令插入
可以把多条命令一次性打包,所以可以有效减少网络开销;
lua脚本可以常驻在redis内存中,所以在使用的时候,可以直接拿来复用.也减少了代码量

分布式加锁

在应对并发问题时，除了原子操作，Redis客户端可采用加锁的方法，来控制并发写操作对共享数据的修改，从而保证数据的正确性。（其实就是修改同一份数据前，所有的客户端先去抢占锁，抢占到锁的客户端才能去执行Redis命令修改当前的数据（去做（Read-Modify-Write）操作），其他客户端就阻塞等待直到抢占到锁才去做（Read-Modify-Write）操作或者直接放弃）

当有多个客户端需要争抢锁时，需要保证的是这把锁不能是某个客户端本地的锁。否则的话，其它客户端的是无法访问到这把锁的，更不要说是获取锁了。所以在分布式系统中，当有多个客户端需要获取锁时，需要使用分布式锁。此时锁是保存在共享存储系统中的，可以被多个客户端共享访问和获取。

而Redis正好可以被多个客户端共享访问，可以保存分布式锁。

加锁操作和释放锁的操作就是针对锁的键值进行读取、判断、设置的过程。

加锁时根据锁变量值判断是否可以加锁，如果可以则对锁变量值进行修改，表示持有锁；
释放锁时同样需要进行判断，因为需要判断当前加锁的是不是该客户端，如果不判断直接释放锁的话，会被其它客户端将持有的锁给释放掉了；如果可以释放锁，则重置锁变量的值；

这样一来，因为加锁释放锁涉及了多个操作，所以实现分布式锁时需要两个保证：

锁操作的原子性；
分布式锁的可靠性；

锁操作的原子性

锁操作（加锁和释放锁的操作）的原子性可以采用上面提到的单命令操作和Lua脚本操作。

单命令操作和Lua脚本

使用 SETNX 和 DEL命令即可实现加锁和释放锁的操作。SETNX命令表示在执行时会判断键值对是否存在，如果不存在，就设置键值对的值，如果存在，就不做任何设置。

SETNX key value

释放锁时直接将锁删除掉即可。

但进行操作时需要注意两个问题：

一是锁的过期时间设置；在加锁后，如果后面的逻辑发生了异常导致没有释放锁，这时就需要过期时间去保证该客户端不能一直持有锁。
还有一个是需要区别不同客户端的释放锁操作；这可以让每个客户端加锁时设置唯一值；（客户端只能释放自己的加的锁，不能释放别人的锁，这种情况可能发生在当前客户端的锁自动过期后，客户端再去主动释放锁）

锁过期时间的设置和释放锁的操作都需要保证原子性；这里使用SET命令的NX选项和Lua脚本保证了。

SET KEY VALUE [EX seconds | PX milliseconds] [NX]

即SET lock_key unique_value NX PX 10000 表示给lock_key这个键设置unique_value值，同时设置过期时间为10000ms。

释放锁也包含了读取锁变量值、判断锁变量值和删除锁变量三个操作，不过，我们无法使用单个命令来实现，所以，我们可以采用 Lua 脚本执行释放锁操作，通过 Redis 原子性地执行 Lua 脚本，来保证释放锁操作的原子性。

释放锁时的Lua脚本：（重要）

//释放锁 比较unique_value是否相等，避免误释放，客户端只能释放自己的锁
if redis.call("get",KEYS[1]) == ARGV[1] then
    return redis.call("del",KEYS[1])
else
    return 0
end

redis-cli  --eval  unlock.script lock_key , unique_value

分布式锁的可靠性

为了避免锁实例出现故障而导致的锁无法工作的问题，需要按照一定的步骤和规定。Redis 的开发者 Antirez 提出了分布式锁算法 Redlock。

RedLock的基本思路是，是让客户端和多个独立的Redis实例依次请求加锁，如果客户端能够与半数以上的实例成功地完成加锁操作，那么就认为客户端获得了分布式锁。这样一来，即使有某个Redis实例发生故障，那么也有其它实例可以做锁操作的支撑。

RedLock算法实现的三个步骤

RedLock算法实现的可以分为3个步骤，假设需要有N个独立的Redis实例：

1 客户端获取当前时间；

2 客户端按顺序依次向N个Redis实例执行加锁操作；

向Redis实例请求加锁，一样是采用SET NX 原子操作的命令，为了保障在加锁过程中Redis故障了，需要给加锁操作设置一个超时时间。如果超时了，那么会去下一个Redis实例继续请求加锁。

加锁操作的超时时间需要远远小于锁的有效时间，一般也是设置几十毫秒。

3一旦客户端完成了和所有Redis实例的加锁操作，客户端计算整个加锁过程的总耗时。

客户端需要满足以下两个条件才能认为是加锁成功：

客户端从超过半数（大于等于N/2 + 1)的Redis实例上成功获取到了锁；

客户端获取锁的总耗时没有超过锁的有效时间。

在满足加锁成功的条件后，需要重新计算锁的有效时间，计算结果是锁的最初有效时间减去客户端为获取锁的总耗时。如果锁的有效时间已经来不及完成共享数据的操作了，那么就需要释放锁，以免出现还没完成数据操作，锁就过期的情况（这个有一个阈值，很小）。

后端工程狮

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
Redis如何保证并发访问时的数据正确性

在应对并发问题时，除了原子操作，Redis客户端可采用加锁的方法，来控制并发写操作对共享数据的修改，从而保证数据的正确性。RMW操作即是指客户端要对数据做修改操作时所需要执行的步骤，即要先读取Redis中的内存数据到客户端中，然后根据读取到的数据判断是否要修改，然后在本地修改，最后写入到Redis服务中。虽然Redis的单个命令可以原子性执行（Redis是单线程执行的，同一时间最多只有一条Redis命令被执行），但实际操作中数据修改包含了多个命令的操作，包括数据读取、数据增减、写回数据三个操作。
复制链接

扫一扫