文章目录

  • Redis学习笔记-并发控制&分布式锁
  • 1.笔记图
  • 2.Redis两种应对并发访问的方法
  • 3.并发访问控制中需要对什么进行控制？
  • 4.Redis 的两种原子操作方法
  • 5.Redis实现分布式锁
  • 6.分布式锁算法(Redlock)


Redis学习笔记-并发控制&分布式锁

在使用 Redis 时，遇到大流量时，不可避免地会遇到并发问题，多个用户对缓存在 Redis 中的商品信息并发更新，如果没有对并发修改或写入操作做很好的控制，就可能会对业务造成严重的错误，这篇文章学习一下 Redis 中的原子操作和分布式锁的思想。

1.笔记图

redisson 读写锁实现 redis 读写控制 锁_分布式

2.Redis两种应对并发访问的方法

  • 原子操作：
  • 描述
  • 原子操作是指执行过程保持原子性的操作，而且原子操作执行时并不需要再加锁
  • 既能保证并发控制，还能减少对系统并发性能的影响
  • 加锁
  • 描述
  • 在读取数据前，客户端需要先获得锁，否则就无法进行操
  • A 客户端获得锁，会一直持有这把锁，直到完成数据更新才释放
  • 问题
  • 如果加锁操作多，会降低系统的并发访问性能
  • 客户端加锁需要用到分布式锁，分布式锁实现复杂，要用额外的存储系统支持

3.并发访问控制中需要对什么进行控制？

  • 描述
  • 对多客户端访问同一数据的过程控制，保证任何客户端的操作在执行时有互斥性
  • 如 A 访问在执行时，B 的操作不能执行，需等 A 操作结束，才能执行
  • 并发访问控制对应的操作主要是数据修改操作
  • 修改数据基本流程
  • 客户端先把数据读取到本地，在本地进行修改
  • 客户端修改完数据后，再写回 Redis
  • 读取 - 修改 - 写回（Read-Modify-Write，简称为 RMW 操作）
current = GET(id)
current--
SET(id, current)

redisson 读写锁实现 redis 读写控制 锁_mysql_02

  • RMW潜在风险：客户端 A 在 t1 时读取库存值 10 并扣减 1，在 t2 时，客户端 A 还没有把扣减后的库存值 9 写回 Redis，而在此时，客户端 B 读到库存值 10，也扣减了 1，B 记录的库存值也为 9 了。等到 t3 时，A 往 Redis 写回了库存值 9，而到 t4 时，B 也写回了库存值 9

4.Redis 的两种原子操作方法

  • 单命令操作
  • 把多个操作在 Redis 中实现成一个操作
  • 如 incr/decr 命令就是单个命令操作
  • 执行单个 Lua 脚本
  • 把多个操作写到一个 Lua 脚本中执行
  • Redis 会把整个 Lua 脚本作为一个整体执行，在执行的过程中不会被其他命令打断，从而保证了 Lua 脚本中操作的原子性
  • 使用 Redis 的 EVAL 命令来执行脚本
  • 应用举例：
  • 描述：当一个业务应用的访问用户增加时，我们有时需要限制某个客户端在一定时间范围内的访问次数
  • lua脚本内容
//获取ip对应的访问次数
current = GET(ip)
//如果超过访问次数超过20次，则报错
IF current != NULL AND current > 20 THEN
    ERROR "exceed 20 accesses per second"
ELSE
    //如果访问次数不足20次，增加一次访问计数
    value = INCR(ip)
    //如果是第一次访问，将键值对的过期时间设置为60s后
    IF value == 1 THEN
        EXPIRE(ip,60)
    END
    //执行其他操作
    DO THINGS
END
  • 小建议：把很多操作都放在 Lua 脚本中原子执行，会导致 Redis 执行脚本的时间增加，同样也会降低 Redis 的并发性能，在编写 Lua 脚本时，你要避免把不需要做并发控制的操作写入脚本中

5.Redis实现分布式锁

  • 锁操作流程
  • 加锁：SETNX lock_key 1
  • 业务逻辑：DO THINGS
  • 释放锁：DEL lock_key
  • 潜在风险
  • 情况一：假如某个客户端在执行了 SETNX 命令、加锁之后，在操作共享数据时发生了异常，结果一直没有执行最后的 DEL 命令释放锁
  • 情况一应对办法：给锁变量设置一个过期时间
  • 情况二：如果客户端 A 执行了 SETNX 命令加锁后，假设客户端 B 执行了 DEL 命令释放锁
  • 情况二应对办法：
  • 设置客户端唯一标识
// 加锁, unique_value作为客户端唯一性的标识
SET lock_key unique_value NX PX 10000

Tips：NX 表示 key 不存在时创建，PX 表示以毫秒为单位的过期时间

  • lua脚本中释放锁之前判断用户唯一标识
# 命令
redis-cli  --eval  script lock_key , unique_value
# lua脚本内容
//释放锁 比较unique_value是否相等，避免误释放
if redis.call("get",KEYS[1]) == ARGV[1] then
	return redis.call("del",KEYS[1])
else
	return 0
end

Tips：script 指的是 lua 脚本名，lock_key , unique_value 分别传入 lua 脚本中，对应KEYS[1]、ARG[1]

6.分布式锁算法(Redlock)

  • 基本思路：让客户端和多个独立的 Redis 实例依次请求加锁，如果客户端能够和半数以上的实例成功地完成加锁操作，那么我们就认为，客户端成功地获得分布式锁了，否则加锁失败
  • 加锁步骤：
  • 客户端获取当前时间
  • 客户端按顺序依次向 N 个 Redis 实例执行加锁操作，使用 SET 命令，带上 NX，EX/PX 选项，以及带上客户端的唯一标识
  • 一旦客户端完成了和所有 Redis 实例的加锁操作，客户端就要计算整个加锁过程的总耗时
  • 加锁成功的条件
  • 客户端从超过半数（大于等于 N/2+1）的 Redis 实例上成功获取到了锁
  • 客户端获取锁的总耗时没有超过锁的有效时间