redis事务

谈到事务大家可能就会想起mysql中的事务

注意这里的事务不是指的是事务的四大特性acid

持久性  原子性 隔离性 一致性 

事务的概念就是 一组命令,串行化执行而不被打断

这里redis的事务和mysql的事务就不太一样

传统关系型数据库的事务主要强调的是一个没有执行完成就直接回滚

注:redis这里不存在回滚的概念

而redis这里就分为很多种情况

1.正常执行

就是和正常事务是相同的,原子化执行 

使用multi开启事务

使用exec结束事务

两个指令之间的指令会串行化执行

2.discard 放弃事务

multi    

...

...

discard

直接放弃队列中的事务

3.全体连坐

就是在正常执行的期间出现语法错误等等

4.冤有头债有主

就是假如几条命令在语法阶段没有检查出来

而在编译期间检查出来了,就只会让这一条指令失效

比如我设置一个key对应的邮箱号 对其使用自增操作

在语法上是可以浑水摸鱼过去的但是实际无法执行成功

5.watch监控

这里的watch监控就是类似于乐观锁(CAS)

因为redis是一个高性能的数据库,肯定不能使用悲观锁呀

就是认为在执行期间肯定不会有人动我的数据

所以我不加锁只是执行比较,看内存中的数据是不是被修改过了

如果是修改过了就直接返回一个nil,且队列中的指令不生效

总结

整体执行流程是这样的

multi   开启事务  

指令进入队列

exec 开始执行事务

管道

redis管道操作也是批处理的操作

执行原理就是全打包发送,批量返回数据,避免内核态和用户态的多次转化

有人可能认为这个跟事务有什么区别吗

区别可大了

这里的批处理指令不是原子的

redis原生的事务处理是原子的

事务是一个一个发的,执行的时候可能会进行阻塞

管道是一起发的,不会阻塞

事务是只需要客户端即可

而管道需要客户端和服务端一起操作

指令

比如将cmd.txt写入redis cat cmd.txt | redis-cli -a abc123 --pipe

这里的cmd.txt中装的就是指令

注意:

管道如果命令条数过多 缓冲指令只会依次执行 发生异常了后续命令还是会继续执行的 当客户端发布命令使用管道的时候,服务端会被迫恢复一个队列答复 占用的内存就会很多 性能也必然下降