redis 事务

要弄清楚 Redis 有没有事务，其实很简单，上 Rredis 的官网查看文档，发现：

MULTI 、 EXEC 、 DISCARD 和 WATCH 是 Redis 事务相关的命令。事务可以一次执行多个命令， 并且带有以下两个重要的保证：

• 事务是一个单独的隔离操作：事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。

• 事务是一个原子操作：事务中的命令要么全部被执行，要么全部都不执行。

EXEC 命令负责触发并执行事务中的所有命令：

• 如果客户端在使用 MULTI 开启了一个事务之后，却因为断线而没有成功执行 EXEC ，那么事务中的所有命令都不会被执行。
• 另一方面，如果客户端成功在开启事务之后执行 EXEC ，那么事务中的所有命令都会被执行。

但是 最重要的是记住这样一条， 即使事务中有某条/某些命令执行失败了， 事务队列中的其他命令仍然会继续执行 —— Redis 不会停止执行事务中的命令。

 

 

Redis 确实是有事务，不过按照传统的事务定义 ACID 来看，Redis 是不是都具备了 ACID 的特性。

ACID 指的是：

• 原子性
• 一致性
• 隔离性
• 持久性

我们将使用以上 Redis 事务的命令来检验是否 Redis 都具备了 ACID 的各个特征。

1、原子性

事务具备原子性指的是，数据库将事务中多个操作当作一个整体来执行，服务要么执行事务中所有的操作，要么一个操作也不会执行。

①事务队列

首先弄清楚 Redis 开始事务 multi 命令后，Redis 会为这个事务生成一个队列，每次操作的命令都会按照顺序插入到这个队列中。

这个队列里面的命令不会被马上执行，直到 exec 命令提交事务，所有队列里面的命令会被一次性，并且排他的进行执行。

 

 

 

从上面的例子可以看出，当执行一个成功的事务，事务里面的命令都是按照队列里面顺序的并且排他的执行。

但原子性又一个特点就是要么全部成功，要么全部失败，也就是我们传统 DB 里面说的回滚。

当我们执行一个失败的事务：

可以发现，就算中间出现了失败，set abc x 这个操作也已经被执行了，并没有进行回滚，从严格的意义上来说 Redis 并不具备原子性。

②为何 Redis 不支持回滚

这个其实跟 Redis 的定位和设计有关系，先看看为何我们的 MySQL 可以支持回滚，这个还是跟写 Log 有关系，Redis 是完成操作之后才会进行 AOF 日志记录，AOF 日志的定位只是记录操作的指令记录。

而 MySQL 有完善的 Redolog，并且是在事务进行 Commit 之前就会写完成 Redolog，Binlog：

要知道 MySQL 为了能进行回滚是花了不少的代价，Redis 应用的场景更多是对抗高并发具备高性能，所以 Redis 选择更简单，更快速无回滚的方式处理事务也是符合场景。

2、一致性

事务具备一致性指的是，如果数据库在执行事务之前是一致的，那么在事务执行之后，无论事务是否成功，数据库也应该是一致的。

从 Redis 来说可以从 2 个层面看，一个是执行错误是否有确保一致性，另一个是宕机时，Redis 是否有确保一致性的机制。

①执行错误是否有确保一致性

 

依然去执行一个错误的事务，在事务执行的过程中会识别出来并进行错误处理，这些错误并不会对数据库作出修改，也不会对事务的一致性产生影响。

②宕机对一致性的影响

暂不考虑分布式高可用的 Redis 解决方案，先从单机看宕机恢复是否能满意数据完整性约束。

无论是 RDB 还是 AOF 持久化方案，可以使用 RDB 文件或 AOF 文件进行恢复数据，从而将数据库还原到一个一致的状态。

③再议一致性

上面执行错误和宕机对一致性的影响的观点摘自黄健宏 《Redis 设计与实现》。

当在读这章的时候还是有一些存疑的点，归根到底 Redis 并非关系型数据库。

如果仅仅就 ACID 的表述上来说，一致性就是从 A 状态经过事务到达 B 状态没有破坏各种约束性，仅就 Redis 而言不谈实现的业务，那显然就是满意一致性。

但如果加上业务去谈一致性，例如，A 转账给 B，A 减少 10 块钱，B 增加 10 块钱，因为 Redis 并不具备回滚，也就不具备传统意义上的原子性，所以 Redis 也应该不具备传统的一致性。

其实，这里只是简单讨论下 Redis 在传统 ACID 上的概念怎么进行对接，或许，有可能是我想多了，用传统关系型数据库的 ACID 去审核 Redis 是没有意义的，Redis 本来就没有意愿去实现 ACID 的事务。

3、隔离性

隔离性指的是，数据库中有多个事务并发的执行，各个事务之间不会相互影响，并且在并发状态下执行的事务和串行执行的事务产生的结果是完全相同的。

Redis 因为是单线程操作，所以在隔离性上有天生的隔离机制，当 Redis 执行事务时，Redis 的服务端保证在执行事务期间不会对事务进行中断，所以，Redis 事务总是以串行的方式运行，事务也具备隔离性。

4、持久性

事务的持久性指的是，当一个事务执行完毕，执行这个事务所得到的结果被保存在持久化的存储中，即使服务器在事务执行完成后停机了，执行的事务的结果也不会被丢失。

Redis 是否具备持久化，这个取决于 Redis 的持久化模式：

• 纯内存运行，不具备持久化，服务一旦停机，所有数据将丢失。
• RDB 模式，取决于 RDB 策略，只有在满足策略才会执行 Bgsave，异步执行并不能保证 Redis 具备持久化。
• AOF 模式，只有将 appendfsync 设置为 always，程序才会在执行命令同步保存到磁盘，这个模式下，Redis 具备持久化。(将 appendfsync 设置为 always，只是在理论上持久化可行，但一般不会这么操作)

简单总结：

• Redis 具备了一定的原子性，但不支持回滚。
• Redis 不具备 ACID 中一致性的概念。
• Redis 具备隔离性。
• Redis 通过一定策略可以保证持久性。

 

Redis 脚本和事务

从定义上来说， Redis 中的脚本本身就是一种事务， 所以任何在事务里可以完成的事， 在脚本里面也能完成。 并且一般来说， 使用脚本要来得更简单，并且速度更快。

因为脚本功能是 Redis 2.6 才引入的， 而事务功能则更早之前就存在了， 所以 Redis 才会同时存在两种处理事务的方法。

不过我们并不打算在短时间内就移除事务功能， 因为事务提供了一种即使不使用脚本， 也可以避免竞争条件的方法， 而且事务本身的实现并不复杂。