Redis【事务】（面试相关）与MySQL相比较，重点在Redis事务

目录

• 什么是事务
• 事务操作
• • MULTI
  • EXEC
  • DISCARD
  • WATCH
  • UNWATCH
• 总结

什么是事务

Redis的事务与MySQL的事务概念上是类似的，都是把一系列的操作绑定成一组，让这一组可以批量执行

区别：

区分	Redis	MySQL
原子性	Redis没有"回滚机制"，只能做到这些操作"批量执行"，不能做到"一个失败就恢复到初始状态"	回滚，"批量操作，一个失败初始状态"
一致性	不涉及"约束"，也没有回滚，如果某个操作就会引起不一致	MySQL的一致性体现在运行事务前后，结果都是合理有效的，不会出现中间非法状态
隔离性	不涉及隔离级别，不会并发执行事务	MySQL会有隔离级别
持久性	是存在保存内存的，但是与事务无关，是redis-server自己的操作	保存到硬盘当中

Redis的事务，主要意义：打包避免其他客户端命令插队到中间

事务操作

MULTI

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

Redis：要么全部都执行，要么全部都不执行，但是不保证成功

127.0.0.1:6379> MULTI
OK

EXEC

真正执行事务

开启一个事务之后是保存的一种状态，并没有真正被执行此时如果在开启一个客户端时查不到这个key的
如果在这个过程当中没有执行就直接下线了，此时的事务当中的数据就会丢失了

127.0.0.1:6379> MULTI
OK
127.0.0.1:6379> set k1 1
QUEUED
127.0.0.1:6379> EXEC
OK

每添加一个操作，都会提示QUEUED，说明命令已经进入客户端的队列了

之后新开启的客户端才能真正查到这个值

DISCARD

放弃当前事务，直接清空事务队列

127.0.0.1:6379> MULTI
OK
127.0.0.1:6379> set k1 1
QUEUED
127.0.0.1:6379> DISCARD
OK

127.0.0.1:6379> get k1
(nil)

WATCH

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

# 客户端1
127.0.0.1:6379> MULTI
OK
127.0.0.1:6379> set k1 1
QUEUED

# 客户端2
127.0.0.1:6379> set k1 200
OK

# 客户端1 最后执行
127.0.0.1:6379> exec
OK

#最后获取
127.0.0.1:6379> get key
1

当开启事务的时候，如果对 watch的key进行修改，就会记录当前key的"版本号"（版本号只是一个简单的整数，每次修改版本号都会变大）
在真正提交事务的时候，如果发现当前服务器上的key版本号已经超过事务开始时候的版本号，就说明出现了修改

watch类似于一个"乐观锁"

乐观锁：加锁前有一个心里预期，使锁冲突的概率降低
悲观锁：加锁前有一个心理预期，锁冲突的概率比较高

watch的版本号类似于CAS问题当中的ABA问题

UNWATCH

取消对key的监控

总结

redis事务比MySQL事务要简单很多

1. 原子性：Redis事务，不支持回滚
2. 一致性：Redis并不会保证事务执行的前后统一
3. 持久性：Redis主要通过内存来存储数据
4. 隔离性：Redis作为一个单线程服务器，本质都是串行执行数据的