Redis事务

Redis事务

Redis 事务简介

Redis 事务的基本功能由 MULTI、EXEC、DISCARD 及 WATCH 等命令实现。其中，

● MULTI 命令用于启动 Redis 的事务，将客户端置为事务状态。

● EXEC 命令用于提交事务，执行从 MULTI 到此命令前面的命令队列，此时客户端变为非事务状态。

● DISCARD 命令用于取消事务，命令执行后，将会清空事务队列中的所有命令，并且客户端从事务状态中退出。你可以把它理解为事务回滚，但是 Redis 数据库并不具有事务回滚机制。

● WATCH 命令用于监视键值对，它使得 EXEC 命令需要有条件地执行，在所有被监视键都没有被修改的前提下，事务才能正常被执行。如果这个被监视的键值对发生了改变，那么事务就不会被执行。

Redis事务本质是一组命令的集合，Redis服务器先序列化这一组命令，然后一次性、按顺序、排他性地串行（逐个）执行这一组命令，并且不会在执行事务的途中去执行其他客户端命令。

Redis事务只能保证一个客户端请求的事务中的命令可以连续地被执行

当服务器接收到客户端发送过来的命令是 MULTI、EXEC、WATCH、DISCARD 4 个命令中的任意一个时，服务器会立即执行这个命令。

相反，当服务器接收到客户端发送过来的命令是 MULTI、EXEC、WATCH、DISCARD 4 个命令以外的其他命令时，服务器不会立即执行这个命令，而是将该命令放入一个事务队列中，然后返回 QUEUED 标识给客户端。

file

每个 Redis 客户端都有自己的事务状态，而 mstate 属性就保存了这个客户端的事务状态。事务状态由一个事务队列和一个入队命令的计数器组成。其中，事务队列是一个 multiCmd 类型的结构体数组，它采用先进先出（FIFO）的方式保存入队的命令，先入队的命令将会被放到数组的前面，先执行；而后入队的命令则被放到数组的后面，后执行。这个数组中的每个 multiCmd 结构都保存了一个入队命令的信息，具体包括指向命令实现函数的指针、命令的参数及参数数量等。

ACID 特性

原子性：当客户端使用 MULTI 命令成功开启一个事务上下文，执行 EXEC 命令，中间入队列的多个命令要不全部执行成功，要不全部失败。

当客户端处于事务开启状态时，每进入一条命令，都会返回一个内容为 QUEUED 的结果回复

在执行 EXEC 命令后，将会以数组的方式返回执行的结果，数组中的每个元素都是事务中的命令执行结果。结果的输出顺序与开启事务后命令进入队列的先后顺序一致。

然而 Redis 数据库并不支持事务回滚。向Redis事务队列中插入命令，如果遇到命令格式错误，入队失败，则会导致整个事务执行失败。如果遇到事务中某个命令的语法格式正确，但在执行时因为类型或者键不存在而报错，那么它的整个事务也会继续执行下去，而不是终止执行，直到这个事务的所有命令执行完毕为止。

一致性：事务的一致性说的是，数据库在执行事务之前是一致的，在执行事务之后，不管事务是执行成功还是执行失败，数据库中的数据也应该具有一致性。

当存在错误命令，或者命令格式错误。服务器会拒绝执行入队过程中出现错误的事务，导致了事务执行失败，从而保证了数据库的一致性。

当命令入队成功，但在执行过程中发生了错误。如 INCRBY username 8 命令，那么执行错误的命令会被服务器检测出来，并做相应的错误处理，所以这些执行错误的命令并不会影响其他命令的执行，也不会修改数据库，对事务的一致性并不会产生影响。

当发生突发情况（如断电、服务器停机、服务器崩溃等），导致事务执行出错。此时常常会根据服务器所使用的持久化方式来保证数据库的一致性，具体如下。

➢ 服务器没有开启持久化，在服务器重启时，数据库中将没有任何数据，此时可以保证数据库的一致性。

➢ 服务器开启了 RDB 或 AOF 持久化，在执行事务的过程中，发生故障，不会引起数据库的不一致性。RDB 或 AOF 文件中保存了数据库数据，可以根据 RDB 或 AOF 文件来将数据还原到事务执行之前的状态。如果开启了 RDB 或 AOF 持久化方式，但是找不到 RDB 或 AOF 文件，那么在服务器重启后，数据库会是空白的，也能保证数据库的一致性。

隔离性：Redis 数据库是采用单进程单线程模型实现的键值对存储数据库，它在执行事务命令及其他相关命令时，采用的就是单线程方式。在执行事务的过程中，服务器可以保证这个事务不会被中断，所以 Redis 事务总是以串行方式实现的，在上一个事务没有执行完之前，其他命令是不会被执行的，这就是 Redis 事务的隔离性。

持久性：Redis 数据库是采用单进程单线程模型实现的键值对存储数据库，它在执行事务命令及其他相关命令时，采用的就是单线程方式。在执行事务的过程中，服务器可以保证这个事务不会被中断，所以 Redis 事务总是以串行方式实现的，在上一个事务没有执行完之前，其他命令是不会被执行的，这就是 Redis 事务的隔离性。

●如果 Redis 服务器没有采用任何持久化方式，那么事务不具有持久性。假如服务器发生故障（如停机、断电、崩溃），将会丢失服务器上包括事务数据在内的所有数据。

● 如果 Redis 服务器使用了 AOF 持久化方式：

➢ 当 Redis 配置文件（redis.conf）中的 appendfsync 属性的值为 always 时，可以保证 Redis 事务具有持久性。每当服务器执行完相关命令后，包括事务命令在内，程序都会调用执行 sync 同步函数，将命令数据及时保存到系统硬盘中，这就保证了事务的持久性。

➢ 当 Redis 配置文件中的 appendfsync 属性的值为 everysec 时，服务器程序会每隔 1 秒执行一次数据同步操作，并将数据保存到硬盘中。如果服务器发生停机故障，可能刚好发生在数据等待同步的那 1 秒之内，就会导致数据丢失，因此无法保证事务的持久性。

➢ 当 Redis 配置文件中的 appendfsync 属性的值为 no 时，服务器命令数据同步保存到硬盘中的操作将由操作系统来控制，因此，事务数据在同步的过程中，可能会因为一些原因而丢失，这种情况也不能保证事务的持久性。后面的章节将会详细介绍 Redis 的持久化。

● 如果 Redis 服务器使用了 RDB 持久化方式，那么，只有在特定的保存条件被满足时，服务器才会执行 BGSAVE 命令，实现数据的保存。而如果是异步执行 BGSAVE 命令，那么服务器并不能保证在第一时间将事务数据保存到硬盘中，因此也就不能保证事务的持久性。换句话说，RDB 持久化方式不能保证事务具有持久性。

悲观锁和乐观锁

悲观锁：每次去数据库中取数据的时候都会认为别人会修改这些数据，所以它每次取数据的时候都会给这些数据加锁，不让别人使用，别人想拿这些数据就会阻塞直到它释放锁、别人获得锁为止。在传统的关系型数据库中，使用了大量的悲观锁，如行锁、表锁、读锁、写锁等

乐观锁：每次去数据库中取数据的时候，都认为别人不会修改这些数据，所以它不会给这些数据加锁。但是它也很细心，每次在更新这些数据的时候，都会判断一下在此期间有没有别人更新过这些数据。如果别人更新过这些数据，它就会放弃本次更新；相反，如果别人没有更新过这些数据，它就会更新这些数据。乐观锁比较适用于多读的应用类型，可以提高吞吐量。（下文中WATCH 命令就是一个乐观锁）

事务的 WATCH 命令

事务的 WATCH 命令用于监视事务中的命令。有了 WATCH 命令的监视，就会使得 EXEC 命令需要有条件地执行，只有在所有被 WATCH 命令监视的数据库键都没有被修改的前提下，这个事务才能执行成功。如果所有被监视的数据库键中有任意一个数据库键被修改，那么这个事务都会执行失败。

使用 UNWATCH 命令取消 WATCH 命令对数据库键的监视

使用方法：

WATCH name age＃WATCH 命令同时监视 name 键和 age 键
MULTI＃开启事务上下文
...