面试竟被问到Redis事务，触及知识盲区，脸都绿了

前言

前几天有读者说本身面试被问到Redis的事务，虽然不经常使用，可是面试居然被问到，平时本身没有注意Redis的事务这一块，面试的时候被问到很是很差受。

虽然，这位读者面试最后算是过了，可是薪资方面没有拿到本身理想的薪资。

其实这个也是正常的，通常面试被问到烂大街的，谁还问你啊，专门挑一些不常见的来问你，就是为了压你的薪资。

因此在这里写一篇文章对Redis的事务进行详细的讲解，估计对Redis事务从理解到原理深刻这一篇就够了。

之后面试都不用担忧了再被问道Redis的事务了，这一篇主要讲解Redis事务原理和实操的演练，理解理论的同时也经过实操来证明理论。

事务介绍

Redis事务是一组命令的集合，将多个命令进行打包，而后这些命令会被顺序的添加到队列中，而且按顺序的执行这些命令。

「Redis事务中没有像Mysql关系型数据库事务隔离级别的概念，不能保证原子性操做，也没有像Mysql那样执行事务失败会进行回滚操做」。

这个与Redis的特色：「快速、高效」有着密切的关联，「由于一些列回滚操做、像事务隔离级别那这样加锁、解锁，是很是消耗性能的」。因此，Redis中执行事务的流程只须要简单的下面三个步骤：

1. 开始事务（MULTI）
2. 命令入队
3. 执行事务（EXEC）、撤销事务（DISCARD ）

在Redis中事务的实现主要是经过以下的命令实现的：

命令	功能描述
MULTI	「事务开始的命令」，执行该命令后，后面执行的对Redis数据类型的「操做命令都会顺序的放进队列中」，等待执行EXEC命令后队列中的命令才会被执行
DISCARD	「放弃执行队列中的命令」，你能够理解为Mysql的回滚操做，「而且将当前的状态从事务状态改成非事务状态」。
EXEC	执行该命令后「表示顺序执行队列中的命令」，执行完后并将结果显示在客户端，「将当前状态从事务状态改成非事务状态」。如果执行该命令以前有key被执行WATCH命令而且又被其它客户端修改，那么就会放弃执行队列中的全部命令，在客户端显示报错信息，如果没有修改就会执行队列中的全部命令。
WATCH key	表示指定监视某个key，「该命令只能在MULTI命令以前执行」，若是监视的key被其余客户端修改，「EXEC将会放弃执行队列中的全部命令」
UNWATCH	「取消监视以前经过WATCH 命令监视的key」，经过执行EXEC 、DISCARD 两个命令以前监视的key也会被取消监视

以上就是一个Redis事务的执行过程包含的命令，下面就来详细的围绕着这几个命令进行讲解。

开始事务

MULTI 命令表示事务的开始，当看到OK表示已经进入事务的状态： 该命令执行后客户端会将「当前的状态从非事务状态修改成事务状态」，这一状态的切换是将客户端的flags属性中打开REDIS_MULTI来完成的，该命令能够理解关系型数据库Mysql的BEGIN TRANCATION语句：

命令入队

执行完MULTI命令后，后面执行的操做Redis五种类型的命令都会按顺序的进入命令队列中，该部分也是真正的业务逻辑的部分。

Redis客户端的命令执行后如果当前状态处于事务状态命令就会进入队列中，而且返回QUEUED字符串，表示该命令已经进入了命令队列中，而且「事务队列是以先进先出（FIFO）的方式保存入队的命令」的。 如果当前状态是非事务状态就会当即执行命令，并将结果返回客户端。在事务状态「执行操做事务的命令就会被当即执行」，如EXEC、DISCARD、UNWATCH。 结合上面的分析，Redis执行命令的流程以下图所示： 事务的命令队列中有三个参数分别是：「要执行的命令」、「命令的参数」、「参数的个数」。例如：经过执行以下的命令：

redis> MULTI
OK redis> SET name "黎杜" QUEUED redis> GET name QUEUED 复制代码

那么对应上面的队列中三个参数以下表格所示：

执行的命令	命令的参数	参数的个数
SET	["name", "黎杜"]	2
GET	["name"]	1

执行事务

当客户端执行EXEC命令的时候，上面的命令队列就会被按照先进先出的顺序被执行，固然执行的结果有成功有失败，这个后面分析。

上面说到当客户端处于非事务的状态命令发送到服务端会被当即执行，如果客户端处于事务状态命令就会被放进命令队列。

命令入队的时候，会按照顺序进入队列，队列以先进先出的特色来执行队列中的命令。

如果客户端处于事务状态，执行的是EXEC、DISCARD、UNWATCH这些操做事务的命令，也会被当即执行。 「（1）正常执行」

仍是上面的例子，执行以下的代码：

redis> MULTI
OK redis> SET name "黎杜" QUEUED redis> GET name QUEUED 复制代码

全部的命令进入了队列，当最后执行EXEC，首先会执行SET命令，而后执行GET命令，而且执行后的结果也会进入一个队列中保存，最后返回给客户端：

回复的类型	回复的内容
status code reply	OK
bulk reply	"黎杜"

因此最后你会在客户端看到「OK、黎杜」，这样的结果显示，这个也就是一个事务成功执行的过程。

至此一个事务就完整的执行完成，而且此时客户端也从事务状态更改成非事务状态。

「（2）放弃事务」

固然你也能够放弃执行该事务，只要你再次执行DISCARD操做就会放弃执行这次的事务。具体代码以下所示：

redis> MULTI
OK redis> SET name "黎杜" QUEUED redis> GET name QUEUED redis> DISCARD // 放弃执行事务 OK 复制代码

DISCARD命令取消一个事务的时候，就会将命令队列清空，而且将客户端的状态从事务状态修改成非事务的状态。

「Redis的事务是不可重复的」，当客户端处于事务状态的时候，再次向服务端发送MULTI命令时，直接就会向客户端返回错误。

WATCH 命令

WATCH命令是在MULTI命令以前执行的，表示监视任意数量的key，与它对应的命令就是UNWATCH命令，取消监视的key。

WATCH命令有点「相似于乐观锁机制」，在事务执行的时候，如果被监视的任意一个key被更改，则队列中的命令不会被执行，直接向客户端返回(nil)表示事务执行失败。

下面咱们来演示一下WATCH命令的操做流程，具体实现代码以下：

redis> WATCH num
OK redis> MULTI OK redis> incrby num 10 QUEUED redis> decrby num 1 QUEUED redis> EXEC // 执行成功 复制代码

这个是WATCH命令的正常的操做流程，如果在其它的客户端，修改了被监视的任意key，就会放弃执行该事务，以下图所示：

客户端一	客户端二
WATCH num
MULTI
incrby num 10	get num
	decrby num 1
EXEC
执行失败，返回(nil)

WATCH命令的底层实现中保存了watched_keys 字典，「字典的键保存的是监视的key，值是一个链表，链表中的每一个节点值保存的是监视该key的客户端」。 如果某个客户端再也不监视某个key，该客户端就会从链表中脱离。如client3，经过执行UNWATCH命令，再也不监视key1：

错误处理

上面说到Redis是没有回滚机制的，那么执行的过程，如果不当心敲错命令，Redis的命令发送到服务端没有被当即执行，因此是暂时发现不到该错误。

那么在Redis中的错误处理主要分为两类：「语法错误」、「运行错误」。下面主要来说解一下这两类错误的区别。

「（1）语法错误」

好比执行命令的时候，命令的不存在或者错误的敲错命令、参数的个数不对等都会致使语法错误。

下面来演示一下，执行下面的四个命令，先后的两个命令是正确的，中间的两个命令是错误的，以下所示：

127.0.0.1:6379> multi
OK 127.0.0.1:6379> set num 1 QUEUED 127.0.0.1:6379> set num (error) ERR wrong number of arguments for 'set' command 127.0.0.1:6379> ssset num 3 (error) ERR unknown command 'ssset' 127.0.0.1:6379> set num 2 QUEUED 127.0.0.1:6379> exec (error) EXECABORT Transaction discarded because of previous errors. 复制代码

语法错误是在Redis语法检测的时候就能发现的，因此当你执行错误命令的时候，也会即便的返回错误的提示。

最后，即便命令进入队列，只要存在语法错误，该队列中的命令都不会被执行，会直接向客户端返回事务执行失败的提示。

「（2）运行错误」

执行时使用不一样类型的操做命令操做不一样数据类型就会出现运行时错误，这种错误时Redis在不执行命令的状况下，是没法发现的。

127.0.0.1:6379> multi
OK 127.0.0.1:6379> set num 3 QUEUED 127.0.0.1:6379> sadd num 4 QUEUED 127.0.0.1:6379> set num 6 QUEUED 127.0.0.1:6379> exec 1) OK 2) (error) WRONGTYPE Operation against a key holding the wrong kind of value 3) OK 127.0.0.1:6379> get key "6" 复制代码

这样就会致使，正确的命令被执行，而错误的命令不会不执行，这也显示出Redis的事务并不能保证数据的一致性，由于中间出现了错误，有些语句仍是被执行了。

这样的结果只能程序员本身根据以前执行的命令，本身一步一步正确的回退，所谓本身的烂摊子，本身收拾。

Redis事务与Mysql事务

咱们知道关系性数据库Mysql中具备事务的四大特性：「原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Durability）」。

可是Redis的事务为了保证Redis除了客户端的请求高效，去除了传统关系型数据库的「事务回滚、加锁、解锁」这些消耗性能的操做，Redis的事务实现简单。

原子性中Redis的事务只能保证单个命令的原子性，多个命令就没法保证，如上面索道的运行时错误，即便中间有运行时错误出现也会正确的执行后面正确的命令，不具备回滚操做。

既然没有了原子性，数据的一致性也就没法保证，这些都须要程序员本身手动去实现。

Reids在进行事务的时候，不会被中断知道事务的运行结束，也具备必定的隔离性，而且Redis也能持久化数据。