19.1 事务的实现
把多个Redis命令放到队列中，一次性执行队列里的所有命令。整个过程分为三个阶段：1、事务开始 2、命令入队 3、命令执行
19.1.1 事务开始
做了什么：改变Redis服务端的状态，把Redis服务端的状态由非事务状态切换到事务状态，非事务状态会立即响应并执行客户端的请求，事务状态下会把Redis请求放入队列里并返回QUEUED，代表已经把指令放入队列。
19.1.2 命令入队
19.1.3 事务队列
事务队列维护一个队列，该队列里保存所有在事务状态下已经接受但还未执行并返回的指令。
19.1.4 执行事务
当处于事务状态下的Redis服务端接收到EXEC指令后会执行事务队列里的指令并返回。
19.2 WATCH命令
WATCH是一种乐观锁，之所以称为乐观锁是因为他并没有强制保证WATCH的键不会被修改，它只是在发现WATCH的对象被别的线程修改后拒绝执行事务。与乐观锁相对应的是分布式锁，分布式锁是一种悲观锁。只有在MUTI命令之前执行WATCH才有效，MUTI后执行WATCH会报错。
客户端B修改了name，name在客户端A开启的事务中，当服务端EXEC客户端A的事务队列时，发现name被修改，拒绝执行客户端A的事务队列。
19.2.1 WATCH简单实现原理
Redis服务端维护一个watch_dict，保存所有被监视的key以及监视这些key的客户端ID。下面这张图代表c1 c2客户端监视了name。
所有对数据库进行修改的命令执行完毕后都会检查watched_key。如某个线程修改了name字段，该线程会根据watched_dict找到c1 c2监视name，并打开c1 c2的REDIS_DIRTY_CAS标识，该标识被打开代表该客户端事务安全性被破坏。
当Redis服务端执行某个客户端的EXEC命令时，会先检查 REDIS_DIRTY_CAS标识，只有在该标识没有被打开的情况下才会执行该客户端的事务。
19.3 事务的ACID
Redis事务具有ACI性质，在某种特定持久化模式下也具有D。
19.3.1 原子性
关于原子性，该书给出的结论是：Redis事务的原子性是一种不具有回滚功能的特殊的原子性。虽然特殊但是也具有原子性。原子性的关键在于一个事务中如果有一个语句执行失败，数据库是否会回滚之前已经成功执行的语句。就Redis而言，分为两种情况：
1、Redis命令在加入事务队列前发现错误，此时会“回滚”，之所以加上引号是因为这并不是回滚，因为当事务中一个命令加入Redis事务队列失败后，整个事物队列都不会执行。比如下面的例子，首先把正确的指令加入事务队列，然后把错误的get指令加入事务队列，此时报错，因为这不符合get指令的语法要求，所以当执行EXEC的时候也报错，最后检查test发现没有赋值成功。
2、Redis命令加入事务队列不报错，不回滚。
在事务外面执行set test 456，test为字符串类型。然后开启事务，先执行set a 123，这条指令是正确的。然后执行lpush test 1 2 3 4，这条指令是错误的，因为test已经被设置成了字符串类型。随后执行EXEC，不出意外的报错。虽然执行EXEC报错，但是检查最后的结果发现a被设置成了123，说明在一个事务中，一条执行执行，一条没有执行，你告诉我这是原子性？？？？
总之，最后总结发言
- 加入事务队列的时候发现指令错误，整个事务队列里所有指令都不会执行，此时的Redis事务是具有原子性的。这种错误被称为入队错误。
- 已经加入事务队列，但该指令是错误的。当EXEC执行整个事务的时候，所有正确的指令会执行并产生影响，错误的指令不被执行。且已经执行的正确指令不会回滚。这种错误被称为执行错误。
19.3.2 一致性
根据原子性的分析，Redis不具有一致性。
19.3.3 隔离性
Redis是单线程模型，不会出现并发问题，且Redis保证事务执行过程中不会被打断，因此Redis具有隔离性。
19.3.4 永久性
Redis的事务只是简单的把多个命令放在队列里执行，并不会对持久化造成影响，所以事务的持久性取决于Redis本身的持久性
- 不开启任何持久化配置的情况下，Redis不具有耐久性，掉电即失。
- 只开启RDB持久化，在不显示执行SAVE命令时，两次BGSAVE之间的数据会丢失
- 开启AOF持久化，取决于同步写(appendsync)命令的配置，always下，不会丢失数据，具有持久性；everysec下，最多丢失一秒的诗句，no下，丢失的数据取决于操作系统