Redis事务的理解

介绍

Redis通过MULTI、EXEC、WATCH等命令来实现事务功能。
事务提供了一种将多个命令请求打包，然后一次性、按照顺序地执行多个命令的机制，并且在事务执行期间，服务器不会因为其他客户端请求而中断事务的执行功能，他会将事务中的所有命令都执行完毕，才会去处理客户端的请求

通过MULTI和EXEC这两个命令就能完成一个简单的事务

• MULTI开启事务的标志
• EXEC事务结束的标志

127.0.0.1:6379> set name "zhangsan"
QUEUED
127.0.0.1:6379> set age 18
QUEUED
127.0.0.1:6379> get name
QUEUED
127.0.0.1:6379> get age
QUEUED
127.0.0.1:6379> exec
1) OK
2) OK
3) "zhangsan"
4) "18"

事务执行的原理

一个事务从开始到结束通常会经历以下三个阶段：

1. 事务开始
2. 命令入队
3. 事务执行

1. 事务开始

MULTI命令的执行 标志着事务的开始
MULTI命令将客户端从非事务状态切换到事务状态，主要是通过修改客户端的一个状态标志位来完成的

2. 命令入队

当一个客户端处于非事务状态时，客户端发送的命令会立即被服务器执行
但是，当一个客户端切换到事务状态之后，服务器就会根据发来的不同命令执行不同的操作：

• 如果是客户端发送的MULTI、DISCARD、WATCH、EXEC四个命令中的一个时，服务器会立即执行这个命令
• 除了以上四个命令之外的所有命令，服务器并不会立即执行这个命令，而是将这个命令放入到一个事务队列里，向客户端返回QUEUED回复

3. 事务队列

处于事务状态的客户端，在服务端都会有一个事务队列，这个队列中按照先进先出的方式保存了客户端的命令，同时还会有一个变量来表示队列的长度，即命令的数量。

4. 执行事务

当一个处于事务状态的客户端发送EXEC命令时，这个EXEC命令将立即被服务器执行。
服务器会遍历这个客户端的事务队列，顺序执行队列中的所有命令，最后将执行的结果全部返回给客户端，这个过程是不会被打断的
也就是说，客户端只有在发送了EXEC命令后，才会真正得到前面那些命令的结果。

WATCH命令

WATCH命令是一个乐观锁，他可以在EXEC命令执行之前，监视任意数量的key，并在EXEC命令执行时，会检查这些key是否已经被修改过了，如果是，则服务端将拒绝执行这个事务，并向客户端返回代表失败的标识。

即，WATCH命令会监视指定的key，如果在本客户端事务的过程中，其他客户端修改了这个key对应的value，那么在本客户端执行EXEC时，WATCH就会发现先检测有没有被修改过，如果是，则服务端拒绝执行这个客户端的事务
WATCH命令必须在MULTI和EXEC之外，不能在这两者之间
正确示例

127.0.0.1:6379> WATCH name
OK
127.0.0.1:6379> MULTI
OK
127.0.0.1:6379> get name
QUEUED
127.0.0.1:6379> get age
QUEUED
127.0.0.1:6379> exec
(nil)

事务的ACID

在关系型数据库中事务有ACID的特性：

• 原子性：一组命令要么全部执行，要么全部不执行
• 一致性：事务开启前后完成后，数据是一致的
• 隔离性：一个数据在不同事务中是如何表现的
• 持久性：数据是持久的，不会消失的

在Redis中，也能说满足这四个特征，并不是完全满足。

原子性

对于关系型数据库来说，事务中的多个操作当做一个整体，要么全部执行，要么全部不执行。
对于Redis事务来说，事务队列中的命令要么就是全部要执行，要么一个都不执行，因此Redis是具有原子性的。
当客户端的一条命令是语法错误的，那么在入事务队列时，就会报错，整个事务队列中的命令就不会执行

Redis事务与关系型数据库事务的最大区别是，Redis事务不支持回滚机制，当服务端执行事务队列里的命令时，一条命令出现了错误，下面的命令依然会被执行下去，直到整个事务队列执行完成

一致性

“一致”指的是，数据在事务前后，数据是正确的，符合业务逻辑及数据库本身的规范
我说一下数据可能会不一致的情况：

• 命令入队错误，一个客户端事务的命令在入队时，若此命令非法（不存在或语法错误），则Redis拒绝执行这个客户端端的事务。对于这个事务来说，事务执行前后的数据是一致的。
• 出队错误，服务端在执行事务队列中的命令时，此时发生了错误，由于不存在回滚机制，同时事务也不能被中断，因此下面的命令还是会继续执行，此时事务执行完成后，可能会导致数据不一致性。
• 服务器宕机：
  • 服务器并没有开启持久化机制，那么重启后内存中的数据是空的，这么来看数据是一致的。
  • 如果是RDB持久化模式下，那么在重启时，会恢复数据，从之前的一致性恢复到另一个一致性状态，也算是一致的。
  • 如果是AOF持久化模式下，那么在重启时，同样会恢复数据，此时的数据也是一个一致性状态

隔离性

因为Redis使用的是单线程的方式来执行事务，同一时刻，只有一个事务在执行，同时事务执行期间不会被打断，因此事务之间是具有隔离性的

持久性

Redis事务的持久性是由Redis的持久化机制来来保障的。

• 当服务器没有开启持久化模式，那么事务不具有持久性，一旦宕机，数据就会消失
• 当服务器在RDB持久化模式下，服务器只会在特定条件被满足时，才会执行BGSAVE命令来持久化数据，保存的是某一时刻的数据，并且异步BGSAVE下，不能保证最新数据第一时间被持久化，因此RDB模式下，事务不具有持久性
• 当服务器在AOF持久化同步追加模式下，服务器每执行一条命令，就会将这个命令追加到AOF日志中，因此在同步AOF模式下，事务具有持久性。
• 当处于AOF异步追加模式下，并不能保证最新的命令被立即追加到AOF日志中，因此在异步AOF模式下，事务不具有持久性