Redis系列(九):Redis的事务机制

申城异乡人 2020/7/29 17:03:55

提到事务,相信大家都不陌生,事务的ACID四大特性,也是面试时经常问的,不过一般情况下,我们可能想到的是传统关系型数据库的事务,其实,Redis也是提供了事务机制的,本篇博客就来讲解下Redis的事务机制。 1. 事务演示 Redis的事务提供了一种将多个命令请求打包,然后一…

提到事务,相信大家都不陌生,事务的ACID四大特性,也是面试时经常问的,不过一般情况下,我们可能想到的是传统关系型数据库的事务,其实,Redis也是提供了事务机制的,本篇博客就来讲解下Redis的事务机制。

1. 事务演示

Redis的事务提供了一种将多个命令请求打包,然后一次性、按顺序性地执行多个命令的机制。

在事务执行期间,服务器不会中断事务而去执行其它客户端的命令请求,它会将事务中的所有命令执行完毕,然后才去处理其它客户端的命令请求。

下图展示了一个Redis事务的执行过程:

可以看出,事务以MULTI命令开始,然后将多个命令放到事务当中,最后由EXEC命令将这个事务提交给服务器执行。

2. 事务实现原理

一个事务从开始到结束会经历以下3个阶段:

  1. 事务开始
  2. 命令入队
  3. 事务执行

2.1 事务开始

MULTI命令的执行标志着事务的开始。

执行完该命令后,客户端状态的flags属性会打开REDIS_MULTI标识,表示该客户端从非事务状态切换至事务状态。

2.2 命令入队

当一个客户端处于非事务状态时,这个客户端发送的命令会立即被服务器执行:

当一个客户端处于事务状态时,这个客户端发送的命令,服务器是否会立即执行,分为以下2种情况:

  1. 如果客户端发送的命令为MULTIEXECWATCHDISCARD四个命令中的其中1个,服务器会立即执行这个命令。
  2. 如果客户端发送的命令为以上4个命令外的其它命令,服务器不会立即执行这个命令,而是将其放到事务队列里,然后向客户端返回QUEUED回复。

以上流程可以使用以下流程图来表示:

这里首先提下DISCARD命令,这个命令用于取消事务,放弃执行事务块内的所有命令,如下所示:

然后提下事务队列,每个Redis客户端都有自己的事务状态,事务状态存储在客户端状态的mstates属性里:

事务状态包含1个事务队列和1个已入队命令的数量,如下所示:

事务队列是一个multiCmd类型的数组,数组中的每个multiCmd结构保存了一个已入队命令的相关信息,比如:

  1. 指向命令实现函数的指针,如GET命令、SET命令
  2. 命令的参数
  3. 参数的数量

事务队列以**先进先出(FIFO)**的方式保存入队的命令。

2.3 事务执行

当一个处于事务状态的客户端执行EXEC命令时,服务器会遍历这个客户端的事务队列,执行队列中保存的所有命令(按先入先出顺序),然后将执行命令的结果一次性返回给客户端。

3. WATCH命令的实现原理

WATCH命令用于监视任意数量的数据库键,并在EXEC命令执行时,检测被监视的键是否被修改,如果被修改了,服务器将拒绝执行事务,并向客户端返回空回复。

为了更好的理解,我们做个演示,首先,我们打开客户端1,执行WATCH命令监视键“name”,然后开启一个事务:

此时,先不要执行EXEC命令,打开客户端2,执行以下命令修改“name”键的值:

然后,在客户端1执行EXEC命令时,会返回空回复,因为“name”键的值在客户端2已经被修改:

那么,WATCH命令的实现原理是什么样的呢?我们从以下3个方面来分析:

  1. 使用WATCH命令监视数据库键
  2. 监视机制的触发
  3. 判断事务是否安全

3.1 使用WATCH命令监视数据库键

每个Redis数据库都保存着1个watched_keys字典,这个字典的键是某个被WATCH命令监视的数据库键,字典的值是一个链表,链表中记录了所有监视相应数据库键的客户端。

举个例子,假如客户端1正在监视键“name”,客户端2正在监视键“age”,那么watched_keys字典存储的数据大概如下:

如果此时客户端3执行了以下WATCH命令:

那么watched_keys字典存储的数据就变为:

3.2 监视机制的触发

那么问题来了,既然watched_keys字典存储了被WATCH命令监视的键,那么监视机制是如何被触发的呢?

答案是所有对数据库修改的命令,比如SETLPUSHSADD等,在执行之后都会对watched_keys字典进行检查,如果有客户端正在监视刚刚被命令修改的键,那么所有监视该键的客户端的REDIS_DIRTY_CAS标识将被打开,表示该客户端的事务安全性已经被破坏。

以上图为例,如果键“name”的值被修改,那么客户端1、客户端3的REDIS_DIRTY_CAS标识会被打开。

3.3 判断事务是否安全

最后非常关键的一步是,当服务器接收到一个客户端发来的EXEC命令时,服务器会根据这个客户端是否打开了REDIS_DIRTY_CAS标识来决定是否执行事务,判断的流程图如下所示:

4. 事务执行失败举例

先来看第1个例子,这个事务因为命令入队出错被服务器拒绝执行,事务中的所有命令都不会被执行:

再来看第2个例子,事务入队时出现了不存在的命令,服务器将拒绝执行这个事务:

再来看第3个例子,RPUSH命令在执行期间报错了,但后续命令仍然继续执行,并且之前执行的命令没有受到任何影响:

这个例子也说明Redis事务不支持回滚机制

5. 总结

Redis的事务提供了一种将多个命令打包,然后一次性、有序地执行的机制,

它的原理是多个命令会被入队到事务队列中,然后按先进先出(FIFO)的顺序执行,

并且事务在执行过程中不会被中断,当事务队列中的所有命令都被执行完毕之后,事务才会结束。

6. 参考

黄健宏 《Redis设计与实现》


注:如果觉得本篇博客有任何错误或者更好的建议,欢迎留言,我会及时跟进并更正博客内容!

文章持续更新,欢迎关注微信公众号「申城异乡人」第一时间阅读!

随时随地学软件编程-关注百度小程序和微信小程序
关于找一找教程网

本站文章仅代表作者观点,不代表本站立场,所有文章非营利性免费分享。
本站提供了软件编程、网站开发技术、服务器运维、人工智能等等IT技术文章,希望广大程序员努力学习,让我们用科技改变世界。
[Redis系列(九):Redis的事务机制]http://www.zyiz.net/tech/detail-145340.html

上一篇:【起】Redis 基础篇——基本数据结构之String,Hash

下一篇:关于Redis集群的故障检测和转移

赞(0)

共有 条评论 网友评论

验证码: 看不清楚?
    关注微信小程序
    程序员编程王-随时随地学编程

    扫描二维码或查找【程序员编程王】

    可以随时随地学编程啦!

    技术文章导航 更多>
    扫一扫关注最新编程教程