【redis】事务详解，相关下令multi、exec、discard 与 watch 的原理 ...

什么是事务

MySQL 事务：

• 原子性：把多个操作，打包成一个团体
  
• 一致性：事务执行之前和之后，数据都不能离谱（变化前后能对上号）
  
• 持久性：事务中做出的修改都会存硬盘
  
• 隔离性：事务并发执行，涉及到的一些问题
  

原子性

相比于 MySQL 来说，Redis 的事务就是个弟弟：

• 原子性：Redis 的事务，到底有没有原子性？存在争议
  
  
  
  • 最原本的含义是把多个操作打包到一起，要么都执行，要么都不执行
    
  • Redis 做到了上述的含义，但是 MySQL 这里的原子性走的更远
    
    
    
    • MySQL 也是把多个操作打包到一起，要么全都执行成功，要么都不执行。假如事务中有操作执行失败的，就要进行回滚，把中央已经执行的操作，全部回退
      
    • Redis 事务中的如干操作，要是有失败的，无所谓。
      
    
    
  
  

Redis 把多个操作打包到一起执行，已经可以称为是原子性了，只是 MySQL 标杆，提高了“原子性”门槛，这就使人们谈到原子性的时候，更多的想到的是 MySQL 如许带回滚的原子性
所以，一般说到 Redis 的事务有没有原子性，更多的倾向于没有（或者弱化的原子性）
一致性

Redis 没有束缚，也没有回滚机制，事务执行过程中假如某个修改操作出现失败，就可能引起不一致的情况

• 所以 Redis 事务不具备一致性
  

持久性

reids 自己就是内存数据库，数据是存储在内存中的，固然 Redis 也有持久化机制（AOF），但这里的持久化机制和事务没有什么关系

• 像 MySQL 那边，事务百分百有持久性，Redis 这边把持久化机制关了。这是不一样的
  
• 所以 Redis 事务不具备持久性
  

隔离性

Redis 是一个单线程模子的服务器程序，全部的请求/事务都是“串行”执行的。而谈到隔离性，都是并发执行才会涉及到的

• 所以 Redis 事务不涉及隔离性
  

上风

Redis 事务，主要的意义就是为了“打包”，制止其他客户端的下令，插队插到中央

• Redis 中实现事务，是引入了一个队列（每个客户端都有一个）
  
• 开启事务的时候，此时客户端输入的下令，就会发给服务器，并且进入这个队列中（而不是立即执行）。当遇到了“执行事务”下令的时候，此时就会把队列中的这些任务都按次序依次执行
  
  
  
  • “按次序依次执行”是在 Redis 主线程中完成的，主线程会把事务中的操作都执行完，再处理别的客户端
    
  
  

与 MySQL 对比

Redis 的事务为什么就计划的这么简单，而不计划成和 MySQL 一样强大呢？

• MySQL 的事务，在背后付出了很大的代价
  
  
  
  • 空间上，要耗费更多的空间来存储更多的数据（实现回滚，就要额外开发空间去存储必要的日记…）
    
  • 时间上，也要有更大的执行开销 (必要做更多额外的动作)
    
  
  

正是由于 MySQL 上述的问题，才有 Redis 上场的时机（简单高效的上风）
用处

什么时候必要用到 Redis 事务呢？

• 假如我们必要把多个操作打包进行操作，使用事务是比力合适的
  

---

比如一个商品秒杀出售场景：
一个货品 A，进行秒杀出售，市场火爆。此时最重要的就是不能出现“超卖”的情况（超卖：放货 5000 台，卖出了 5001 台）
一个典型的程序写法：

1. 获取仓库中剩余的商品个数
2. if(个数 > 0) {
3.         下单成功;
4.         个数--;
5. }

复制代码

• 假如不加上任何限定，就可能会存在"线程安全"问题
  
• 所以我们得让 下单成功 和 个数-- 这两个操作是原子的
  
  
  
  • 以前在多线程中，是通过加锁的方式，来制止插队
    
  • 在 Redis 中，就直接使用事务即可
    
  
  

使用事务之后的写法：

1. 开启事务
2. get count
3. if count > 0
4.         decr count
5. 执行事务

复制代码

• 在 redis 吸收到下令的时候，不会立即执行，只会将其按次序放在队列中。当收到“执行事务”操作的时候，才会开始按次序执行下令
  
  
  
• 第二个客户端的“执行事务”下令发过来之后，服务器才真正执行第二个事务中的内容。此时第一个事务执行下令已经运行过了，此时第二个事务 get 到的 count 就已经是第一个事务自减之后的效果了
  

这个场景中，没加锁，也能办理上述“超卖”问题
   redis 下令里能进行条件判断吗？
  

• redis 原生下令中确实没有这种条件判断定，但是 redis 支持 lua 脚本
  
  
  
  • lua 是另外一种编程语言，特点是小巧，许多程序都可以内嵌 lua 语言，从而去执行其他的语言
    
  
  
• 通过 lua 脚本，就能实现上述的“条件判断”，并且也和事务一样是打包批量执行的
  
• lua 脚本的实现方式，是 redis 事务的进阶版本
  

  

---

确实，redis 的事务的应用场景，没有 MySQL 的事务那么多（有点鸡肋的感觉）。redis 假如是按照集群模式摆设，就不支持事务
事务相关下令

开启事务——MULTI

（猫体，不是马体）
开启一个事务，执行成功返回 OK

• 此时只是在服务器的事务队列中，保存了上述请求，并没有真正执行下令
  
• 此时假如另外开一个客户端，尝试查询这几个 key，是查询不到的
  

执行事务——EXEC

真正执行事务

• 此时客户端才会真正把上述操作发给客户端，此时就可以获取到 key 的值了
  
  
  

放弃当前事务——DISCARD

放弃当前事务，此时直接清空事务队列，之前的操作都不会真正执行到

• 前面输入的下令，都被抛弃了
  

---

当我们开启事务，并且给服务器发送若干下令之后，此时重启服务器，会怎么样？

• 此时的效果就等同于 discard
  
• 事务队列终归是内存中的结构，重启之后，天然是没有了
  

监控某个 key——WATCH

在执行事务的时候，假如某个事务中修改的值，被别的客户端修改了，此时就容易出现数据不一致的问题
作用场景

从时间上来看，客户端 1 是先发送了 set key 222，客户端 2 是后发送了 set key 333

• 由于客户端 1 中，得是 exec 执行了，才会真正执行 set key 222。这个操作变成了现实上更晚执行的操作，最终 key 的值就是 222
  

使用方法

在刚才的场景中，就可以使用 watch 下令来监控这个 key，看看这个 key 在事务的 multi 和 exec 之间，set key 之后，是否在外部被其他客户端修改了

• 被监控的 key 被修改之后，exec 之后返回值为 nil
  

实现原理

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

• 乐观锁/悲观锁不是指某个具体的锁，而是指的是某一类锁的特性
  
• 乐观锁：加锁之前，就有一个心理预期，接下来锁的辩论概率较低
  
• 悲观锁：加锁之前，也有一个心理预期，接下来锁的辩论概率较高
  
  
  
  • 辩论：两个线程针对同一个锁加锁，一个能加锁成功，另一个就得阻塞等待
    
  
  
• 锁辩论概率高低，接下来要做的工作是不一样的
  

   乐观锁在 https://yeeear.blog.csdn.net/article/details/141102212 这篇文章中有具体表明
  redis 的 watch 就相称于是基于版本号如许的机制，来实现了“乐观锁”（就是 CAS 中的 ABA 问题的办理方法）

• watch 必须搭配事务使用，并且必须在 multi 之前使用
  
• 假如 watch 的版本号和 exec 的版本号
  
  
  
  • 一致：阐明当前 key 在事务开启到最终执行这个过程中，没有被别的客户端修改，于是才能真正进行设置
    
  • 不一致：阐明 key 在其他客户端中改过了，因此此处就直接抛弃事务中的操作，exec 返回 nil
    
  
  

所以，watch 本质上就是给 exec 加了一个判断条件
事务总结

Redis 的事务，要比 MySQL 的事务，简单许多

• 原子性：Redis 的事务，并不支持回滚
  
• 一致性：Redis 并不会保证事务执行前后的内容同一
  
• 持久性：Redis 主要通过内存来存储数据
  
• 隔离性：Redis 自身作为一个单线程的服务器模子，上面处理的请求本质上都是串行执行的
  

四个关于事务的下令：

• 开启事务—— nulti
  
• 执行事务—— exec
  
• 放弃当前事务—— discard
  
• 监控某个 key 是否被修改—— watch
  

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。