Redis事务

前言
Redis是单线程的，指令放在队列中，由一个线程依次完成，因此Redis中不存在像InnoDB引擎那种真正的事务，但是指令的执行顺序会引发类似事务所引发的问题。
举例：有三个客户端a、b、c，依次执行set k1 1，set k1 2，set k1 3命令，当另一个客户端执行get k1命令时，读取到的k1的值和执行get命令的时间有关，有可能得到1，2，3中的任何一个值。

Redis事务的定义
Redis事务是一个单独的隔离操作：事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。
Redis事务的主要作用就是串联多个命令防止别的命令插队。

Multi、Exec、discard
从输入Multi命令开始，输入的命令都会依次进入命令队列中，但不会执行，直到输入Exec后，Redis会将之前的命令队列中的命令依次执行。
组队的过程中可以通过discard来放弃组队。

启动两个客户端连接值6379，红色部分为测试事务的执行过程，然后依次按照蓝色、绿色、黄色部分输入命令，可以看出，get b是我们所期望的值1，而不是后来执行的22。

Redis事务没有原子性，如果组队的命令中有出错的（比如set a aa，incr a），不会影响其他命令的执行，只是执行阶段该命令会保存。但是如果在组队的时候该命令就报错了，如set a，那么exec的时候，整个队列中的命令都会被取消。

事务的问题
有如下图这样的一个场景，有10000元钱，三个人同时使用，导致余额为负数。

解决上述问题有两种解决方法：
1 悲观锁

查询的时候就加锁，其它客户端无法读取该数据。

2 悲观锁

给金额字段加版本号，如初始版本号为v1.0，当第一个客户端执行减8000的命令后，金额字段的版本号改变成了v1.1，当第二个客户端执行减5000的时候，因为第二个客户端读取到金额为10000的时候，该字段版本号是v1.0，而此时变成了v1.1，因此重新读取该字段。

Redis选择使用乐观锁检查版本号的check-and-set机制实现事务

WATCH key [key]
在multi执行之前，先执行WATCH key [key]，可以监视一个或多个key，如果在事务exec之前这些key被其他命令改动，则事务被打断。
如下图，依次执行红色、蓝色、黄色区域的命令，期望的是a经过两次incr，变成2，但是在exec之前，另一个客户端将a的值变成10，由于我们启用了watch a，因此事务被打断无法执行。
之所以会被打断，就是因为redis的check-and-set机制，检查监视key的版本号，发现版本号不对的时候，事务执行就会失败。

执行unwatch取消对keys的监视，如果执行了watch，又执行了exec或者discard，则不需要执行unwatch。

Redis事务的三特性

• 单独的隔离性
  事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。
• 没有隔离级别的概念
  队列中的命令没有提交之前都不会实际的被执行，因为事务提交前任何指令都不会被实际执行，也就不存在“事务内的查询能看到事务内的更新，在事务外查询不能看到”的问题。
• 不保证原子性
  Redis同一个事务中如有有一天命令在执行阶段失败，其他命令依旧会执行成功。