【Redis】Redis 事务

什么是事务

Redis 的事务和 MySQL 的事务概念上是类似的. 都是把⼀系列操作绑定成⼀组. 让这⼀组能够批量执⾏.

但是注意体会 Redis 的事务和 MySQL 事务的区别:

• 弱化的原子性: Redis 没有 “回滚机制”, 只能做到这些操作 “批量执行”, 不能做到 “一个失败就恢复到初始状态”.
• 不保证一致性: 不涉及 “约束”, 也没有回滚, MySQL 的一致性体现的是运行事务前和运行后, 结果都是合理有效的, 不会出现中间非法状态.
• 不需要隔离性: 也没有隔离级别, 因为不会并发执行事务(Redis单线程处理请求)
• 不需要持久性: 是保存在内存的, 是否开启持久化, 是 Redis-server 自己的事情, 和事务无关.

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

而是会在真正收到 exec 命令之后才真正执行队列中的所有操作

因此, Redis 的事务的功能相比于MySQL来说, 是弱化很多的, 只能保证事务中的这几个操作是 “连续的”, 不会被别的客户端 “加塞”, 仅此而已.

事务操作

MULTI

开启⼀个事务. 执⾏成功返回 OK.

EXEC

真正执⾏事务.

每次添加⼀个操作, 都会提⽰ “QUEUED”, 说明命令已经进⼊客⼾端的队列了.

真正执⾏ EXEC 的时候, 客⼾端才会真正把上述操作发送给服务器.

此时就可以获取到上述 key 的值了.

DISCARD

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

WATCH

在执⾏事务的时候, 如果某个事务中修改的值, 被别的客⼾端修改了, 此时就容易出现数据不⼀致的问题.

此时, key 的值是多少呢??

从输⼊命令的时间看, 是客⼾端1 先执⾏的 set key 100. 客⼾端2 后执⾏的 set key 200.

但是从实际的执⾏时间看, 是客⼾端2 先执⾏的, 客⼾端1 后执⾏的.

这个时候, 其实就容易引起歧义.

因此, 即使不保证严格的隔离性, ⾄少也要告诉⽤⼾, 当前的操作可能存在⻛险.

watch 命令就是⽤来解决这个问题的. watch 在该客⼾端上监控⼀组具体的 key.

• 当开启事务的时候, 如果对 watch 的 key 进⾏修改, 就会记录当前 key 的 “版本号”. (版本号是个简单的整数, 每次修改都会使版本变⼤. 服务器来维护每个 key 的版本号情况)
• 在真正提交事务的时候, 如果发现当前服务器上的 key 的版本号已经超过了事务开始时的版本号, 就会让事务执⾏失败. (事务中的所有操作都不执⾏).

实例

UNWATCH

取消对 key 的监控.