Redis中的事务操作

Redis的事务定义：
Redis事务是一个单独的隔离操作：事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。
Redis事务的主要作用就是串联多个命令防止别的命令插队。
就像羊肉串那样，不允许别的羊肉串插进来。
如何实现事务？我们需要通过下面三个命令：Multi、Exec、discard
从输入Multi命令开始，输入的命令都会依次进入命令队列中，但不会执行，直到输入Exec后，Redis会将之前的命令队列中的命令依次执行。
组队的过程中可以通过discard来放弃组队。

示例：

事务的错误处理：
组队中某个命令出现了报告错误，则执行时整个的所有队列都会被取消。

示例：

但如果是执行阶段某个命令出现了错误，则只有报错的命令不会被执行，而其他的命令都会执行，不会回滚。

示例：

那为什么要出现事务操作呢？
我们想象一下有很多人有你的账户，同时去参加过双十一购物的场景。
如果没有事务机制，则会发生下面的情况：

而处理这种情况有两种解决方式，一种是悲观锁，一种是乐观锁。
悲观锁：

悲观锁(Pessimistic Lock), 顾名思义，就是很悲观，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会block直到它拿到锁。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。
这就相当于Java多线程中的那个上锁的关键字，我忘记咋拼的了。
乐观锁：

乐观锁(Optimistic Lock), 顾名思义，就是很乐观，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号等机制。乐观锁适用于多读的应用类型，这样可以提高吞吐量。Redis就是利用这种check-and-set机制实现事务的。
意思就是每个数据一开始都有自己的版本号，而且数据在更新时也会同步更新自己的版本号，如上图中一开始两个人都拿到了版本号为1.0的10000数据，但是上面减8000的操作要快于下面减5000的操作，于是上面的10000数据更新成2000时同步更新了自己的版本号为v1.1，下面的版本号在进行check-and-set操作时发现版本号已经更新，所以不能再执行原来的10000-8000，而是使用新的版本号中的2000-5000了，但因为执行的条件（2000-5000<0）不满足所以无法执行，继而拿着新的版本号去执行其他的操作了。
比如抢票就是乐观锁的使用场景，有成百上千的人去抢同一张票，但是最后只有一个人能拿到。
因为Redis就是利用乐观锁的机制来处理事务的，所以现在来说怎么在Redis中实现乐观锁。
在执行multi之前，先执行watch key1 [key2],可以监视一个(或多个) key ，如果在事务执行之前这个(或这些) key 被其他命令所改动，那么事务将被打断。
来演示一下：
先在1号终端用watch监视balance，并且开启事务操作：

再在2号终端用watch监视balance，并且也开启事务操作：

（注意balance的值是100）
现在我们在1号终端将balance的值加上10：

然后在2号终端将balance的值加上20：

现在我们执行1号终端中的队列：

可以看见成功了，那么现在我们也去执行2号终端的操作;

可以看见没有成功，这就是因为Redis中乐观锁机制的存在。
还有一个unwatch命令，它的作用是：
取消 WATCH 命令对所有 key 的监视。
如果在执行 WATCH 命令之后，EXEC 命令或DISCARD 命令先被执行了的话，那么就不需要再执行UNWATCH 了。
Redis事务的三特性：