在使用 Redis 时，遇到大流量时，不可避免地会遇到并发问题，多个用户对缓存在 Redis 中的商品信息并发更新，如果没有对并发修改或写入操作做很好的控制，就可能会对业务造成严重的错误，这篇文章学习一下 Redis 中的原子操作和分布式锁的思想。
1.笔记图
2.Redis两种应对并发访问的方法
- 原子操作：
- 描述
- 原子操作是指执行过程保持原子性的操作，而且原子操作执行时并不需要再加锁
- 既能保证并发控制，还能减少对系统并发性能的影响
- 加锁
- 描述
- 在读取数据前，客户端需要先获得锁，否则就无法进行操
- A 客户端获得锁，会一直持有这把锁，直到完成数据更新才释放
- 问题
- 如果加锁操作多，会降低系统的并发访问性能
- 客户端加锁需要用到分布式锁，分布式锁实现复杂，要用额外的存储系统支持
3.并发访问控制中需要对什么进行控制？
- 描述
- 对多客户端访问同一数据的过程控制，保证任何客户端的操作在执行时有互斥性
- 如 A 访问在执行时，B 的操作不能执行，需等 A 操作结束，才能执行
- 并发访问控制对应的操作主要是数据修改操作
- 修改数据基本流程
- 客户端先把数据读取到本地，在本地进行修改
- 客户端修改完数据后，再写回 Redis
- 读取 - 修改 - 写回（Read-Modify-Write，简称为 RMW 操作）
current = GET(id) current-- SET(id, current)
- 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 实例上成功获取到了锁
- 客户端获取锁的总耗时没有超过锁的有效时间
