Redis事务讲解

概念

Redis的事务本质就是一组命令的集合,可以一次性执行多个指令.事务中的所有命令都会被序列化,按顺序地执行.

单独的隔离操作
事务从上到下依次执行的过程中,不会被其它客户端发送来的命令请求打断.

Redis事务没有隔离性概念
队列中的命令没有提交之前都不会被实际的执行

Redis不保证原子性
Redis的单条命令一定是原子性的,但是事务中,如果其中一个命令执行失败,其余的命令依旧执行,没有回滚.

Redis的事务极其简单

# 开启一个事务
# 一堆指令
# 执行这个事务
multi # 标记事务的开始
exec # 执行事务
discard # 放弃事务，取消这个事务

测试:
正常执行:

放弃事务:

事务中的错误

• 事务在执行EXEC之前,入队的命令可能会出错.比如说，命令可能会产生语法错误（参数数量错误，参数名错误，等等），或者其他更严重的错误，比如内存不足（如果服务器使用 maxmemory 设置了最大内存限制的话）。
• 命令可能在 EXEC 调用之后失败。举个例子，事务中的命令可能处理了错误类型的键，比如将列表命令用在了字符串键上面，诸如此类。

处理方式

编译型错误(命令错误),全体连坐

运行时错误(1/0),冤头债主

乐观锁

乐观锁:

非常乐观,每次获取数据都认为这个数据没有变化,没有被人修改过,所以不会上锁.但是更新的时候需要去比较一下这个数据在此期间是否有没有被人更新过.(版本号控制)乐观锁使用的场景,就是读非常多的情况下,这样可以提高吞吐量,提交的版本一定要大于当前记录版本才可以修改.

悲观锁:

非常悲观,每次获取这个数据都认为被人动了,每次获取数据都会上锁,如果别人要获取这个数据,就必须要等到解锁才可以拿到,传统关系数据库都是这种锁机制,行锁,表锁,读写锁,syn都是悲观锁,操作之前先上锁.

测试redis实现乐观锁操作

watch    #监控数据
unwatch  #取消监控

正常执行

# 初始化测试环境
127.0.0.1:6379> set money 100
OK
127.0.0.1:6379> set use 0失败测试
如果失败，则需要放弃监视
OK
# 监控 money， 假设在一个事务内，这个money没有发生变化，这个事务才可以执行成功！
127.0.0.1:6379> WATCH money
OK
# 开启事务，后面和之前一样的
127.0.0.1:6379> MULTI
OK
127.0.0.1:6379> DECRBY money 20
QUEUED
127.0.0.1:6379> INCRBY use 20
QUEUED
127.0.0.1:6379> exec
1) (integer) 80
2) (integer) 20

失败测试

如果失败,则需要放弃监视

# 如果执行失败则需要放弃监视，再次获取这个值
127.0.0.1:6379> UNWATCH
OK
127.0.0.1:6379> WATCH m
OK
127.0.0.1:6379> MULTI
OK
127.0.0.1:6379> DECRBY m 20
QUEUED
127.0.0.1:6379> INCRBY u 20
QUEUED
127.0.0.1:6379> exec
1) (integer) 180
2) (integer) 20
# mysql
select verion ... 1 # 先去获取版本号
update verion = verion + 1 where version = 1 # 更新的时候带上版本号
while(){
// 获取最新版本，直到修改成功！
}

我们一旦执行EXEC,无论你事务是否执行成功,WATCH都会取消监视,事务执行失败的话,我们需要重新监视这个变量.

总结:

事务3阶段

• 开启: 以MULTI开启一个事务
• 入队: 将多个命令入队到事务中,接到这些命令不会立即执行,而是放到等待执行的事务队列里面.
• 执行: 由EXEC命令触发事务

事务3特性

• 单独的隔离操作
• 没有隔离级别的概念
• 不保证原子性

为什么 Redis 不支持回滚（roll back）

• Redis 命令只会因为错误的语法而失败（并且这些问题不能在入队时发现），或是命令用在了错误类型的键上面：这也就是说，从实用性的角度来说，失败的命令是由编程错误造成的，而这些错误应该在开发的过程中被发现，而不应该出现在生产环境中。
• 因为不需要对回滚进行支持，所以 Redis 的内部可以保持简单且快速。