关于Redis的事务

认识Redis的事务

MySQL的事务拥有四个特性：

原子性：把多个操作，打包成一个整体了。张三给李四转钱，李四没收到，张三就不能扣钱。

一致性：事务执行之前和之后，数据能对得上。张三有1000，给李四转500，最终结果必须是李四500，张三500。

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

隔离性：事务并发执行，涉及到的一些问题。

与MySQL的事务相比，Redis的事务同样是将多个操作打包在一起。Redis的事务与MySQL相比简单很多：

弱化的原子性：Redis的原子性也是把多个操作打包到一起，要么全部执行，要么全部不执行。但不保证成功。如果事务中的若干个操作，存在有失败的，那就只能失败，没有回滚机制。但是MySQL的事务中如果有操作执行失败，要进行回滚，把中间已经执行的操作全都回退。

不具备一致性：redis没有约束，也没有回滚机制，事务执行过程中如果某个修改操作出现失败，就可能引起不一致的情况。

不具备持久性：redis本身就是内存数据库，数据是存储在内存中的。redis虽然存在持久化机制，但是这里的持久化机制，和事务没有直接关系。 

不涉及隔离性：redis是一个单线程的服务器模型。所有的请求/事务，都是“串行”执行的。

Redis的事务主要的意义就是为了“打包”，避免其他客户端的命令，插队到中间。

Redis中实现事务，是引入了队列（每个客户端都有一个），开启事务的时候，此时客户端输入的命令，就会发给服务器并且进入到这个队列中（而不是立即执行）。当遇到了“执行事务”命令的时候，此时就会把队列中的这些任务都按照顺序执行。主线程会把事务中的操作都执行完，再处理别的客户端。

为什么Redis的事务设计地如此简单呢？

MySQL的事务，在背后付出了很大的代价。空间上，要花费更多的空间来存储更多的数据。时间上，也要有更大的执行开销。不符合Redis简单，高效的理念。

什么时候需要使用到Redis的事务呢？

如果我们需要把多个操作打包进行，使用事务是比较合适的。

事务的相关命令

开启事务：MULTI

执行事务：EXEC

放弃当前事务：DISCARD

当开启事务并给服务器发送若干个命令之后，此时服务器重启，此时的效果就等同于discard。

WATCH：监控某个key是否在事务执行之前，发生了改变。查看这个key在事务的multi和exec之间，set key 之后，是否在外部被其他客户端修改了。watch必须搭配事务使用，并且必须在mutli之前使用。

如果没有执行execw，事务中的命令就不会执行。

watch的实现原理

watch的实现类似于“乐观锁”。
乐观锁：加锁之前，就有一个预期，认为接下来锁冲突的概率比较低。

悲观锁：加锁之前，也有一个预期，认为接下来锁冲突的概率比较高。

锁冲突：两个线程针对同一个锁加锁，一个能加锁成功，另一个就得阻塞等待。

锁冲突概率的高低，接下来要做的工作，是不一样的。

redis的watch就相当于是基于版本号这样的机制，来实现了“乐观锁”。当执行watch key的时候，就会给这个key安排一个版本号。版本号可以理解成一个“整数”，每次在修改的时候，版本号都会变大。

在watch key执行时，就会给这个key分配版本号，并且记录了这个版本号。其他客户端只要针对这个key做出了修改，就会引起版本号变大。在“执行事务”命令的时候，此处就会做出判定。判定当前这个key的版本号和最初watch的时候记录的版本号是否一致。如果一致，说明当前key在事务开启到最终执行这个过程中，没有别的客户端修改，于是才能真正进行设置。如果不一致，说明key在其他客户端中改过了，因此此处就直接丢弃事务中的操作。exec返回nil。

watch本质上是给exec加了个判定条件。

以上，关于redis的事务，希望对你有所帮助。