The Little Redis Book中文版

本书的目的是向读者传授掌握Redis所需要的基本知识,如数据结构、 使⽤数据结构、超越数据结构、管理等。我们将会注重于学习Redis的5种数据结构,并研究各种数据建模方法。我们还会接触到一些主要的管理细节和调试技巧。
展开查看详情

1. ⽬ 录 致谢 关于此书 简介 ⼊门 驱动Redis 第1章 - 基础知识 第2章 - 数据结构 第3章 - 使⽤数据结构 第4章 - 超越数据结构 第5章 - 管理 总结 本⽂档使⽤ 书栈(BookStack.CN) 构建 - 1 -

2.致谢 致谢 当前文档 《The Little Redis Book中文版》 由 进击的皇虫 使用 书栈(BookStack.CN) 进行构建, 生成于 2018-01-28。 书栈(BookStack.CN) 仅提供文档编写、整理、归类等功能,以及对文档内容的生成和导出工具。 文档内容由网友们编写和整理,书栈(BookStack.CN) 难以确认文档内容知识点是否错漏。如果您 在阅读文档获取知识的时候,发现文档内容有不恰当的地方,请向我们反馈,让我们共同携手,将知 识准确、高效且有效地传递给每一个人。 同时,如果您在日常生活、工作和学习中遇到有价值有营养的知识文档,欢迎分享到 书栈 (BookStack.CN) ,为知识的传承献上您的一份力量! 如果当前文档生成时间太久,请到 书栈(BookStack.CN) 获取最新的文档,以跟上知识更新换代的 步伐。 文档地址:http://www.bookstack.cn/books/the-little-redis-book 书栈官网:http://www.bookstack.cn 书栈开源:https://github.com/TruthHun 分享,让知识传承更久远! 感谢知识的创造者,感谢知识的分享者,也感谢每一位阅读到此处的 读者,因为我们都将成为知识的传承者。 本⽂档使⽤ 书栈(BookStack.CN) 构建 - 2 -

3.关于此书 关于此书 关于此书 许可证 关于作者 关于译者 致谢 最新版本 关于此书 许可证 《The Little Redis Book》是经由Attribution-NonCommercial 3.0 Unported license许可的,你不需要 为此书付钱。 你可以自由地对此书进行复制,分发,修改或者展示等操作。当然,你必须知道且认可这本书的作者 是Karl Seguin,译者是赖立维,而且不应该将此书用于商业用途。 关于这个许可证的详细描述在这里: http://creativecommons.org/licenses/by-nc/3.0/legalcode 关于作者 作者Karl Seguin是一名在多项技术领域浸淫多年的开发者。他是开源软件计划的活跃贡献者,同时也 是一名技术作者以及业余演讲者。他写过若干关于Radis的文章以及一些工具。在他的一个面向业余游 戏开发者的免费服务里,Redis为其中的评级和统计功能提供了支持:mogade.com。 Karl之前还写了《The Little MongoDB Book》,这是一本免费且受好评,关于MongoDB的书。 他的博客是http://openmymind.net,你也可以关注他的Twitter帐号,via @karlseguin。 关于译者 译者 赖立维 是一名长在天朝的普通程序员,对许多技术都有浓厚的兴趣,是开源软件的支持者, Emacs的轻度使用者。 虽然译者已经很认真地对待这次翻译,但是限于水平有限,肯定会有不少错漏,如果发现该书的翻译 有什么需要修改,可以通过他的邮箱与他联系。他的邮箱是jasonlai256@gmail.com。 本⽂档使⽤ 书栈(BookStack.CN) 构建 - 3 -

4.关于此书 致谢 必须特别感谢Perry Neal一直以来的指导,我的眼界、触觉以及激情都来源于你。你为我提供了无价的 帮助,感谢你。 最新版本 此书的最新有效资源在: http://github.com/karlseguin/the-little-redis-book 中文版是英文版的一个分支,最新的中文版本在: https://github.com/JasonLai256/the-little-redis-book 本⽂档使⽤ 书栈(BookStack.CN) 构建 - 4 -

5.简介 简介 简介 最近几年来,关于持久化和数据查询的相关技术,其需求已经增长到了让人惊讶的程度。可以断言, 关系型数据库再也不是放之四海皆准。换一句话说,围绕数据的解决方案不可能再只有唯一一种。 对于我来说,在众多新出现的解决方案和工具里,最让人兴奋的,无疑是Redis。为什么?首先是因为 其让人不可思议的容易学习,只需要简短的几个小时学习时间,就能对Redis有个大概的认识。还有, Redis在处理一组特定的问题集的同时能保持相当的通用性。更准确地说就是,Redis不会尝试去解决 关于数据的所有事情。在你足够了解Redis后,事情就会变得越来越清晰,什么是可行的,什么是不应 该由Redis来处理的。作为一名开发人员,如此的经验当是相当的美妙。 当你能仅使用Redis去构建一个完整系统时,我想大多数人将会发现,Redis能使得他们的许多数据方 案变得更为通用,不论是一个传统的关系型数据库,一个面向文档的系统,或是其它更多的东西。这 是一种用来实现某些特定特性的解决方法。就类似于一个索引引擎,你不会在Lucene上构建整个程 序,但当你需要足够好的搜索,为什么不使用它呢?这对你和你的用户都有好处。当然,关于Redis和 索引引擎之间相似性的讨论到此为止。 本书的目的是向读者传授掌握Redis所需要的基本知识。我们将会注重于学习Redis的5种数据结构,并 研究各种数据建模方法。我们还会接触到一些主要的管理细节和调试技巧。 本⽂档使⽤ 书栈(BookStack.CN) 构建 - 5 -

6.⼊门 ⼊门 入门 Windows平台 *nix和MacOSX平台 运行和连接Redis 入门 每个人的学习方式都不一样,有的人喜欢亲自实践学习,有的喜欢观看教学视频,还有的喜欢通过阅 读来学习。对于Redis,没有什么比亲自实践学习来得效果更好的了。Redis的安装非常简单。而且通 过随之安装的一个简单的命令解析程序,就能处理我们想做的一切事情。让我们先花几分钟的时间把 Redis安装到我们的机器上。 Windows平台 Redis并没有官方支持Windows平台,但还是可供选择。你不会想在这里配置实际的生产环境,不过在 我过往的开发经历里并没有感到有什么限制。 首先进入https://github.com/dmajkic/redis/downloads,然后下载最新的版本(应该会在列表的最上 方)。 获取zip文件,然后根据你的系统架构,打开 64bit 或 32bit 文件夹。 *nix和MacOSX平台 对于*nix和MacOSX平台的用户,从源文件来安装是你的最佳选择。通过最新的版本号来选择,有效地 址于http://redis.io/download。在编写此书的时候,最新的版本是2.4.6,我们可以运行下面的命令来安 装该版本: 1. wget http://redis.googlecode.com/files/redis-2.4.6.tar.gz 2. tar xzf redis-2.4.6.tar.gz 3. cd redis-2.4.6 4. make (当然,Redis同样可以通过套件管理程序来安装。例如,使用Homebrew的MaxOSX用户可以只键 入 brew install redis 即可。) 如果你是通过源文件来安装,二进制可执行文件会被放置在 src 目录里。通过运行 cd src 可跳转 到 src 目录。 本⽂档使⽤ 书栈(BookStack.CN) 构建 - 6 -

7.⼊门 运行和连接Redis 如果一切都工作正常,那Redis的二进制文件应该已经可以曼妙地跳跃于你的指尖之下。Redis只有少 量的可执行文件,我们将着重于Redis的服务器和命令行界面(一个类DOS的客户端)。首先,让我们 来运行服务器。在Windows平台,双击 redis-server ,在*nix/MacOSX平台则运行 ./redis-server . 如果你仔细看了启动信息,你会看到一个警告,指没能找到 redis.conf 文件。Redis将会采用内置的 默认设置,这对于我们将要做的已经足够了。 然后,通过双击 redis-cli (Windows平台)或者运行 ./redis-cli (*nix/MacOSX平台),启动 Redis的控制台。控制台将会通过默认的端口(6379)来连接本地运行的服务器。 可以在命令行界面键入 info 命令来查看一切是不是都运行正常。你会很乐意看到这么一大组关键字- 值(key-value)对的显示,这为我们查看服务器的状态提供了大量有效信息。 如果在上面的启动步骤里遇到什么问题,我建议你到Redis的官方支持组里获取帮助。 本⽂档使⽤ 书栈(BookStack.CN) 构建 - 7 -

8.驱动Redis 驱动Redis 驱动Redis 驱动Redis 很快你就会发现,Redis的API就如一组定义明确的函数那般容易理解。Redis具有让人难以置信的简单 性,其操作过程也同样如此。这意味着,无论你是使用命令行程序,或是使用你喜欢的语言来驱动, 整体的感觉都不会相差多少。因此,相对于命令行程序,如果你更愿意通过一种编程语言去驱动 Redis,你不会感觉到有任何适应的问题。如果真想如此,可以到Redis的客户端推荐页面下载适合的 Redis载体。 本⽂档使⽤ 书栈(BookStack.CN) 构建 - 8 -

9.第1章 - 基础知识 第1章 - 基础知识 第1章 - 基础知识 数据库(Databases) 命令、关键字和值(Commands, Keys and Values) 查询(Querying) 存储器和持久化(Memory and Persistence) 整体来看(Putting It Together) 小结 第1章 - 基础知识 是什么使Redis显得这么特别?Redis具体能解决什么类型的问题?要实际应用Redis,开发者必须储备 什么知识?在我们能回答这么一些问题之前,我们需要明白Redis到底是什么。 Redis通常被人们认为是一种持久化的存储器关键字-值型存储(in-memory persistent key-value store)。我认为这种对Redis的描述并不太准确。Redis的确是将所有的数据存放于存储器(更多是是 按位存储),而且也确实通过将数据写入磁盘来实现持久化,但是Redis的实际意义比单纯的关键字- 值型存储要来得深远。纠正脑海里的这种误解观点非常关键,否则你对于Redis之道以及其应用的洞察 力就会变得越发狭义。 事实是,Redis引入了5种不同的数据结构,只有一个是典型的关键字-值型结构。理解Redis的关键就 在于搞清楚这5种数据结构,其工作的原理都是如何,有什么关联方法以及你能怎样应用这些数据结构 去构建模型。首先,让我们来弄明白这些数据结构的实际意义。 应用上面提及的数据结构概念到我们熟悉的关系型数据库里,我们可以认为其引入了一个单独的数据 结构——表格。表格既复杂又灵活,基于表格的存储和管理,没有多少东西是你不能进行建模的。然 而,这种通用性并不是没有缺点。具体来说就是,事情并不是总能达到假设中的简单或者快速。相对 于这种普遍适用(one-size-fits-all)的结构体系,我们可以使用更为专门化的结构体系。当然,因此可 能有些事情我们会完成不了(至少,达不到很好的程度)。但话说回来,这样做就能确定我们可以获得 想象中的简单性和速度吗? 针对特定类型的问题使用特定的数据结构?我们不就是这样进行编程的吗?你不会使用一个散列表去 存储每份数据,也不会使用一个标量变量去存储。对我来说,这正是Redis的做法。如果你需要处理标 量、列表、散列或者集合,为什么不直接就用标量、列表、散列和集合去存储他们?为什么不是直接 调用 exists(key) 去检测一个已存在的值,而是要调用其他比O(1)(常量时间查找,不会因为待处理 元素的增长而变慢)慢的操作? 数据库(Databases) 与你熟悉的关系型数据库一致,Redis有着相同的数据库基本概念,即一个数据库包含一组数据。典型 本⽂档使⽤ 书栈(BookStack.CN) 构建 - 9 -

10.第1章 - 基础知识 的数据库应用案例是,将一个程序的所有数据组织起来,使之与另一个程序的数据保持独立。 在Redis里,数据库简单的使用一个数字编号来进行辨认,默认数据库的数字编号是 0 。如果你想切 换到一个不同的数据库,你可以使用 select 命令来实现。在命令行界面里键入 select 1 ,Redis应 该会回复一条 OK 的信息,然后命令行界面里的提示符会变成类似 redis 127.0.0.1:6379[1]> 这样。如 果你想切换回默认数据库,只要在命令行界面键入 select 0 即可。 命令、关键字和值(Commands, Keys and Values) Redis不仅仅是一种简单的关键字-值型存储,从其核心概念来看,Redis的5种数据结构中的每一个都 至少有一个关键字和一个值。在转入其它关于Redis的有用信息之前,我们必须理解关键字和值的概 念。 关键字(Keys)是用来标识数据块。我们将会很常跟关键字打交道,不过在现在,明白关键字就是类 似于 users:leto 这样的表述就足够了。一般都能很好地理解到,这样关键字包含的信息是一个名 为 leto 的用户。这个关键字里的冒号没有任何特殊含义,对于Redis而言,使用分隔符来组织关键 字是很常见的方法。 值(Values)是关联于关键字的实际值,可以是任何东西。有时候你会存储字符串,有时候是整数, 还有时候你会存储序列化对象(使用JSON、XML或其他格式)。在大多数情况下,Redis会把值看做 是一个字节序列,而不会关注它们实质上是什么。要注意,不同的Redis载体处理序列化会有所不同 (一些会让你自己决定)。因此,在这本书里,我们将仅讨论字符串、整数和JSON。 现在让我们活动一下手指吧。在命令行界面键入下面的命令: 1. set users:leto "{name: leto, planet: dune, likes: [spice]}" 这就是Redis命令的基本构成。首先我们要有一个确定的命令,在上面的语句里就是 set 。然后就是 相应的参数, set 命令接受两个参数,包括要设置的关键字,以及相应要设置的值。很多的情况 是,命令接受一个关键字(当这种情况出现,其经常是第一个参数)。你能想到如何去获取这个值 吗?我想你会说(当然一时拿不准也没什么): 1. get users:leto 关键字和值的是Redis的基本概念,而 get 和 set 命令是对此最简单的使用。你可以创建更多的用 户,去尝试不同类型的关键字以及不同的值,看看一些不同的组合。 查询(Querying) 随着学习的持续深入,两件事情将变得清晰起来。对于Redis而言,关键字就是一切,而值是没有任何 意义。更通俗来看就是,Redis不允许你通过值来进行查询。回到上面的例子,我们就不能查询生活 在 dune 行星上的用户。 本⽂档使⽤ 书栈(BookStack.CN) 构建 - 10 -

11.第1章 - 基础知识 对许多人来说,这会引起一些担忧。在我们生活的世界里,数据查询是如此的灵活和强大,而Redis的 方式看起来是这么的原始和不高效。不要让这些扰乱你太久。要记住,Redis不是一种普遍使用(one- size-fits-all)的解决方案,确实存在这么一些事情是不应该由Redis来解决的(因为其查询的限制)。 事实上,在考虑了这些情况后,你会找到新的方法去构建你的数据。 很快,我们就能看到更多实际的用例。很重要的一点是,我们要明白关于Redis的这些基本事实。这能 帮助我们弄清楚为什么值可以是任何东西,因为Redis从来不需要去读取或理解它们。而且,这也可以 帮助我们理清思路,然后去思考如何在这个新世界里建立模型。 存储器和持久化(Memory and Persistence) 我们之前提及过,Redis是一种持久化的存储器内存储(in-memory persistent store)。对于持久化, 默认情况下,Redis会根据已变更的关键字数量来进行判断,然后在磁盘里创建数据库的快照 (snapshot)。你可以对此进行设置,如果X个关键字已变更,那么每隔Y秒存储数据库一次。默认情 况下,如果1000个或更多的关键字已变更,Redis会每隔60秒存储数据库;而如果9个或更少的关键字 已变更,Redis会每隔15分钟存储数据库。 除了创建磁盘快照外,Redis可以在附加模式下运行。任何时候,如果有一个关键字变更,一个单一附 加(append-only)的文件会在磁盘里进行更新。在一些情况里,虽然硬件或软件可能发生错误,但用 那60秒有效数据存储去换取更好性能是可以接受的。而在另一些情况里,这种损失就难以让人接受, Redis为你提供了选择。在第5章里,我们将会看到第三种选择,其将持久化任务减荷到一个从属数据 库里。 至于存储器,Redis会将所有数据都保留在存储器中。显而易见,运行Redis具有不低的成本:因为 RAM仍然是最昂贵的服务器硬件部件。 我很清楚有一些开发者对即使是一点点的数据空间都是那么的敏感。一本《威廉·莎士比亚全集》需要 近5.5MB的存储空间。对于缩放的需求,其它的解决方案趋向于IO-bound或者CPU-bound。这些限制 (RAM或者IO)将会需要你去理解更多机器实际依赖的数据类型,以及应该如何去进行存储和查询。 除非你是存储大容量的多媒体文件到Redis中,否则存储器内存储应该不会是一个问题。如果这对于一 个程序是个问题,你就很可能不会用IO-bound的解决方案。 Redis有虚拟存储器的支持。然而,这个功能已经被认为是失败的了(通过Redis的开发者),而且它 的使用已经被废弃了。 (从另一个角度来看,一本5.5MB的《威廉·莎士比亚全集》可以通过压缩减小到近2MB。当然,Redis 不会自动对值进行压缩,但是因为其将所有值都看作是字节,没有什么限制让你不能对数据进行压缩/ 解压,通过牺牲处理时间来换取存储空间。) 整体来看(Putting It Together) 我们已经接触了好几个高层次的主题。在继续深入Redis之前,我想做的最后一件事情是将这些主题整 合起来。这些主题包括,查询的限制,数据结构以及Redis在存储器内存储数据的方法。 本⽂档使⽤ 书栈(BookStack.CN) 构建 - 11 -

12.第1章 - 基础知识 当你将这3个主题整合起来,你最终会得出一个绝妙的结论:速度。一些人可能会想,当然Redis会很 快速,要知道所有的东西都在存储器里。但这仅仅是其中的一部分,让Redis闪耀的真正原因是其不同 于其它解决方案的特殊数据结构。 能有多快速?这依赖于很多东西,包括你正在使用着哪个命令,数据的类型等等。但Redis的性能测试 是趋向于数万或数十万次操作每秒。你可以通过运行 redis-benchmark (就在 redis-server 和 redis- cli 的同一个文件夹里)来进行测试。 我曾经试过将一组使用传统模型的代码转向使用Redis。在传统模型里,运行一个我写的载入测试,需 要超过5分钟的时间来完成。而在Redis里,只需要150毫秒就完成了。你不会总能得到这么好的收获, 但希望这能让你对我们所谈的东西有更清晰的理解。 理解Redis的这个特性很重要,因为这将影响到你如何去与Redis进行交互。拥有SQL背景的程序员通 常会致力于让数据库的数据往返次数减至最小。这对于任何系统都是个好建议,包括Redis。然而,考 虑到我们是在处理比较简单的数据结构,有时候我们还是需要与Redis服务器频繁交互,以达到我们的 目的。刚开始的时候,可能会对这种数据访问模式感到不太自然。实际上,相对于我们通过Redis获得 的高性能而言,这仅仅是微不足道的损失。 小结 虽然我们只接触和摆弄了Redis的冰山一角,但我们讨论的主题已然覆盖了很大范围内的东西。如果觉 得有些事情还是不太清楚(例如查询),不用为此而担心,在下一章我们将会继续深入探讨,希望你 的问题都能得到解答。 这一章的要点包括: 关键字(Keys)是用于标识一段数据的一个字符串 值(Values)是一段任意的字节序列,Redis不会关注它们实质上是什么 Redis展示了(也实现了)5种专门的数据结构 上面的几点使得Redis快速而且容易使用,但要知道Redis并不适用于所有的应用场景 本⽂档使⽤ 书栈(BookStack.CN) 构建 - 12 -

13.第2章 - 数据结构 第2章 - 数据结构 第2章 - 数据结构 字符串(Strings) 散列(Hashes) 列表(Lists) 集合(Sets) 分类集合(Sorted Sets) 小结 第2章 - 数据结构 现在开始将探究Redis的5种数据结构,我们会解释每种数据结构都是什么,包含了什么有效的方法 (Method),以及你能用这些数据结构处理哪些类型的特性和数据。 目前为止,我们所知道的Redis构成仅包括命令、关键字和值,还没有接触到关于数据结构的具体概 念。当我们使用 set 命令时,Redis是怎么知道我们是在使用哪个数据结构?其解决方法是,每个命 令都相对应于一种特定的数据结构。例如,当你使用 set 命令,你就是将值存储到一个字符串数据 结构里。而当你使用 hset 命令,你就是将值存储到一个散列数据结构里。考虑到Redis的关键字集 很小,这样的机制具有相当的可管理性。 Redis的网站里有着非常优秀的参考文档,没有任何理由去重造轮子。但为了搞清楚这些数据结构的作 用,我们将会覆盖那些必须知道的重要命令。 没有什么事情比高兴的玩和试验有趣的东西来得更重要的了。在任何时候,你都能通过键 入 flushdb 命令将你数据库里的所有值清除掉,因此,不要再那么害羞了,去尝试做些疯狂的事情 吧! 字符串(Strings) 在Redis里,字符串是最基本的数据结构。当你在思索着关键字-值对时,你就是在思索着字符串数据 结构。不要被名字给搞混了,如之前说过的,你的值可以是任何东西。我更喜欢将他们称作“标 量”(Scalars),但也许只有我才这样想。 我们已经看到了一个常见的字符串使用案例,即通过关键字存储对象的实例。有时候,你会频繁地用 到这类操作: 1. set users:leto "{name: leto, planet: dune, likes: [spice]}" 除了这些外,Redis还有一些常用的操作。例如, strlen <key> 能用来获取一个关键字对应值的长 度; getrange <key> <start> <end> 将返回指定范围内的关键字对应值; append <key> <value> 会将value 本⽂档使⽤ 书栈(BookStack.CN) 构建 - 13 -

14.第2章 - 数据结构 附加到已存在的关键字对应值中(如果该关键字并不存在,则会创建一个新的关键字-值对)。不要犹 豫,去试试看这些命令吧。下面是我得到的: 1. > strlen users:leto 2. (integer) 42 3. 4. > getrange users:leto 27 40 5. "likes: [spice]" 6. 7. > append users:leto " OVER 9000!!" 8. (integer) 54 现在你可能会想,这很好,但似乎没有什么意义。你不能有效地提取出一段范围内的JSON文件,或者 为其附加一些值。你是对的,这里的经验是,一些命令,尤其是关于字符串数据结构的,只有在给定 了明确的数据类型后,才会有实际意义。 之前我们知道了,Redis不会去关注你的值是什么东西。通常情况下,这没有错。然而,一些字符串命 令是专门为一些类型或值的结构而设计的。作为一个有些含糊的用例,我们可以看到,对于一些自定 义的空间效率很高的(space-efficient)串行化对象, append 和 getrange 命令将会很有用。对于一 个更为具体的用例,我们可以再看一下 incr 、 incrby 、 decr 和 decrby 命令。这些命令会增长 或者缩减一个字符串数据结构的值: 1. > incr stats:page:about 2. (integer) 1 3. > incr stats:page:about 4. (integer) 2 5. 6. > incrby ratings:video:12333 5 7. (integer) 5 8. > incrby ratings:video:12333 3 9. (integer) 8 由此你可以想象到,Redis的字符串数据结构能很好地用于分析用途。你还可以去尝试增 长 users:leto (一个不是整数的值),然后看看会发生什么(应该会得到一个错误)。 更为进阶的用例是 setbit 和 getbit 命令。“今天我们有多少个独立用户访问”是个在Web应用里常 见的问题,有一篇精彩的博文,在里面可以看到Spool是如何使用这两个命令有效地解决此问题。对于 1.28亿个用户,一部笔记本电脑在不到50毫秒的时间里就给出了答复,而且只用了16MB的存储空间。 最重要的事情不是在于你是否明白位图(Bitmaps)的工作原理,或者Spool是如何去使用这些命令,而 是应该要清楚Redis的字符串数据结构比你当初所想的要有用许多。然而,最常见的应用案例还是上面 我们给出的:存储对象(简单或复杂)和计数。同时,由于通过关键字来获取一个值是如此之快,字 符串数据结构很常被用来缓存数据。 本⽂档使⽤ 书栈(BookStack.CN) 构建 - 14 -

15.第2章 - 数据结构 散列(Hashes) 我们已经知道把Redis称为一种关键字-值型存储是不太准确的,散列数据结构是一个很好的例证。你 会看到,在很多方面里,散列数据结构很像字符串数据结构。两者显著的区别在于,散列数据结构提 供了一个额外的间接层:一个域(Field)。因此,散列数据结构中的 set 和 get 是: 1. hset users:goku powerlevel 9000 2. hget users:goku powerlevel 相关的操作还包括在同一时间设置多个域、同一时间获取多个域、获取所有的域和值、列出所有的域 或者删除指定的一个域: 1. hmset users:goku race saiyan age 737 2. hmget users:goku race powerlevel 3. hgetall users:goku 4. hkeys users:goku 5. hdel users:goku age 如你所见,散列数据结构比普通的字符串数据结构具有更多的可操作性。我们可以使用一个散列数据 结构去获得更精确的描述,是存储一个用户,而不是一个序列化对象。从而得到的好处是能够提取、 更新和删除具体的数据片段,而不必去获取或写入整个值。 对于散列数据结构,可以从一个经过明确定义的对象的角度来考虑,例如一个用户,关键之处在于要 理解他们是如何工作的。从性能上的原因来看,这是正确的,更具粒度化的控制可能会相当有用。在 下一章我们将会看到,如何用散列数据结构去组织你的数据,使查询变得更为实效。在我看来,这是 散列真正耀眼的地方。 列表(Lists) 对于一个给定的关键字,列表数据结构让你可以存储和处理一组值。你可以添加一个值到列表里、获 取列表的第一个值或最后一个值以及用给定的索引来处理值。列表数据结构维护了值的顺序,提供了 基于索引的高效操作。为了跟踪在网站里注册的最新用户,我们可以维护一个 newusers 的列表: 1. lpush newusers goku 2. ltrim newusers 0 50 (译注: ltrim 命令的具体构成是 LTRIM Key start stop 。要理解 ltrim 命令,首先要明白Key所存 储的值是一个列表,理论上列表可以存放任意个值。对于指定的列表,根据所提供的两个范围参数 start和stop, ltrim 命令会将指定范围外的值都删除掉,只留下范围内的值。) 首先,我们将一个新用户推入到列表的前端,然后对列表进行调整,使得该列表只包含50个最近被推 入的用户。这是一种常见的模式。 ltrim 是一个具有O(N)时间复杂度的操作,N是被删除的值的数 本⽂档使⽤ 书栈(BookStack.CN) 构建 - 15 -

16.第2章 - 数据结构 量。从上面的例子来看,我们总是在插入了一个用户后再进行列表调整,实际上,其将具有O(1)的时 间复杂度(因为N将永远等于1)的常数性能。 这是我们第一次看到一个关键字的对应值索引另一个值。如果我们想要获取最近的10个用户的详细资 料,我们可以运行下面的组合操作: 1. keys = redis.lrange('newusers', 0, 10) 2. redis.mget(*keys.map {|u| "users:#{u}"}) 我们之前谈论过关于多次往返数据的模式,上面的两行Ruby代码为我们进行了很好的演示。 当然,对于存储和索引关键字的功能,并不是只有列表数据结构这种方式。值可以是任意的东西,你 可以使用列表数据结构去存储日志,也可以用来跟踪用户浏览网站时的路径。如果你过往曾构建过游 戏,你可能会使用列表数据结构去跟踪用户的排队活动。 集合(Sets) 集合数据结构常常被用来存储只能唯一存在的值,并提供了许多的基于集合的操作,例如并集。集合 数据结构没有对值进行排序,但是其提供了高效的基于值的操作。使用集合数据结构的典型用例是朋 友名单的实现: 1. sadd friends:leto ghanima paul chani jessica 2. sadd friends:duncan paul jessica alia 不管一个用户有多少个朋友,我们都能高效地(O(1)时间复杂度)识别出用户X是不是用户Y的朋友: 1. sismember friends:leto jessica 2. sismember friends:leto vladimir 而且,我们可以查看两个或更多的人是不是有共同的朋友: 1. sinter friends:leto friends:duncan 甚至可以在一个新的关键字里存储结果: 1. sinterstore friends:leto_duncan friends:leto friends:duncan 有时候需要对值的属性进行标记和跟踪处理,但不能通过简单的复制操作完成,集合数据结构是解决 此类问题的最好方法之一。当然,对于那些需要运用集合操作的地方(例如交集和并集),集合数据 结构就是最好的选择。 本⽂档使⽤ 书栈(BookStack.CN) 构建 - 16 -

17.第2章 - 数据结构 分类集合(Sorted Sets) 最后也是最强大的数据结构是分类集合数据结构。如果说散列数据结构类似于字符串数据结构,主要 区分是域(field)的概念;那么分类集合数据结构就类似于集合数据结构,主要区分是标记(score) 的概念。标记提供了排序(sorting)和秩划分(ranking)的功能。如果我们想要一个秩分类的朋友名 单,可以这样做: 1. zadd friends:duncan 70 ghanima 95 paul 95 chani 75 jessica 1 vladimir 对于 duncan 的朋友,要怎样计算出标记(score)为90或更高的人数? 1. zcount friends:duncan 90 100 如何获取 chani 在名单里的秩(rank)? 1. zrevrank friends:duncan chani (译注: zrank 命令的具体构成是 ZRANK Key menber ,要知道Key存储的Sorted Set默认是根据 Score对各个menber进行升序的排列,该命令就是用来获取menber在该排列里的次序,这就是所谓 的秩。) 我们使用了 zrevrank 命令而不是 zrank 命令,这是因为Redis的默认排序是从低到高,但是在这个 例子里我们的秩划分是从高到低。对于分类集合数据结构,最常见的应用案例是用来实现排行榜系 统。事实上,对于一些基于整数排序,且能以标记(score)来进行有效操作的东西,使用分类集合数 据结构来处理应该都是不错的选择。 小结 对于Redis的5种数据结构,我们进行了高层次的概述。一件有趣的事情是,相对于最初构建时的想 法,你经常能用Redis创造出一些更具实效的事情。对于字符串数据结构和分类集合数据结构的使用, 很有可能存在一些构建方法是还没有人想到的。当你理解了那些常用的应用案例后,你将发现Redis对 于许多类型的问题,都是很理想的选择。还有,不要因为Redis展示了5种数据结构和相应的各种方 法,就认为你必须要把所有的东西都用上。只使用一些命令去构建一个特性是很常见的。 本⽂档使⽤ 书栈(BookStack.CN) 构建 - 17 -

18.第3章 - 使⽤数据结构 第3章 - 使⽤数据结构 第3章 - 使用数据结构 大O表示法(Big O Notation) 仿多关键字查询(Pseudo Multi Key Queries) 引用和索引(References and Indexes) 数据交互和流水线(Round Trips and Pipelining) 事务(Transactions) 关键字反模式(Keys Anti-Pattern) 小结 第3章 - 使用数据结构 在上一章里,我们谈论了Redis的5种数据结构,对于一些可能的用途也给出了用例。现在是时候来看 看一些更高级,但依然很常见的主题和设计模式。 大O表示法(Big O Notation) 在本书中,我们之前就已经看到过大O表示法,包括O(1)和O(N)的表示。大O表示法的惯常用途是,描 述一些用于处理一定数量元素的行为的综合表现。在Redis里,对于一个要处理一定数量元素的命令, 大O表示法让我们能了解该命令的大概运行速度。 在Redis的文档里,每一个命令的时间复杂度都用大O表示法进行了描述,还能知道各命令的具体性能 会受什么因素影响。让我们来看看一些用例。 常数时间复杂度O(1)被认为是最快速的,无论我们是在处理5个元素还是5百万个元素,最终都能得到 相同的性能。对于 sismember 命令,其作用是告诉我们一个值是否属于一个集合,时间复杂度为 O(1)。 sismember 命令很强大,很大部分的原因是其高效的性能特征。许多Redis命令都具有O(1)的时 间复杂度。 对数时间复杂度O(log(N))被认为是第二快速的,其通过使需扫描的区间不断皱缩来快速完成处理。使 用这种“分而治之”的方式,大量的元素能在几个迭代过程里被快速分解完整。 zadd 命令的时间复杂 度就是O(log(N)),其中N是在分类集合中的元素数量。 再下来就是线性时间复杂度O(N),在一个表格的非索引列里进行查找就需要O(N)次操作。 ltrim 命 令具有O(N)的时间复杂度,但是,在 ltrim 命令里,N不是列表所拥有的元素数量,而是被删除的元 素数量。从一个具有百万元素的列表里用 ltrim 命令删除1个元素,要比从一个具有一千个元素的列 表里用 ltrim 命令删除10个元素来的快速(实际上,两者很可能会是一样快,因为两个时间都非常的 小)。 根据给定的最小和最大的值的标记, zremrangebyscore 命令会在一个分类集合里进行删除元素操作, 其时间复杂度是O(log(N)+M)。这看起来似乎有点儿杂乱,通过阅读文档可以知道,这里的N指的是在 本⽂档使⽤ 书栈(BookStack.CN) 构建 - 18 -

19.第3章 - 使⽤数据结构 分类集合里的总元素数量,而M则是被删除的元素数量。可以看出,对于性能而言,被删除的元素数 量很可能会比分类集合里的总元素数量更为重要。 (译注: zremrangebyscore 命令的具体构成是 ZREMRANGEBYSCORE Key max mix 。) 对于 sort 命令,其时间复杂度为O(N+M*log(M)),我们将会在下一章谈论更多的相关细节。 从 sort 命令的性能特征来看,可以说这是Redis里最复杂的一个命令。 还存在其他的时间复杂度描述,包括O(N^2)和O(C^N)。随着N的增大,其性能将急速下降。在Redis 里,没有任何一个命令具有这些类型的时间复杂度。 值得指出的一点是,在Redis里,当我们发现一些操作具有O(N)的时间复杂度时,我们可能可以找到更 为好的方法去处理。 (译注:对于Big O Notation,相信大家都非常的熟悉,虽然原文仅仅是对该表示法进行简单的介 绍,但限于个人的算法知识和文笔水平实在有限,此小节的翻译让我头痛颇久,最终成果也确实难以 让人满意,望见谅。) 仿多关键字查询(Pseudo Multi Key Queries) 时常,你会想通过不同的关键字去查询相同的值。例如,你会想通过电子邮件(当用户开始登录时) 去获取用户的具体信息,或者通过用户id(在用户登录后)去获取。有一种很不实效的解决方法,其将 用户对象分别放置到两个字符串值里去: 1. set users:leto@dune.gov "{id: 9001, email: 'leto@dune.gov', ...}" 2. set users:9001 "{id: 9001, email: 'leto@dune.gov', ...}" 这种方法很糟糕,如此不但会产生两倍数量的内存,而且这将会成为数据管理的恶梦。 如果Redis允许你将一个关键字链接到另一个的话,可能情况会好很多,可惜Redis并没有提供这样的 功能(而且很可能永远都不会提供)。Redis发展到现在,其开发的首要目的是要保持代码和API的整 洁简单,关键字链接功能的内部实现并不符合这个前提(对于关键字,我们还有很多相关方法没有谈 论到)。其实,Redis已经提供了解决的方法:散列。 使用散列数据结构,我们可以摆脱重复的缠绕: 1. set users:9001 "{id: 9001, email: leto@dune.gov, ...}" 2. hset users:lookup:email leto@dune.gov 9001 我们所做的是,使用域来作为一个二级索引,然后去引用单个用户对象。要通过id来获取用户信息,我 们可以使用一个普通的 get 命令: 1. get users:9001 本⽂档使⽤ 书栈(BookStack.CN) 构建 - 19 -

20.第3章 - 使⽤数据结构 而如果想通过电子邮箱来获取用户信息,我们可以使用 hget 命令再配合使用 get 命令(Ruby代 码): 1. id = redis.hget('users:lookup:email', 'leto@dune.gov') 2. user = redis.get("users:#{id}") 你很可能将会经常使用这类用法。在我看来,这就是散列真正耀眼的地方。在你了解这类用法之前, 这可能不是一个明显的用例。 引用和索引(References and Indexes) 我们已经看过几个关于值引用的用例,包括介绍列表数据结构时的用例,以及在上面使用散列数据结 构来使查询更灵活一些。进行归纳后会发现,对于那些值与值间的索引和引用,我们都必须手动的去 管理。诚实来讲,这确实会让人有点沮丧,尤其是当你想到那些引用相关的操作,如管理、更新和删 除等,都必须手动的进行时。在Redis里,这个问题还没有很好的解决方法。 我们已经看到,集合数据结构很常被用来实现这类索引: 1. sadd friends:leto ghanima paul chani jessica 这个集合里的每一个成员都是一个Redis字符串数据结构的引用,而每一个引用的值则包含着用户对象 的具体信息。那么如果 chani 改变了她的名字,或者删除了她的帐号,应该如何处理?从整个朋友圈 的关系结构来看可能会更好理解,我们知道, chani 也有她的朋友: 1. sadd friends_of:chani leto paul 如果你有什么待处理情况像上面那样,那在维护成本之外,还会有对于额外索引值的处理和存储空间 的成本。这可能会令你感到有点退缩。在下一小节里,我们将会谈论减少使用额外数据交互的性能成 本的一些方法(在第1章我们粗略地讨论了下)。 如果你确实在担忧着这些情况,其实,关系型数据库也有同样的开销。索引需要一定的存储空间,必 须通过扫描或查找,然后才能找到相应的记录。其开销也是存在的,当然他们对此做了很多的优化工 作,使之变得更为有效。 再次说明,需要在Redis里手动地管理引用确实是颇为棘手。但是,对于你关心的那些问题,包括性能 或存储空间等,应该在经过测试后,才会有真正的理解。我想你会发现这不会是一个大问题。 数据交互和流水线(Round Trips and Pipelining) 我们已经提到过,与服务器频繁交互是Redis的一种常见模式。这类情况可能很常出现,为了使我们能 获益更多,值得仔细去看看我们能利用哪些特性。 本⽂档使⽤ 书栈(BookStack.CN) 构建 - 20 -

21.第3章 - 使⽤数据结构 许多命令能接受一个或更多的参数,也有一种关联命令(sister-command)可以接受多个参数。例如 早前我们看到过 mget 命令,接受多个关键字,然后返回值: 1. keys = redis.lrange('newusers', 0, 10) 2. redis.mget(*keys.map {|u| "users:#{u}"}) 或者是 sadd 命令,能添加一个或多个成员到集合里: 1. sadd friends:vladimir piter 2. sadd friends:paul jessica leto "leto II" chani Redis还支持流水线功能。通常情况下,当一个客户端发送请求到Redis后,在发送下一个请求之前必 须等待Redis的答复。使用流水线功能,你可以发送多个请求,而不需要等待Redis响应。这不但减少 了网络开销,还能获得性能上的显著提高。 值得一提的是,Redis会使用存储器去排列命令,因此批量执行命令是一个好主意。至于具体要多大的 批量,将取决于你要使用什么命令(更明确来说,该参数有多大)。另一方面来看,如果你要执行的 命令需要差不多50个字符的关键字,你大概可以对此进行数千或数万的批量操作。 对于不同的Redis载体,在流水线里运行命令的方式会有所差异。在Ruby里,你传递一个代码块 到 pipelined 方法: 1. redis.pipelined do 2. 9001.times do 3. redis.incr('powerlevel') 4. end 5. end 正如你可能猜想到的,流水线功能可以实际地加速一连串命令的处理。 事务(Transactions) 每一个Redis命令都具有原子性,包括那些一次处理多项事情的命令。此外,对于使用多个命令, Redis支持事务功能。 你可能不知道,但Redis实际上是单线程运行的,这就是为什么每一个Redis命令都能够保证具有原子 性。当一个命令在执行时,没有其他命令会运行(我们会在往后的章节里简略谈论一下Scaling)。在 你考虑到一些命令去做多项事情时,这会特别的有用。例如: incr 命令实际上就是一个 get 命令然后紧随一个 set 命令。 getset 命令设置一个新的值然后返回原始值。 setnx 命令首先测试关键字是否存在,只有当关键字不存在时才设置值 本⽂档使⽤ 书栈(BookStack.CN) 构建 - 21 -

22.第3章 - 使⽤数据结构 虽然这些都很有用,但在实际开发时,往往会需要运行具有原子性的一组命令。若要这样做,首先要 执行 multi 命令,紧随其后的是所有你想要执行的命令(作为事务的一部分),最后执行 exec 命 令去实际执行命令,或者使用 discard 命令放弃执行命令。Redis的事务功能保证了什么? 事务中的命令将会按顺序地被执行 事务中的命令将会如单个原子操作般被执行(没有其它的客户端命令会在中途被执行) 事务中的命令要么全部被执行,要么不会执行 你可以(也应该)在命令行界面对事务功能进行一下测试。还有一点要注意到,没有什么理由不能结 合流水线功能和事务功能。 1. multi 2. hincrby groups:1percent balance -9000000000 3. hincrby groups:99percent balance 9000000000 4. exec 最后,Redis能让你指定一个关键字(或多个关键字),当关键字有改变时,可以查看或者有条件地应 用一个事务。这是用于当你需要获取值,且待运行的命令基于那些值时,所有都在一个事务里。对于 上面展示的代码,我们不能去实现自己的 incr 命令,因为一旦 exec 命令被调用,他们会全部被执 行在一块。我们不能这么做: 1. redis.multi() 2. current = redis.get('powerlevel') 3. redis.set('powerlevel', current + 1) 4. redis.exec() (译注:虽然Redis是单线程运行的,但是我们可以同时运行多个Redis客户端进程,常见的并发问题 还是会出现。像上面的代码,在 get 运行之后, set 运行之前, powerlevel 的值可能会被另一个 Redis客户端给改变,从而造成错误。) 这些不是Redis的事务功能的工作。但是,如果我们增加一个 watch 到 powerlevel ,我们可以这样 做: 1. redis.watch('powerlevel') 2. current = redis.get('powerlevel') 3. redis.multi() 4. redis.set('powerlevel', current + 1) 5. redis.exec() 在我们调用 watch 后,如果另一个客户端改变了 powerlevel 的值,我们的事务将会运行失败。如果 没有客户端改变 powerlevel 的值,那么事务会继续工作。我们可以在一个循环里运行这些代码,直到 其能正常工作。 本⽂档使⽤ 书栈(BookStack.CN) 构建 - 22 -

23.第3章 - 使⽤数据结构 关键字反模式(Keys Anti-Pattern) 在下一章中,我们将会谈论那些没有确切关联到数据结构的命令,其中的一些是管理或调试工具。然 而有一个命令我想特别地在这里进行谈论: keys 命令。这个命令需要一个模式,然后查找所有匹配 的关键字。这个命令看起来很适合一些任务,但这不应该用在实际的产品代码里。为什么?因为这个 命令通过线性扫描所有的关键字来进行匹配。或者,简单地说,这个命令太慢了。 人们会如此去使用这个命令?一般会用来构建一个本地的Bug追踪服务。每一个帐号都有一个 id , 你可能会通过一个看起来像 bug:account_id:bug_id 的关键字,把每一个Bug存储到一个字符串数据结构 值中去。如果你在任何时候需要查询一个帐号的Bug(显示它们,或者当用户删除了帐号时删除掉这些 Bugs),你可能会尝试去使用 keys 命令: 1. keys bug:1233:* 更好的解决方法应该使用一个散列数据结构,就像我们可以使用散列数据结构来提供一种方法去展示 二级索引,因此我们可以使用域来组织数据: 1. hset bugs:1233 1 "{id:1, account: 1233, subject: '...'}" 2. hset bugs:1233 2 "{id:2, account: 1233, subject: '...'}" 从一个帐号里获取所有的Bug标识,可以简单地调用 hkeys bugs:1233 。去删除一个指定的Bug,可以 调用 hdel bugs:1233 2 。如果要删除了一个帐号,可以通过 del bugs:1233 把关键字删除掉。 小结 结合这一章以及前一章,希望能让你得到一些洞察力,了解如何使用Redis去支持(Power)实际项 目。还有其他的模式可以让你去构建各种类型的东西,但真正的关键是要理解基本的数据结构。你将 能领悟到,这些数据结构是如何能够实现你最初视角之外的东西。 本⽂档使⽤ 书栈(BookStack.CN) 构建 - 23 -

24.第4章 - 超越数据结构 第4章 - 超越数据结构 第4章 超越数据结构 使用期限(Expiration) 发布和订阅(Publication and Subscriptions) 监控和延迟日志(Monitor and Slow Log) 排序(Sort) 小结 第4章 超越数据结构 5种数据结构组成了Redis的基础,其他没有关联特定数据结构的命令也有很多。我们已经看过一些这 样的命令: info , select , flushdb , multi , exec , discard , watch 和 keys 。这一章将 看看其他的一些重要命令。 使用期限(Expiration) Redis允许你标记一个关键字的使用期限。你可以给予一个Unix时间戳形式(自1970年1月1日起)的 绝对时间,或者一个基于秒的存活时间。这是一个基于关键字的命令,因此其不在乎关键字表示的是 哪种类型的数据结构。 1. expire pages:about 30 2. expireat pages:about 1356933600 第一个命令将会在30秒后删除掉关键字(包括其关联的值)。第二个命令则会在2012年12月31日上午 12点删除掉关键字。 这让Redis能成为一个理想的缓冲引擎。通过 ttl 命令,你可以知道一个关键字还能够存活多久。而 通过 persist 命令,你可以把一个关键字的使用期限删除掉。 1. ttl pages:about 2. persist pages:about 最后,有个特殊的字符串命令, setex 命令让你可以在一个单独的原子命令里设置一个字符串值,同 时里指定一个生存期(这比任何事情都要方便)。 1. setex pages:about 30 '<h1>about us</h1>....' 发布和订阅(Publication and Subscriptions) 本⽂档使⽤ 书栈(BookStack.CN) 构建 - 24 -

25.第4章 - 超越数据结构 Redis的列表数据结构有 blpop 和 brpop 命令,能从列表里返回且删除第一个(或最后一个)元 素,或者被堵塞,直到有一个元素可供操作。这可以用来实现一个简单的队列。 (译注:对于 blpop 和 brpop 命令,如果列表里没有关键字可供操作,连接将被堵塞,直到有另外 的Redis客户端使用 lpush 或 rpush 命令推入关键字为止。) 此外,Redis对于消息发布和频道订阅有着一流的支持。你可以打开第二个 redis-cli 窗口,去尝试一 下这些功能。在第一个窗口里订阅一个频道(我们会称它为 warnings ): 1. subscribe warnings 其将会答复你订阅的信息。现在,在另一个窗口,发布一条消息到 warnings 频道: 1. publish warnings "it's over 9000!" 如果你回到第一个窗口,你应该已经接收到 warnings 频道发来的消息。 你可以订阅多个频道( subscribe channel1 channel2 ... ),订阅一组基于模式的频道( psubscribe warnings:* ),以及使用 unsubscribe 和 punsubscribe 命令停止监听一个或多个频道,或一个频道模 式。 最后,可以注意到 publish 命令的返回值是1,这指出了接收到消息的客户端数量。 监控和延迟日志(Monitor and Slow Log) monitor 命令可以让你查看Redis正在做什么。这是一个优秀的调试工具,能让你了解你的程序如何 与Redis进行交互。在两个 redis-cli 窗口中选一个(如果其中一个还处于订阅状态,你可以使 用 unsubscribe 命令退订,或者直接关掉窗口再重新打开一个新窗口)键入 monitor 命令。在另一个 窗口,执行任何其他类型的命令(例如 get 或 set 命令)。在第一个窗口里,你应该可以看到这些 命令,包括他们的参数。 在实际生产环境里,你应该谨慎运行 monitor 命令,这真的仅仅就是一个很有用的调试和开发工具。 除此之外,没有更多要说的了。 随同 monitor 命令一起,Redis拥有一个 slowlog 命令,这是一个优秀的性能剖析工具。其会记录执 行时间超过一定数量微秒的命令。在下一章节,我们会简略地涉及如何配置Redis,现在你可以按下面 的输入配置Redis去记录所有的命令: 1. config set slowlog-log-slower-than 0 然后,执行一些命令。最后,你可以检索到所有日志,或者检索最近的那些日志: 1. slowlog get 本⽂档使⽤ 书栈(BookStack.CN) 构建 - 25 -

26.第4章 - 超越数据结构 2. slowlog get 10 通过键入 slowlog len ,你可以获取延迟日志里的日志数量。 对于每个被你键入的命令,你应该查看4个参数: 一个自动递增的id 一个Unix时间戳,表示命令开始运行的时间 一个微妙级的时间,显示命令运行的总时间 该命令以及所带参数 延迟日志保存在存储器中,因此在生产环境中运行(即使有一个低阀值)也应该不是一个问题。默认 情况下,它将会追踪最近的1024个日志。 排序(Sort) sort 命令是Redis最强大的命令之一。它让你可以在一个列表、集合或者分类集合里对值进行排序 (分类集合是通过标记来进行排序,而不是集合里的成员)。下面是一个 sort 命令的简单用例: 1. rpush users:leto:guesses 5 9 10 2 4 10 19 2 2. sort users:leto:guesses 这将返回进行升序排序后的值。这里有一个更高级的例子: 1. sadd friends:ghanima leto paul chani jessica alia duncan 2. sort friends:ghanima limit 0 3 desc alpha 上面的命令向我们展示了,如何对已排序的记录进行分页(通过 limit ),如何返回降序排序的结果 (通过 desc ),以及如何用字典序排序代替数值序排序(通过 alpha )。 sort 命令的真正力量是其基于引用对象来进行排序的能力。早先的时候,我们说明了列表、集合和 分类集合很常被用于引用其他的Redis对象, sort 命令能够解引用这些关系,而且通过潜在值来进 行排序。例如,假设我们有一个Bug追踪器能让用户看到各类已存在问题。我们可能使用一个集合数据 结构去追踪正在被监视的问题: 1. sadd watch:leto 12339 1382 338 9338 你可能会有强烈的感觉,想要通过id来排序这些问题(默认的排序就是这样的),但是,我们更可能是 通过问题的严重性来对这些问题进行排序。为此,我们要告诉Redis将使用什么模式来进行排序。首 先,为了可以看到一个有意义的结果,让我们添加多一点数据: 本⽂档使⽤ 书栈(BookStack.CN) 构建 - 26 -

27.第4章 - 超越数据结构 1. set severity:12339 3 2. set severity:1382 2 3. set severity:338 5 4. set severity:9338 4 要通过问题的严重性来降序排序这些Bug,你可以这样做: 1. sort watch:leto by severity:* desc Redis将会用存储在列表(集合或分类集合)中的值去替代模式中的 * (通过 by )。这会创建出 关键字名字,Redis将通过查询其实际值来排序。 在Redis里,虽然你可以有成千上万个关键字,类似上面展示的关系还是会引起一些混乱。幸 好, sort 命令也可以工作在散列数据结构及其相关域里。相对于拥有大量的高层次关键字,你可以 利用散列: 1. hset bug:12339 severity 3 2. hset bug:12339 priority 1 3. hset bug:12339 details "{id: 12339, ....}" 4. 5. hset bug:1382 severity 2 6. hset bug:1382 priority 2 7. hset bug:1382 details "{id: 1382, ....}" 8. 9. hset bug:338 severity 5 10. hset bug:338 priority 3 11. hset bug:338 details "{id: 338, ....}" 12. 13. hset bug:9338 severity 4 14. hset bug:9338 priority 2 15. hset bug:9338 details "{id: 9338, ....}" 所有的事情不仅变得更为容易管理,而且我们能通过 severity 或 priority 来进行排序,还可以告 诉 sort 命令具体要检索出哪一个域的数据: 1. sort watch:leto by bug:*->priority get bug:*->details 相同的值替代出现了,但Redis还能识别 -> 符号,用它来查看散列中指定的域。里面还包括 了 get 参数,这里也会进行值替代和域查看,从而检索出Bug的细节(details域的数据)。 对于太大的集合, sort 命令的执行可能会变得很慢。好消息是, sort 命令的输出可以被存储起 来: 1. sort watch:leto by bug:*->priority get bug:*->details store watch_by_priority:leto 本⽂档使⽤ 书栈(BookStack.CN) 构建 - 27 -

28.第4章 - 超越数据结构 使用我们已经看过的 expiration 命令,再结合 sort 命令的 store 能力,这是一个美妙的组合。 小结 这一章主要关注那些非特定数据结构关联的命令。和其他事情一样,它们的使用依情况而定。构建一 个程序或特性时,可能不会用到使用期限、发布和订阅或者排序等功能。但知道这些功能的存在是很 好的。而且,我们也只接触到了一些命令。还有更多的命令,当你消化理解完这本书后,非常值得去 浏览一下完整的命令列表。 本⽂档使⽤ 书栈(BookStack.CN) 构建 - 28 -

29.第5章 - 管理 第5章 - 管理 第5章 - 管理 配置(Configuration) 验证(Authentication) 大小限制(Size Limitations) 复制(Replication) 备份文件(Backups) 缩放和Redis集群(Scaling and Redis Cluster) 小结 第5章 - 管理 在最后一章里,我们将集中谈论Redis运行中的一些管理方面内容。这是一个不完整的Redis管理指 南,我们将会回答一些基本的问题,初接触Redis的新用户可能会很感兴趣。 配置(Configuration) 当你第一次运行Redis的服务器,它会向你显示一个警告,指 redis.conf 文件没有被找到。这个文件 可以被用来配置Redis的各个方面。一个充分定义(well-documented)的 redis.conf 文件对各个版本 的Redis都有效。范例文件包含了默认的配置选项,因此,对于想要了解设置在干什么,或默认设置是 什么,都会很有用。你可以在https://github.com/antirez/redis/raw/2.4.6/redis.conf找到这个文件。 这个配置文件针对的是Redis 2.4.6,你应该用你的版本号替代上面URL里的”2.4.6”。运行 info 命 令,其显示的第一个值就是Redis的版本号。 因为这个文件已经是充分定义(well-documented),我们就不去再进行设置了。 除了通过 redis.conf 文件来配置Redis, config set 命令可以用来对个别值进行设置。实际上,在 将 slowlog-log-slower-than 设置为0时,我们就已经使用过这个命令了。 还有一个 config get 命令能显示一个设置值。这个命令支持模式匹配,因此如果我们想要显示关联于 日志(logging)的所有设置,我们可以这样做: 1. config get *log* 验证(Authentication) 通过设置 requirepass (使用 config set 命令或 redis.conf 文件),可以让Redis需要一个密码验 证。当 requirepass 被设置了一个值(就是待用的密码),客户端将需要执行一个 auth password 命 令。 本⽂档使⽤ 书栈(BookStack.CN) 构建 - 29 -