目录
什么是事务
Redis 的事务和 MySQL 的事务概念上是类似的. 都是把⼀系列操作绑定成⼀组. 让这⼀组能够批量执⾏.
但是注意体会 Redis 的事务和 MySQL 事务的区别:
弱化的原⼦性: redis 没有 "回滚机制". 只能做到这些操作 "批量执⾏". 不能做到 "⼀个失败就恢复到初始状态".
不保证⼀致性: 不涉及 "约束". 也没有回滚. MySQL 的⼀致性体现的是运⾏事务前和运⾏后 , 结果都是合理有效的, 不会出现中间⾮法状态.
不需要隔离性: 也没有隔离级别, 因为不会并发执⾏事务 (redis 单线程处理请求) .
不需要持久性: 是保存在内存的. 是否开启持久化, 是redis-server ⾃⼰的事情, 和事务⽆关
相比之下我们发现Redis的事务和MySQL中的事务相差很远，尤其是原子性；Redis可以说是没有原子性的；
Redis 事务本质上是在服务器上搞了⼀个 "事务队列". 每次客⼾端在事务中进⾏⼀个操作, 都会把命令先发给服务器, 放到 "事务队列" 中(但是并不会⽴即执⾏)⽽是会在真正收到 EXEC 命令之后, 才真正执⾏队列中的所有操作.
因此, Redis 的事务的功能相⽐于 MySQL 来说, 是弱化很多的. 只能保证事务中的这⼏个操作是 "连续的", 不会被别的客⼾端 "加塞", 仅此⽽已.
事务操作
MULTI
开启⼀个事务. 执⾏成功返回 OK.
示例：
EXEC
真正执⾏事务.
每次添加⼀个操作, 都会提⽰ "QUEUED", 说明命令已经进⼊客⼾端的队列了.
真正执⾏ EXEC 的时候, 客⼾端才会真正把上述操作发送给服务器.
此时就可以获取到上述 key 的值了.
示例：
每次添加⼀个操作, 都会提⽰ "QUEUED", 说明命令已经进⼊客⼾端的队列了.
真正执⾏ EXEC 的时候, 客⼾端才会真正把上述操作发送给服务器.
此时就可以获取到上述 key 的值了
DISCARD
放弃当前事务. 此时直接清空事务队列. 之前的操作都不会真正执⾏到.
实例
WATCH
在执⾏事务的时候, 如果某个事务中修改的值, 被别的客⼾端修改了, 此时就容易出现数据不⼀致的问题.
示例
此时，为什么key的值是222呢？
从输⼊命令的时间看, 是客⼾端1 先执⾏的 set key 2222. 客⼾端2 后执⾏的 set key 3333.
但是从实际的执⾏时间看, 是客⼾端2 先执⾏的, 客⼾端1 后执⾏的.
这个时候, 其实就容易引起歧义.
因此, 即使不保证严格的隔离性, ⾄少也要告诉⽤⼾, 当前的操作可能存在⻛险.
watch 命令就是⽤来解决这个问题的. watch 在该客⼾端上监控⼀组具体的 key.
• 当开启事务的时候, 如果对 watch 的 key 进⾏修改, 就会记录当前 key 的 "版本号". (版本号是个简单
的整数, 每次修改都会使版本变⼤. 服务器来维护每个 key 的版本号情况)
• 在真正提交事务的时候, 如果发现当前服务器上的 key 的版本号已经超过了事务开始时的版本号, 就
会让事务执⾏失败. (事务中的所有操作都不执⾏).
UNWATCH
取消对 key 的监控.
相当于 WATCH 的逆操作. 此处不做演⽰.
今天对Redis事务的分享到这就结束了，希望大家读完后有很大的收获，也可以在评论区点评文章中的内容和分享自己的看法；个人主页还有很多精彩的内容。您三连的支持就是我前进的动力，感谢大家的支持！！!