了解redis事务的cas操作吗

Posted 2023-05-04

当你使用Redis构建你的服务的时候，一定要记住，你只是找了一个合适的工具来实现你需要的功能。
而不是说你在用Redis构建一个服务，这是很不同的，你把Redis当作你很多工具中的一个，只在合适使用的时候再使用它，在不合适的时候选择其它的方法。 参考技术A

说到事务大家都不陌生，在关系型数据库中，事务时并发控制的基本单位，他是一个操作的序列，可以包含多个指令，并且，对于一个事务，其内部的指令要么全部执行，要么都不执行，内部指令不可分割。

关系型数据库的事务具有四个特性：

1. 原子性

2. 一致性

3. 隔离性

4. 持久性

而在我们redis数据库中，事务回事什么样子的呢？

首先我们给出一个定义：redis的事务中，一次执行多条命令，本质是一组命令的集合，一个事务中所有的命令将被序列化，即按顺序执行而不会被其他命令插入

在redis中，事务的作用就是在一个队列中一次性、顺序性、排他性的执行一系列的命令。

事务的生命周期：

1. 事务的创建：使用MULTI开启一个事务

2. 加入队列：在开启事务的时候，每次操作的命令将会被插入到一个队列中，同时这个命令并不会被真的执行

3. EXEC命令进行提交事务

常用的关于事务的命令有：

1. MULTI：使用该命令，标记一个事务块的开始，通常在执行之后会回复OK，（但不一定真的OK），这个时候用户可以输入多个操作来代替逐条操作，redis会将这些操作放入队列中。

2. EXEC：执行这个事务内的所有命令

3. DISCARD：放弃事务，即该事务内的所有命令都将取消

4. WATCH：监控一个或者多个key，如果这些key在提交事务（EXEC）之前被其他用户修改过，那么事务将执行失败，需要重新获取最新数据重头操作（类似于乐观锁）。

5. UNWATCH：取消WATCH命令对多有key的监控，所有监控锁将会被取消。

注意：关于乐观锁等概念：

乐观锁：就像他的名字，不会认为数据不会出错，他不会为数据上锁，但是为了保证数据的一致性，他会在每条记录的后面添加一个标记（类似于版本号），假设A 获取K1这条标记，得到了k1的版本号是1，并对其进行修改，这个时候B也获取了k1这个数据，当然，B获取的版本号也是1，同样也对k1进行修改，这个时候，如果B先提交了，那么k1的版本号将会改变成2，这个时候，如果A提交数据，他会发现自己的版本号与最新的版本号不一致，这个时候A的提交将不会成功，A的做法是重新获取最新的k1的数据，重复修改数据、提交数据。

悲观锁：这个模式将认定数据一定会出错，所以她的做法是将整张表锁起来，这样会有很强的一致性，但是同时会有极低的并发性（常用语数据库备份工作，类似于表锁）。

那么，现在我们来执行一次具体看看redis的事务机制：

首先我会开启事务，并向数据库中存储4条数据，可以看到没执行一条命令的时候都会显示入队，并不会返回执行结果，说明redis中在事务提交之前，其内部的所有命令将不会被执行：

那么，如果中间有命令出错了会怎样呢？现在我随便打几个字符试一试：

可以看出，在第三条命令中我随便打了几个字符，提交事务的时候并没有成功，这也很符合我们对事务的理解，嗯~具有原子性。但是，有一个细节，那就是错误命令在我输入的时候就已经报错了，也就是说这个条错误命令在进入队列的时候redis就已经知道这是一条错误命令，这样，整个事务的命令将全部失败，那么，有没有一种可能某个错误指令在进入队列的时候redis还没有发现他的错误呢？我们试一试下面这个例子：

问题出现了，我们可以看到，name+1这条指令其实是错误的，但是提交事务的时候会发现，这条错误命令确实没有执行，但是其他正确的命令却执行，这是为什么的？

原因是在redis中，对于一个存在问题的命令，如果在入队的时候就已经出错，整个事务内的命令将都不会被执行（其后续的命令依然可以入队），如果这个错误命令在入队的时候并没有报错，而是在执行的时候出错了，那么redis默认跳过这个命令执行后续命令。也就是说，redis只实现了部分事务。

下面我们来看看刚刚提到的锁的问题，我们说过，redis的锁CAS(check and set)类似于乐观锁，redis的实现原理是使用watch进行监视一个（或多个）数据，如果在事务提交之前数据发生了变化（估计使用了类似于乐观锁的标记），那么整个事务将提交失败，我们可以举一个例子，我们开启两个终端，模拟两个人的操作，设置一条数据为count，初始时100，现在A对其进行监控，并且为count增加20

在没有提交之前，B也获取了这个count，为其减少50，

那么这个时候A如果提交事务，会出现失败提示：

可以看到，在A对数据的修改过程中，B对数据进行了修改，那么这条数据的“标记”就发生了变化，已经不是当初A取出数据的时候的标记了，这样，A的事务也就提交失败了。

最后通过上述的实验，我们总结redis事务的三条性质：

1. 单独的隔离操作：事务中的所有命令会被序列化、按顺序执行，在执行的过程中不会被其他客户端发送来的命令打断
2. 没有隔离级别的概念：队列中的命令在事务没有被提交之前不会被实际执行
3. 不保证原子性：redis中的一个事务中如果存在命令执行失败，那么其他命令依然会被执行，没有回滚机制

阅读全文

Redis 的并发竞争问题是什么？如何解决这个问题？了解 redis 事务的 CAS 方案吗？

面试官心理分析

这个也是线上非常常见的一个问题，就是多客户端同时并发写一个 key，可能本来应该先到的数据后到了，导致数据版本错了；或者是多客户端同时获取一个 key，修改值之后再写回去，只要顺序错了，数据就错了。

而且 redis 自己就有天然解决这个问题的 CAS 类的乐观锁方案。

面试题剖析

某个时刻，多个系统实例都去更新某个 key。可以基于 zookeeper 实现分布式锁。每个系统通过 zookeeper 获取分布式锁，确保同一时间，只能有一个系统实例在操作某个 key，别人都不允许读和写。

你要写入缓存的数据，都是从 mysql 里查出来的，都得写入 mysql 中，写入 mysql 中的时候必须保存一个时间戳，从 mysql 查出来的时候，时间戳也查出来。

每次要写之前，先判断一下当前这个 value 的时间戳是否比缓存里的 value 的时间戳要新。如果是的话，那么可以写，否则，就不能用旧的数据覆盖新的数据。