Redis 事务

事务介绍

Redis 事务和 MySQL 事务在概念上类似的

把一些列的操作绑定成一组，让这一组能够批量执行

MySQL 事务

原子性：把多个操作打包成一个整体

一致性：事务执行前后数据合理

持久性：事务做出的操作都会修改硬盘

隔离性：事务并发执行

Redis 事务

1）弱化的原子性：Redis 没有“回滚机制”

      只能做到“批量执行”，不能做到“一个错误就回到初始状态”

2）不保证一致性：不涉及“约束”，也没有“回滚”

      MySQL 的一致性体现在运行时事务前后，结果都是合理有效的，不会出现中间非法状态

3）不需要隔离性：没有隔离级别

成功。 Red      Redis 单线程处理请求

4）不需要持久性：保存在内存中

      是否开启持久化，是 redis-server 的事情，与事务无关

Redis 事务的主要意义是为了”打包“，避免其他客户端的命令，插队到中间

Redis事务，本质上是在客户端上搞了一个“事务队列”，每次客户端在事务中执行一个操作，都会先把命令发给服务器，放到“事务队列”中（不会立即执行）

在收到 exec 命令时，才真正执行队列中的操作

Redis 事务设计简单的原因：

MySQL 事务在空间上，花费更多的空间存储数据；在时间上，会有更大的开销

场景引入

以 商品超卖 为例：

 该操作并非原子性

多线程，是通过加锁的方式来避免插队

Redis直接使用事务即可（如果 Redis 按照集群模式部署，不支持事务）

Redis 原生命令中没有条件判断，但是 Redis原生命令支持 lua 脚本

通过 lua 脚本可以实现上述的逻辑判定（原子性），和 事务一样也是打包批量执行的

lua 脚本的实现方式是 Redis 事物的进阶版本

Redis 中的 lua 脚本，也能起到类似事务的效果

事务能实现的任何效果，都可以使用 lua 脚本替代（原子性）

事务操作

1）开启事务 MULYI

在服务器的事务队列上，保存了上述请求

此时再开一个客户端，尝试查询上述设置的 key 的数据，是没有结果的

2）执行事务 EXEC

队列中有多少操作，返回多少个“OK”

3）放弃当前事务 DISCARD

开启事务，给服务器发送若干命令后，此时服务器重启 ——>

此时的效果类似于 discard

4)  监视 WATCH

在上述场景中，可以使用 watch 命令来监视这个 key

unwatch  取消对 key 的监控

查看当前 key 在事务的 multi 和 exec 之间是否被修改（即 set key 后，是否被其他客户端修改）

exec 在执行上述事务的命令时，发现 key 在外部有修改，于是真正执行 set key 22 命令没有执行

watch 原理

watch 的实现，类似于是一个“乐观锁”

乐观锁：加锁前，有一个心理预期，预期接下来锁冲突的概率比较低

悲观锁：加锁前，有一个心理预期，预期接下来锁冲突的概率比较高

C++ Linux中涉及到的锁 mutex / std::mutex 都是悲观锁

Java synchronized 可以在乐观锁 / 悲观锁之间自适应

当执行 watch key 时，就会给这个 key 安排一个 版本号（可以理解成一个整数）

每次修改 key，版本号都会变大

watch 必须搭配事务使用，并且必须是在 multi 之前实现

watch 本质上是给 exec 加了个判定条件

在执行 事务 中命令的时候，会在 exec 处做出判断

判断当前这个 key 的版本号，和最初的 watch 时记录的版本号是否一致

如果一致，说明 key 在当前事务开启到最终执行的过程中，没有被其他的客户端修改，进行设置

如果不同，说明 key 在其他客户端中改过了，此处直接丢弃事务中的操作，exec 返回 nil

上述过程，在 CAS 里的 ABA问题中也涉及到了，思想及实现上都非常相似