15天玩转redis —— 第八篇 你不得不会的事务玩法

  我们都知道redis追求的是简单,快速,高效,在这种情况下也就拒绝了支持window平台,学sqlserver的时候,我们知道事务还算是个比较复杂的东西,

所以这吊毛要是照搬到redis中去,理所当然redis就不是那么简单纯碎的东西了,但是呢,事务是我们写程序无法逃避的场景,所以redis作者折衷的写了个简

化版的事务机制,下面我来扯一下它的蛋蛋。

一: 事务实战

  具体到事务是什么,要保证什么。。。这个我想没必要说了,先不管三七二十一,看一下redis手册,领略下它的魔力。

1. multi,exec

还记得sqlserver是怎么玩的吗?一般都是这样的三个步骤,生成事务,产生命令,执行事务,对吧,而对应redis呢??multi就是生成事务,然后

输入redis命令,最后用exec执行命令,就像下面这样:

可以看到,我set完命令之后,反馈信息是QUEUED,最后我再执行exec,这些命令才会真正的执行,就是这么的简单,一切执行的就是那么的顺利,

一点都不拖泥带水,牛逼的不要不要的,可能有些人说,其实事务中还有一个rollback操作,但好像在redis中没有看到,哈哈,牛逼哈,很遗憾是

redis中没有rollback操作,比如下面这样。

在图中我故意用lpush命令去执行string,可想而知自然不会执行成功,但从结果中,你看到什么了呢?两个OK,一个Error,这就是违反了事务

的原子性,对吧,但是我该怎么反驳呢??? 我会说,错你妹啊。。。连个基本的命令都写错了,你搞个毛啊。。。还写个吊毛代码,reids仅仅

是个数据结构服务器,多简单的一件事情,退一万步说,很明显的错误命令它会直接返回的,比如我故意把lpush写成lpush1:

2. watch

  不知道你看完multi后面的三条set命令之后,有没有一种心虚的感觉,怎么说呢,就是只要命令是正确的,redis保证会一并执行,誓死完成

任务,虽然说命令是一起执行的,但是谁可以保证我在执行命令的过程中,其他client不会修改这些值呢???如果修改了这些值,那我的exec

还有什么意义呢???没关系,这种烂大街的需求,redis怎可能袖手旁观???这里的watch就可以助你一臂之力。

WATCH
WATCH key [key ...]

监视一个(或多个) key ,如果在事务执行之前这个(或这些) key 被其他命令所改动,那么事务将被打断。

 上面就是redis手册中关于watch的解释,使用起来貌似很简单,就是我在multi之前,用watch去监视我要修改的key,如果说我在exec之前,

multi之后的这段时间,key被其他client修改,那么exec就会执行失败,返回(nil),就这么简单,我还是来举个例子:

二:原理探索

  关于事务操作的源代码,大多都在redis源码中的multi.c 文件中,接下来我会一个一个的简单剖析一下:

1. multi

  在redis的源代码中,它大概是这么写的:

1 void multiCommand(redisClient *c) {
2     if (c->flags & REDIS_MULTI) {
3         addReplyError(c,"MULTI calls can not be nested");
4         return;
5     }
6     c->flags |= REDIS_MULTI;
7     addReply(c,shared.ok);
8 }

从这段代码中,你可以看到multi只是简单的把redisClient的REDIS_MULTI状态打开,告诉这个redis客户端已经进入事务模式了,对吧。

2. 生成命令

在redisClient中,里面有一个multiState命令:

typedef struct redisClient {
    。。。
    multiState mstate;      /* MULTI/EXEC state */
    。。。
} redisClient;

从注释中你大概也看到了这个命令和multi/exec肯定有关系,接下来我很好奇的看看multiState的定义:

typedef struct multiState {
    multiCmd *commands;     /* Array of MULTI commands */
    int count;              /* Total number of MULTI commands */
    int minreplicas;        /* MINREPLICAS for synchronous replication */
    time_t minreplicas_timeout; /* MINREPLICAS timeout as unixtime. */
} multiState;

从multiState这个枚举中,你可以看到下面有一个*command命令,从注释中可以看到它其实指向的是一个数组,这个数组我想你闭着眼睛都

能想得到吧。。。它就是你的若干条命令啦。。。下面还有一个count,可以看到是实际的commands的总数。

3. watch

为了方便说到后面的exec,这里想说一下watch大概是怎么实现的,在multi.c源代码中是这样写的。

 1 typedef struct watchedKey {
 2     robj *key;
 3     redisDb *db;
 4 } watchedKey;
 5
 6 void watchCommand(redisClient *c) {
 7     int j;
 8
 9     if (c->flags & REDIS_MULTI) {
10         addReplyError(c,"WATCH inside MULTI is not allowed");
11         return;
12     }
13     for (j = 1; j < c->argc; j++)
14         watchForKey(c,c->argv[j]);
15     addReply(c,shared.ok);
16 }
17
18 /* Watch for the specified key */
19 void watchForKey(redisClient *c, robj *key) {
20     list *clients = NULL;
21     listIter li;
22     listNode *ln;
23     watchedKey *wk;
24
25     /* Check if we are already watching for this key */
26     listRewind(c->watched_keys,&li);
27     while((ln = listNext(&li))) {
28         wk = listNodeValue(ln);
29         if (wk->db == c->db && equalStringObjects(key,wk->key))
30             return; /* Key already watched */
31     }
32     /* This key is not already watched in this DB. Let‘s add it */
33     clients = dictFetchValue(c->db->watched_keys,key);
34     if (!clients) {
35         clients = listCreate();
36         dictAdd(c->db->watched_keys,key,clients);
37         incrRefCount(key);
38     }
39     listAddNodeTail(clients,c);
40     /* Add the new key to the list of keys watched by this client */
41     wk = zmalloc(sizeof(*wk));
42     wk->key = key;
43     wk->db = c->db;
44     incrRefCount(key);
45     listAddNodeTail(c->watched_keys,wk);
46 }

这段代码中大概最核心的一点就是:

    /* This key is not already watched in this DB. Let‘s add it */
    clients = dictFetchValue(c->db->watched_keys,key);

就是通过dicFetchValue这个字典方法,从watched_keys中找到指定key的value,而这个value是一个clients的链表,说明人家其实是想找到

关于这个key的所有client,对吧,最后还会将本次key塞入到redisclient的watched_keys字典中,如下代码:

    /* Add the new key to the list of keys watched by this client */
    wk = zmalloc(sizeof(*wk));
    wk->key = key;
    wk->db = c->db;
    incrRefCount(key);
    listAddNodeTail(c->watched_keys,wk);

如果非要画图,大概就是这样:

其中watched_key是个字典结构,字典的键为上面的key1,key2。。。,value为client的链表,这样的话,我就非常清楚某个key

中是被哪些client监视着的,对吧。

4.exec

这个命令里面大概做了两件事情:

<1>:   判断c->flags=REDIS_DIRTY_EXEC 打开与否,如果是的话,取消事务discardTransaction(c),也就是说这个key已经

被别的client修改了。

<2>:   如果没有修改,那么就for循环执行comannd[]中的命令,如下图中的两处信息:

  

好了,大概就这么说了,希望对你有帮助哈~~~

时间: 2024-12-28 02:20:49

15天玩转redis —— 第八篇 你不得不会的事务玩法的相关文章

15天玩转redis —— 第十篇 对快照模式的深入分析

我们知道redis是带有持久化这个能力了,那到底持久化成到哪里,持久化成啥样呢???这篇我们一起来寻求答案. 一:快照模式 或许在用Redis之初的时候,就听说过redis有两种持久化模式,第一种是SNAPSHOTTING模式,还是一种是AOF模式,而且在实战场景下用的最多的 莫过于SNAPSHOTTING模式,这个不需要反驳吧,而且你可能还知道,使用SNAPSHOTTING模式,需要在redis.conf中设置配置参数,比如下面这样: # Save the DB on disk: # # sa

15天玩转redis —— 第六篇 有序集合类型

今天我们说一下Redis中最后一个数据类型 “有序集合类型”,回首之前学过的几个数据结构,不知道你会不会由衷感叹,开源的世界真好,写这 些代码的好心人真的要一生平安哈,不管我们想没想的到的东西,在这个世界上都已经存在着,曾几何时,我们想把所有数据按照数据结构模式组成 后灌输到内存中,然而为了达到内存共享的方式,不得不将这块内存包装成wcf单独部署,同时还要考虑怎么序列化,何时序列互的问题,烦心事太多 太多...后来才知道有redis这么个吊毛玩意,能把高级的,低级的数据结构单独包装到一个共享内存

15天玩转redis —— 第十一篇 让你彻底了解RDB存储结构

接着上一篇说,这里我们来继续分析一下RDB文件存储结构,首先大家都知道RDB文件是在redis的“快照”的模式下才会产生,那么如果 我们理解了RDB文件的结构,是不是让我们对“快照”模式能做到一个心中有数呢??? 一:RDB结构剖析 首先呢,我们要对RDB文件有一个概念性的认识,比如下面画的图一样: 从图中,我们大概看到了RDB文件的一个简要的存储模式,但为了更好的方便对照,我准备save一个empty database,对比一下看看效果: 然后我们用winHex打开dump.rdb文件,看看它

15天玩转redis —— 第四篇 哈希对象类型

redis中的hash也是我们使用中的高频数据结构,它的构造基本上和编程语言中的HashTable,Dictionary大同小异,如果大家往后有什么逻辑需要用 Dictionary存放的话,可以根据场景优先考虑下redis哦,起码可以装装逼嘛,现在我默认你已经有装逼的冲动了,打开redis手册,看看有哪些我们用得到 的装逼方法. 一:常用方法 只要是一个数据结构,最基础的永远是CURD,redis中的insert和update,永远只需要set来替代,比如下面的Hset,如下图: 前面几篇文章我

支撑微博亿级社交平台,小白也能玩转Redis集群(原理篇)

Redis作为一款性能优异的内存数据库,支撑着微博亿级社交平台,也成为很多互联网公司的标配.这里将以Redis Cluster集群为核心,基于最新的Redis5版本,从原理再到实战,玩转Redis集群 常见Redis集群方案 在介绍Redis Cluster集群方案之前,为了方便对比,先简单了解一下业界常见的Redis集群方案: 1 基于客户端分片 Redis Sharding是Redis Cluster出来之前,业界普遍使用的多Redis实例集群方法.其主要思想是基于哈希算法,根据Redis数

Python之路【第十八篇】:Web框架们

Python之路[第十八篇]:Web框架们 Python的WEB框架 Bottle Bottle是一个快速.简洁.轻量级的基于WSIG的微型Web框架,此框架只由一个 .py 文件,除了Python的标准库外,其不依赖任何其他模块. 1 2 3 4 pip install bottle easy_install bottle apt-get install python-bottle wget http://bottlepy.org/bottle.py Bottle框架大致可以分为以下部分: 路

第八篇 迭代器协议和生成器

第八篇 迭代器协议和生成器 阅读目录 一 递归和迭代 二 什么是迭代器协议 三 python中强大的for循环机制 四 为何要有for循环 五 生成器初探 六 生成器函数 七 生成器表达式和列表解析 八 生成器总结 二 什么是迭代器协议 1.迭代器协议是指:对象必须提供一个next方法,执行该方法要么返回迭代中的下一项,要么就引起一个StopIteration异常,以终止迭代 (只能往后走不能往前退) 2.可迭代对象:实现了迭代器协议的对象(如何实现:对象内部定义一个__iter__()方法)

Python之路【第八篇】:堡垒机实例以及数据库操作

Python之路[第八篇]:堡垒机实例以及数据库操作 堡垒机前戏 开发堡垒机之前,先来学习Python的paramiko模块,该模块机遇SSH用于连接远程服务器并执行相关操作 SSHClient 用于连接远程服务器并执行基本命令 基于用户名密码连接: + import paramiko transport = paramiko.Transport(('hostname', 22)) transport.connect(username='wupeiqi', password='123') ssh

第二十二篇:再写Windows驱动,再玩Windbg---NET

2011年到现在,就没再怎么搞过Windows驱动了. 最近, 由于项目需要, 试着改一改一个显卡驱动(KMDOD), 从实践上证明, 我在理论上对一个驱动的架构的正确与否.(USB Display = KMDOD + AVStream). 其中, KMDOD是完成显示的部分功能, 完成其中的VidPN(Video present network), 将驱动中原来的POST物理设备转变为USB物理设备. 而AVStream之所以这样提出, 完成是由于USB Video class的启发, 要不然