目录
- 一、简介
- 二、相关命令
-
- [2.1 multi](#2.1 multi)
- [2.2 exec](#2.2 exec)
- [2.3 discard](#2.3 discard)
- [2.4 watch](#2.4 watch)
一、简介
事务：把⼀系列操作绑定成⼀组，让这⼀组能够批量执⾏。
redis 与 MySQL事务的区别：
- 弱化的原⼦性：redis 没有 "回滚机制"。只能做到这些操作 "批量执⾏"。不能做到 "⼀个失败就恢复到初始状态"。
- 不保证⼀致性：redis 不涉及 "约束"，也没有回滚机制，MySQL 的⼀致性体现的是运⾏事务前和运⾏后，结果都是合理有效的，不会出现中间⾮法状态。
- 不需要隔离性：redis 是一个单线程模型，所有命令都是"串行"执行的，redis 也没有隔离级别，因为不会并发执⾏事务 (redis 单线程处理请求)
- 不需要持久性：redis 是保存在内存的，是否开启持久化，是redis-server ⾃⼰的事情，和事务⽆关。
redis的事务更像是收集命令，等到收到特定指令的时候批量执行。在服务器上搞了⼀个 "事务队列"。每次客⼾端在事务中进⾏⼀个操作，都会把命令先发给服务器，放到 "事务队列" 中(但是并不会⽴即执⾏)，⽽是会在真正收到 EXEC 命令之后，才真正执⾏队列中的所有操作。
redis主要的意义就是保证这一系列命令，执行时不会有其他的命令"插队"。
二、相关命令
2.1 multi
multi开启⼀个事务。执⾏成功返回 OK
2.2 exec
真正执⾏事务。
每次添加⼀个操作，都会提⽰ "QUEUED"，说明命令已经进⼊客⼾端的队列了。真正执⾏ exec 的时候，客⼾端才会真正把上述操作发送给服务器。此时就可以获取到上述 key 的值了.
2.3 discard
放弃当前事务，此时直接清空事务队列，之前的操作都不会真正执⾏到。
2.4 watch
在执⾏事务的时候，如果某个事务中修改的值，被别的客⼾端修改了，此时就容易出现数据不⼀致的问题。
当一个客户端在执行事务的时候，其他客户端在事务提交之前将内容改变了。
得到的结果还是事务中没有改变的值。
从时间上看，事务执行其实是在客户端2设置200的后面执行的，得到101的结果是没问题的，这就是没保证隔离性产生的问题，watch 命令就是⽤来解决这个问题的。
watch 在该客⼾端上监控⼀组具体的 key
- 当开启事务的时候，如果对 watch 的 key 进⾏修改，就会记录当前 key 的 "版本号"。(版本号是个简单的整数，每次修改都会使版本变⼤。服务器来维护每个 key 的版本号情况)
- 在真正提交事务的时候，如果发现当前服务器上的 key 的版本号已经超过了事务开始时的版本号，就会让事务执⾏失败。(事务中的所有操作都不执⾏)。
进⾏修改, 从服务器获取 k1 的版本号是 0. 记录 k1 的版本号，客户端2修改成功, 使服务器端的 k1 的版本号 0 -> 1
真正执⾏修改操作, 此时对⽐版本发现, 客⼾端的 k1 的版本号是 0, 服务器上的版本号是 1, 版本不⼀致! 说明有其他客⼾端在事务中间修改了 k1 ，事务提交失败，这次提交的所有命令都没有执⾏。
unwatch: 取消对 key 的监控.