Redis之事务

【本文详细介绍了非关系型数据库Redis中事务的概念和具体实例，欢迎读者朋友们阅读、转发和收藏！】

1 基本概念

Redis 中的事务 (transaction) 是一组命令的集合。事务同命令一样都是 Redis 最小的执行单位，一个事务中的命令要么都执行，要么都不执行。Redis 事务的实现需要用到 MULTI 和 EXEC 两个命令，事务开始的时候先向 Redis 服务器发送 MULTI 命令，然后依次发送需要在本次事务中处理的命令，最后再发送 EXEC 命令表示事务命令结束。

redis 对事务的支持目前还比较简单。redis 只能保证一个 client 发起的事务中的命令可以连续的执行，而中间不会插入其他 client 的命令。由于 redis 是单线程来处理所有 client 的请求的所以做到这点是很容易的。

1.1 事务的执行

一般情况下 redis 在接受到一个 client 发来的命令后会立即处理并返回处理结果，但是当一个 client 在一个连接中发出 multi 命令后，这个连接会进入一个事务上下文，该连接后续的命令并不是立即执行，而是先放到一个队列中。当从此连接受到 exec 命令后， redis 会顺序的执行队列中的所有命令。并将所有命令的运行结果打包到一起返回给 client. 然后此连接就结束事务上下文。

1.2 事务的取消

我们可以调用 discard 命令来取消一个事务。

虽说 redis 事务在本质上也相当于序列化隔离级别的了，但是由于事务上下文的命令只排队并不立即执行，所以事务中的写操作不能依赖事务中的读操作结果。

1.3 实现 CAS

Redis 使用乐观锁来实现了 CAS(check and set) 操作，在 redis 2.1 后添加了 watch 命令，可以用来实现 Redis 事务中的 CAS 操作。

watch 监视指定的 key ，这个 key 可以有多个。当被 watched 的 key 在事务 exec 前至少有一个发生改变，那么整个事务将跳出， exec 命令返回 (nil) 。

注意 watch 的 key 是对整个连接有效的，事务也一样。如果连接断开，监视和事务都会被自动清除。当然， exec 、 discard 、 unwatch 命令都会清除连接中的所有监视。

1.4 事务的缺陷

redis 的事务实现是如此简单，当然会存在一些问题。

第一个问题是 redis 只能保证事务的每个命令连续执行，但是如果事务中的一个命令失败了，并不回滚其他命令，比如使用的命令类型不匹配。

另一个十分罕见的问题是，当事务的执行过程中，如果 redis 意外的挂了。很遗憾只有部分命令执行了，后面的也就被丢弃了。当然如果我们使用 append-only file 方式持久化， redis 会用单个 write 操作写入整个事务内容。即使是这种方式还是有可能只部分写入了事务到磁盘。发生部分写入事务的情况下， redis 重启时会检测到这种情况，然后失败退出。可以使用 redis-check-aof 工具进行修复，修复会删除部分写入的事务内容。修复完后就能够重新启动了。

我知道你在看哟