redis 事务

Posted 2020-09-30 Aiapple

事务相关命令

---

 

 

Redis通过multi,discard，exec和watch四个命令来实现事务功能，

 

一般事务

• multi
• discard
• exec

 

特殊：watch

 

服务器在执行完事务中的所有命令之后，才会继续处理其他客户端的其他命令

 

 

事务由multi开启，将多个命令入队到事务中，最后exec命令触发事务，一并执行性：

一个事务从开始到执行会经历以下三个阶段：

• 开始事务。
  • multi命令将服务器切换到事务状态
• 命令入队。
  • 将命令放进事务队列里
•  执行事务。
  • 从事务对列中取出命令并执行

 

 

事务队列是一个数组，每个数组项包含三个属性

• 要执行的命令(cmd)
• 命令的参数(argv)
• 参数的个数(argc)

 

例子：

举个例子，如果客户端执行以下命令：

redis> MULTI
OK
redis> SET book-name "Mastering C++ in 21 days"
QUEUED
redis> GET book-name
QUEUED
redis> SADD tag "C++" "Programming" "Mastering Series"
QUEUED
redis> SMEMBERS tag
QUEUED
 

　　

程序为客户端创建一下事务队列

 

exec,discard,multi,watch 是不放入事务队列中的，而是直接执行的。

 

事务队列的执行结果，放入回复队列中，当执行exec命令会将回复队列作为自己的执行结果放回客户端，

并从事务状态返回到非事务状态。

 

无论在事务状态下，还是在非事务状态下，Redis 命令都由同一个函数执行，所以它们共享很

多服务器的一般设置，比如 AOF 的配置、 RDB 的配置，以及内存限制，等等

 

事务中命令和普通命令的区别

• 非事务状态下的命令以单个命令为单位执行，前一个命令和后一个命令的客户端不一定是同一个；
  • 而事务状态则是以一个事务为单位，执行事务队列中的所有命令：
  • 除非当前事务执行完毕，否则服务器不会中断事务，也不会执行其他客户端的其他命令。
• 在非事务状态下，执行命令所得的结果会立即被返回给客户端；
  • 而事务则是将所有命令的结果集合到回复队列，再作为 EXEC 命令的结果返回给客户端

 

Redis 的事务是不可嵌套的，处于事务状态的客户端在发送multi，则服务器只会返回一个简单错误不做任何操作，

继续等待其他命令入队。

 

DISCARD

• 命令用于取消一个事务，它清空客户端 的整个事务队列，然后将客户端从事务状态调回非事务状态

 

WATCH

• 只能在客户端进入事务状态之前执行，在事务状态下发送 WATCH 命令会引发一个简单错误，不会做其他改变
• 命令用于在事务开始之前监视任意数量的键：
  • 当调用 EXEC 命令执行事务时，如果任意一个被监视的键已经被其他客户端修改了，
  • 那么整个事务不再执行，直接返回失败。
  • watch一个key，这个key只能是自己改动，别人不能改，如果别人改了，我就不玩儿了。
  • 也就是事务的安全性

 

WATCH命令的实现

 

存储

watch_keys 字典，字典的键是这个数据库被监控的键值，而字典的值则是一个链表，链表保存所有监视这个键的客户端。

 

 

watch 触发

在任何对数据库键空间（ key space）进行修改的命令成功执行之后（比如 FLUSHDB 、 SET、DEL 、LPUSH 、SADD 、ZREM ，诸如此类），

multi.c/touchWatchKey 函数都被调用，检查数据库的watch_keys字典，看是否有客户端在监视已经被命令修改的键。

如果有， 程序将所有监视这个/这些被修改键的客户端的 REDIS_DIRTY_CAS 选项打开，表明事务安全性已经被破坏。

 

 

当客户端发送exec命令，触发事务执行性，服务器会对客户端状态进行检查：

REDIS_DIRTY_CAS

• 被打开事务安全性已经被破坏，放弃事务，返回执行失败
• 否则，服务器执行所有事务

 

最后，当一个客户端结束它的事务时，无论事务是成功执行，还是失败，watched_keys字典中和这个客户端相关的资料都会被清除。

 

事务的ACID性质

---

在传统的关系式数据库中，常常用 ACID 性质来检验事务功能的安全性。

Redis 事务保证了其中的一致性（ C）和隔离性（ I），但并不保证原子性（ A）和持久性（ D）

 

原子性(Atomicity)

事务中命令要么全部执行成功，有一条失败则全部回滚

 

单个 Redis 命令的执行是原子性的，但 Redis 没有在事务上增加任何维持原子性的机制，所以Redis事务的执行并不是原子性的

如果 Redis 服务器进程在执行事务的过程中被停止，那么事务执行失败，但是不会回滚。

 

一致性(Consistency)

redis的一致性问题分三部分

• 入队错误
• 执行错误
• redis进程被终结

 

入队错误

客户端向服务器发送了错误的命令。

• 服务器将想客户端返回出错信息，并将客户端设为REDIS_DIRTY_EXEC状态。
• 当执行exec命令时，Redis拒绝执行状态为 REDIS_DIRTY_EXEC 的事务。
• 因此，带有不正确入队命令的事务不会被执行，也不会影响数据库的一致性

 

执行错误

对一个不同类型的 key 执行了错误的操作

• Redis 只会将错误包含在事务的结果中
• 这不会引起事务中断或整个失败
• 不会影响已执行事务命令的结果
• 也不会影响后面要执行的事务命令
• 所以它对事务的一致性也没有影响

 

redis进程被终结

Redis 进程被终结 那么

根据 Redis 所使用的持久化模式，可能有以下情况出现：

• 内存模式
  • 如果 Redis 没有采取任何持久化机制，那么重启之后的数据库总是空白的，所以数据总是一致的。
• RDB模式
  • 在执行事务时，Redis 不会中断事务去执行保存 RDB 的工作，只有在事务执行之后，保存 RDB 的工作才有可能开始。
  • 所以当 RDB 模式下的 Redis 服务器进程在事务中途被杀死时，事务内执行的命令，不管成功了多少，都不会被保存到 RDB文件里。
  • 恢复数据库需要使用现有的 RDB 文件，而这个 RDB 文件的数据保存的是最近一次的数据库快照（ snapshot），所以它的数据可能不是最新的
    • 但只要 RDB 文件本身没有因为其他问题而出错，那么还原后的数据库就是一致的。
• AOF模式
  • 因为保存 AOF 文件的工作在后台线程进行，所以即使是在事务执行的中途，保存 AOF 文件的工作也可以继续进行
  • 因此，根据事务语句是否被写入并保存到 AOF文件，有以下两种情况发生：
    • 如果事务语句未写入到 AOF 文件，或 AOF 未被 SYNC 调用保存到磁盘
      • 那么当进程被杀死之后，Redis 可以根据最近一次成功保存到磁盘的 AOF 文件来还原数据库
      • 只要 AOF 文件本身没有因为其他问题而出错，那么还原后的数据库总是一致的，但其中的数据不一定是最新的
    • 如果事务的部分语句被写入到 AOF 文件，并且 AOF 文件被成功保存
      • 那么不完整的事务执行信息就会遗留在 AOF 文件里
      • 当重启 Redis 时，程序会检测到 AOF 文件并不完整，Redis 会退出，并报告错误
        • 需要使用 redis-check-aof 工具将部分成功的事务命令移除之后，才能再次启动服务器。
        • 还原之后的数据总是一致的，而且数据也是最新的（直到事务执行之前为止）。

 

隔离性(lsolation)

Redis 是单进程程序，并且它保证在执行事务时，不会对事务进行中断，事务可以运行直到执

行完所有事务队列中的命令为止。因此，Redis 的事务是总是带有隔离性的。

 

 

持久性(Durability)

因为事务不过是用队列包裹起了一组 Redis 命令，并没有提供任何额外的持久性功能，所以事

务的持久性由 Redis 所使用的持久化模式决定：

• 在单纯的内存模式下，事务肯定是不持久的。
• 在RDB模式下，服务器可能在事务执行之后,RDB文件更新之前的这段时间失败，所以RDB模式下的Redis 事务也是不持久的
• 在AOF的“总是 SYNC ”模式下，事务的每条命令在执行成功之后，都会立即调用 fsync或 fdatasync 将事务数据写入到 AOF 文件。
  • 但是，这种保存是由后台线程进行的，主线程不会阻塞直到保存成功，所以从命令执行成功到数据保存到硬盘之间，还是有一段非常小的间隔，所以这种模式下的事务也是不持久的
  • 其他 AOF 模式也和“总是 SYNC ”模式类似，所以它们都是不持久的

 

小结

•  事务提供了一种将多个命令打包，然后一次性、有序地执行的机制。
•  事务在执行过程中不会被中断，所有事务命令执行完之后，事务才能结束。
•  多个命令会被入队到事务队列中，然后按先进先出（ FIFO）的顺序执行。
•  带 WATCH 命令的事务会将客户端和被监视的键在数据库的 watched_keys 字典中进行关联，
  • 当键被修改时，程序会将所有监视被修改键的客户端的REDIS_DIRTY_CAS选项打开。
  • 只有在客户端的 REDIS_DIRTY_CAS 选项未被打开时，才能执行事务，否则事务直接返回失败。
•  Redis 的事务保证了 ACID 中的一致性（ C）和隔离性（ I），但并不保证原子性（ A）和持久性（ D）。