Redis事务

认识redis事务

说起事务，会不由自主地想起MySQL中的事务，MySQL中的事务有四个性质：

①原子性：把多个操作，打包成一个整体，要么全都执行成功，要么全都不执行。

②一致性：事务执行之前和执行之后，数据能够对得上号。

③持久性：事务中做出的修改会存在硬盘中

④隔离性：事务并发执行，涉及到的各类读提交问题。

相较于MySQL事务，redis事务很简单：

①原子性：redis原子性是指将多个操作打包在一起，要么全都执行，要么全都不执行。注意：这里跟MySQL事务中的原子性相比，redis原子性不管这些操作有没有成功，它不管！如果事务中有些操作失败了，redis说失败就失败吧。而MySQL则不行，一旦有操作失败，则全部回滚！（有部分观点任务，redis没有原子性，因为以MySQL事务的原子性作为标杆，原子性必须要么执行成功，要么不执行）

②不具备一致性：MySQL一致性是体现事务在执行前和执行后都是合理有效的，没有中间非法状态，而redis没有约束，没有回滚机制，因此事务执行过程中，某个操作失败，则可能会出现不一致的情况。

③不需要隔离性：Redis是一个单线程模型的服务器程序，所有请求/事务，都是"串行"执行的

④不需要持久性：redis数据是保存在内存的.是否开启持久化,是redis-server自己的事情,和事务⽆关。

Redis事务本质就是在服务器上的一个"事务队列"（每个客户端都有一个这样的队列），客户端在事务中进行一个操作，本质就是把命令发送给服务器，放到事务队列中，但是不好立即执行，而是在主线程收到EXEC命令后，主线程才去将队列中的操作依次执行，因此，Redis事务的意义，便是：避免客户端后来的命令插队，并不会去保证执行得对不对。

那么为什么redis事务，不去设计得向MySQL事务那样强大呢？

MySQL事务的强大，其背后是付出了巨大的代价的：

比如，想要实现原子性，一致性，需要实现回滚，那么需要额外开辟空间，去保存相关日志，像dolog等，再然后是每一条记录要搞个隐藏列，通过隐藏列去记录各种信息。因此空间上需要开销很大，时间上执行也有代价。redis正是因为MySQL的空间时间开销大的问题，才制定出来的。

而redis事务的场景：超卖问题。

操作事务

开启事务

MULTI

开启一个事务，执行成功返回OK。

执行事务

EXEC

真正执行事务：

127.0.0.1:6379> MULTI
OK
127.0.0.1:6379> set k1 1
QUEUED
127.0.0.1:6379> set k2 2
QUEUED
127.0.0.1:6379> set k3 3
QUEUED
127.0.0.1:6379> EXEC
1) OK
2) OK
3) OK

每次添加⼀个操作,都会提示"QUEUED",说明命令已经进⼊客户端的队列了.真正执行EXEC的时候,客户端才会真正把上述操作发送给服务器.此时就可以获取到上述key的值了。

127.0.0.1:6379> get k1
"1"
127.0.0.1:6379> get k2
"2"
127.0.0.1:6379> get k3
"3"

放弃当前事务

DISCARD

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

127.0.0.1:6379> MULTI
OK
127.0.0.1:6379> set k1 1
QUEUED
127.0.0.1:6379> set k2 2
QUEUED
127.0.0.1:6379> DISCARD
OK
127.0.0.1:6379> get k1
(nil)
127.0.0.1:6379> get k2
(nil)

监控

WATCH

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

# 客⼾端1 先执⾏
127.0.0.1:6379> MULTI
OK
127.0.0.1:6379> set key 100
QUEUED
# 客⼾端2 再执⾏
127.0.0.1:6379> set key 200
OK
# 客⼾端1 最后执⾏
127.0.0.1:6379> EXEC
1) OK

此时的key是多少呢？

从输入命令的时间看,是客户端1先执⾏的setkey100.客户端2后执的setkey200.但是从实际的执行时间看,是客户端2先执⾏的,客户端1后执行的。

127.0.0.1:6379> get key
"100"

这个时候,其实就容易引起歧义.因此,即使不保证严格的隔离性,至少也要告诉用户,当前的操作可能存在风险。

watch命令就是用于解决这个问题的。watch在该客户端上监控⼀组具体的key。

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

示例

客户端1先执行：

27.0.0.1:6379> watch k1 # 开始监控 k1
OK
127.0.0.1:6379> MULTI
OK
127.0.0.1:6379> set k1 100 # 进⾏修改, 从服务器获取 k1 的版本号是 0. 记录 k1 的版本
QUEUED
127.0.0.1:6379> set k2 1000
QUEUED

客户端2后执行：

127.0.0.1:6379> set k1 200 # 修改成功, 使服务器端的 k1 的版本号 0 -> 1
OK

客户端1再执行：

127.0.0.1:6379> EXEC #真正执⾏修改操作,此时对⽐版本发现,客⼾端的k1的版本不一致，返回空
(nil)
127.0.0.1:6379> get k1
"200"
127.0.0.1:6379> get k2
(nil)

此时说明事务已经被取消了.这次提交的所有命令都没有执行。

UNWATCH--取消监控。