Redis事务和并发控制

清疚 2023-07-11 06:16 19阅读 0赞

### 什么是Redis事务? ###

Redis事务不保证原子性, 即事务中的某个命令执行失败, 事务不会回滚, 且后续命令会继续执行. 这样一来, Redis事务的功能就和脚本差不多, 都是将命令打包, Redis事务能做的事, 脚本也能做, 而且脚本速度更快.

(1) Redis事务相关的命令

*  MULTI  
    开启一个事务, 后续的命令都会添加到一个队列中, 等待EXEC命令.
 *  EXEC  
    触发并执行事务中的所有命令.
 *  DISCARD  
    清空事务队列.

(2) 实例一

127.0.0.1:6379> set num 1
    OK
    127.0.0.1:6379> multi
    OK
    127.0.0.1:6379> incr num
    QUEUED
    127.0.0.1:6379> incrby num 2
    QUEUED
    127.0.0.1:6379> exec
    1) (integer) 2
    2) (integer) 4
    127.0.0.1:6379> get num
    "4"

(3) 实例二

127.0.0.1:6379> set num 1
    OK
    127.0.0.1:6379> multi
    OK
    127.0.0.1:6379> incr num
    QUEUED
    127.0.0.1:6379> discard
    OK
    127.0.0.1:6379> get num
    "1"

### Redis并发控制 ###

redis本身是没有锁的概念的, 但由于redis是单进程单线程的, 所以redis内部也不会出现并发冲突. 虽然redis内部不会出现并发冲突, 但这并不代表在业务场景下使用redis, 也不会出现并发冲突, 比如以下业务场景:

*  多个客户端并发地写同一个key, 且写命令的执行顺序对结果会有影响
 *  多个客户端并发地读同一个key, 如果满足条件就修改值后写回去.

下面我们就来了解在业务场景下使用redis的并发冲突该如何解决.

**乐观锁**

redis乐观锁, 即CAS(check-and-set)机制, 客户端A在修改key之前先监控key, 如果key被其他客户端修改, 那么客户端A的修改就会失败, 返回 nil. 注意: 客户端A的修改要与事务一起使用.

*  WATCH  
    监控key是否被其他客户端修改, 如果被修改则返回nil.
 *  UNWATCH  
    取消对key的监控.

实例如下:

127.0.0.1:6379> watch mykey
    OK
    127.0.0.1:6379> multi
    OK
    127.0.0.1:6379> set mykey 789
    QUEUED
    127.0.0.1:6379> exec
    (nil)

**分布式锁**

客户端在读写redis之前必须先从redis获取锁, 只有获取到锁的客户端才能读写redis, 而其他没有获取到锁的客户端, 会以每秒一次的频率不断地去尝试获取锁.

> 为什么不能简单的使用synchronized互斥锁? 因为synchronized只对单机部署有用, 而我们的应用为了避免单点故障都是多机部署的.

(1) 方案一

a. 获取锁

SET my_lock 随机值 PX 5000 NX

PX是设置过期时间, 单位毫秒. NX是仅当key不存在时才设置值.

b. 删除锁

只有提供的value值相同才能删除锁, 因为我们不能让客户端删除别人的锁. 因为涉及到条件判断, 为了保证事务特性, 必须使用Lua脚本.

if redis.call("get",KEYS[1]) == ARGV[1] then
    	return redis.call("del", KEYS[1])
    else
        return 0
    end

c. 实例

//1. 获取锁
    127.0.0.1:6379> SET my_lock 123456 PX 5000 NX
    OK
    
    //2. 使用lua脚本删除锁
    [root@master ~]# redis-cli --eval delKey.lua my_lock , 123456
    (integer) 1
    
    //3. 查看key
    127.0.0.1:6379> get my_lock
    (nil)

(2) 方案二

上面方案一的分布式锁有个问题, 如果在key同步到子节点之前主节点宕机了, 就会导致锁丢失. 为此redis提供了在集群架构下的分布式锁, 即RedLock算法.

*  获取当前时间戳, 单位是毫秒.
 *  跟上面类似, 轮流尝试在每个master节点上创建锁, 过期时间较短, 一般就几十毫秒.
 *  尝试在大多数节点上建立一个锁, 比如5个节点就要求是3个节点（n/2 + 1）.
 *  客户端计算建立好锁的时间, 如果建立锁的时间小于超时时间, 就算建立成功了
 *  要是锁建立失败了，那么就依次删除这个锁
 *  只要别人建立了一把分布式锁，你就得不断轮询去尝试获取锁

这种RedLock算法在业界还存在争议, 我们只需要了解下, 所以真正的方案二应该是使用ZooKeeper分布式锁.