1.Redis学习资料

虽然前面已经学习了 Redis 理论和技术点，但是如果想要持续提升自己的技术能力，还是需要不断丰富自己的知识体系。本章，给你推荐几本优秀的书籍，以及拓展知识面的其他资料。

1.1 经典书籍

在学习 Redis 时，场景的需求有三个方面：

• 日常使用操作：比如常见的命令和配置，集群搭建等
• 关键技术原理：比如 IO 模型、AOF 和 RDB 机制等
• 在实际使用时的经验教训，比如 Redis 响应变慢了怎么办？Redis 主从数据库不一致怎么办？ 等等。

1.2 工具书《Redis 使用手册》

一本好的工具书可以帮助我们快速了解或查询 Redis 日常的使用命令和操作方法。《Redis 使用手册》是一本非常好用的工具书。

本书中，作者将 Redis 内容分成了三大部分，分别是“数据结构与应用”、“附加功能” 和“多功能机制”。其中，最有用的就是“数据结构与应用”的内容，因为它提供了丰富的操作命令介绍，不仅涵盖了 Redis 的 5 大数据类型的主要操作命令，还介绍了 4 种扩展数据类型的命令操作，包括 位图、地址坐标、HyperLogLog 和流。

不过，想要了解最新、最全的 Redis 命令操作，建议去官网查阅。考虑到有些读者想看中文版，在提供一个翻译版的命令参考。

《Redis 使用手册》还提供了“附加功能”部分，介绍了 Redis 数据库的管理操作和过期 key 的操作，这对我们进行 Redis 数据库运维（例如迁移数据、清空数据库、淘汰数据库等）提供了操作上的指导。

1.3 原理书：《Redis 设计与实现》

虽然《Redis 设计与实现》和《Redis 使用手册》是同一个作者写的，但是它们的侧重点不同，这本书更加关注 Redis 关键机制的实现原理。

介绍 Redis 原理的书籍很多，但是这本书讲解的非常透彻，尤其是在 Redis 底层数据结构、RDB 和 AOF 持久化机制，以及哨兵机制和切片集群的介绍上，非常容易理解，建议你可以重点学习下这部分内容。

除了文字的讲解，概述还针对一些难点问题，例如数据结构的组成、哨兵实例间的交互过程、切片集群实例的交互过程等，都使用了非常清晰的插图来表示，可以最大程度地降低学习难度。

虽然这本书的出版日期比较早（针对 Redis 3.0），但里面讲的很多原理现在依然是适用的，它可以在帮助你从入门 Redis 到精通的道路上，迈进一大步。

1.4 实战书：《Redis 开发与运维》

在实战方面，《Redis 开发与运维》是一本不错的参考书。

首先，它介绍了 Redis 的 Java 和 Python 客户端，以及 Redis 用于缓冲设计的关键技术和注意事项，这些内容在其他的书籍中不太常见，可以重点学习下。

其实，它围绕客户端、持久化、主从复制、哨兵、切片集群等几方面，着重介绍了在日常的开发运维过程中遇到的“坑”，都是经验之谈，可以帮助你提前做规避。

另外，这本书还针对 Redis 阻塞、优化内存使用、处理 bigkey 这几个经典问题，提供了解决方案，非常值得一读。你可以把目录的问题做成 QA 列表，这样，在遇到问题的时候，就可以对照这个列表，快速找出原因，并利用书中的方案去解决问题。

当然，想真正提升能力，光读书是不够的，有两条建议：

• 第一条是阅读源码。读源码其实也是一种实战锻炼，可以帮助你从代码逻辑中彻底理解 Redis 的实际运行机制，当遇到问题时，可以直接从代码层面进行定位、分析和解决问题。阅读 Redis 的源码在 GitHub 上。另外，还有一个增加了中文注释的代码库 （基于Redis 3.0 源码）。

此外，还要动手进行实践。Redis 就是一个进程，我们可以直接使用自己的电脑进行部署。只要不是性能测试，在功能测试或场景模拟上，自己电脑的环境一般都是可以胜任的。比如说，要想部署主从集群或者切片集群，模拟主库故障，完全可以在自己的电脑上起多个 Redis 实例来完成，只要它们的端口号不同就可以了。

1.5 扩展阅读方向

Redis 的很多关键功能，其实和操作系统底层的实现机制是相关的，比如说：非阻塞的网络框架、RDB 生成和 AOF 重写时设计到的 fork 和写实复制机制，等等。另外，Redis 主从集群中的哨兵机制，以及切片集群的数据分布还涉及到一些分布式系统的内容。

所以，如果你希望自己的实战能力更强，建议你读一读操作系统和分布式系统方面的经典教材，比如《操作系统导论》。这本书里对进程、线程的定义，对进程 API 、线程 API 以及对文件系统 fsync 操作、缓存和缓冲的介绍，都是和 Redis 直接相关的；再比如《大规模分布式存储系统：原理解析与架构实战》中的分布式系统章节，可以让你掌握 Redis 主从集群、切片集群涉及到的设计规范。了解了操作系统和分布式系统的基础知识，技能帮你理清容易混淆的概念，也可以帮你将一些通用的设计方法（如一致性哈希）应用到日常实践中，做到融会贯通，举一反三。

2. Redis 好用的运维工具

2.1 最基本的监控命令：INFO 命令

Redis 本身提供的 INFO 命令会返回丰富的实例运行监控信息，这个命令是 Redis 监控工具的基础。

INFO 命令在使用的时候，可以带一个 section ，这个参数的取值有好几种，相应的，INFO 命令也会返回不同类型的监控信息。我们把 INFO 命令的返回信息分成 5 大类，其中，有的类别当中有包含了不同的监控信息，如下表所示：

类别	子类别	对应INFO命令的section参数
实例本身配置信息	无	server
运行状态统计	客户端统计	client
运行状态统计	通用统计信息	stats
运行状态统计	数据库整体统计信息	keyspace
运行状态统计	不同类型命令的调用统计信息	commandstats
资源使用统计信息	cpu使用情况	cpu
资源使用统计信息	内存使用情况	memory
关键功能运行状态	RDB、AOF运行情况	persistence
关键功能运行状态	主从复制的运行情况	replication
关键功能运行状态	切片集群的运行情况	cluster
扩展模块信息	无	modules

在监控 Redis 运行状态是，INFO 命令返回的结果非常有用。如果你想了解 INFO 命令的所有参数返回的含义，可以查看 Redis 官网的介绍。这里给你几个运维时，需要重点关注的参数，及它们的重要返回结果。

首先，无论你运行的是单实例或集群，建议你重点关注一下 stats、commandstats 、cpu 和 memory 这四个参数的返回结果，这里包含了命令的执行情况（如命令的执行次数、执行时间、命令使用的 CPU 资源），内存的使用情况（比如内存的已使用量、内存的碎片率），CPU 资源使用情况等，这可以帮助我们判断实例的运行状态和资源消耗情况。

另外，当你启用 RDB 或 AOF 功能时，你要重点关注下 persistence 参数的返回结果，通过它可以看到 RDB 或 AOF 的执行情况。

如果你在使用主从集群，要重点关注下 replication 参数的返回结果，这里面包含了主从同步的实时状态。

不过 info 命令只提供了文本形式的监控结果，并没有可视化，可以使用一些第三方开源工具，将 INFO 命令返回的结果可视化。

2.2 面向 Prometheus 的 Redis-exporter 监控

Prometheus 是一套开源的系统监控报警框架。它的核心功能是从被监控的系统中拉取监控数据，结合 Grafana 工具，进行可视化展示。而且，监控数据可以保存到时序数据库中，以便运维人员进行历史查询。同时，Prometheus 会检测系统的监控指标是否超过了预设的阈值，一旦超过，Prometheus 就会出发报警。

对于系统的日常运维来说，这些功能是非常重要的。而 Prometheus 已经实现了使用这些功能的工具框架。我们只要能从被监控系统中获取到监控数据，就可以用 Prometheus 来实现运维监控。

Prometheus 正好提供了插件功能拉实现对一个系统法监控，我们把插件称为 exporter ，每一个 exporter 实际是一个采集监控数据的组件。exporter 采集的数据格式符合 Prometheus 的要求，Prometheus 获取到这些数据后，就可以进行展示和保持了。

Redis-exporter 就是用来监控 Redis 的，它将 INFO 命令监控到的运行状态各种统计信息提供给 Prometheus ，从而进行可视化展示和报警设置。目前，Redis-exporter 可以支持 Redis 2.0 至 6.0。

除了获取 Redis 实例的运行状态，Redis-exporter 还可以监控键值对的大小和集合数据类型数据的元素个数，这个可以在运行 Redis-exporter 时，使用 check-keys 命令选项来实现。

此外，可以开发一个 Lua 脚本，定制化采集所需的监控数据。然后，我们使用 Scrpits 命令选项，让 Redis-exporter 运行这个特定的脚本，从而可以满足业务层的多样化监控需求。

最后，在分享两个小工具：redis-stat 和 redis live。跟 Redis-exporter 相比，这两个都是轻量级的监控工具。它们分别用 Ruby 和 Python 开发，也是将 INFO 命令提供的实例运行状态信息可视化展示。虽然这两个工具更新很少，不过，如果你想自行开发 Redis 监控工具，它们都是不错的参考。

2.3 数据迁移工具 Redis-shake

有时，我们在将不同的实例间迁移数据。目前，常用的数据迁移工具是 Redis-shake。

Redis-shake 的基本运行原理，是先启动 Redis-shake 进程，这个进程模拟了一个 Redis 实例，然后，Redis-shake 进程和数据迁出的源实例进行数据的全量同步。这个过程和 Redis 主从实例的全量同步是类似的。

源实例相当于主库，Redis-shake 相当于从库，源实例先把 RDB 文件传输给 Redis-shake，Redis-shake 会把 RDB 文件发送给目的实例。接着，源实例会再把增量命令发送给 Redis-shake，Redis-shake 负责把这些增量命令再同步给目的实例。

Redis-shake 的一大优势，就是支持多种类型的迁移。

首先，它既支持单个实例间的数据迁移，也支持集群到集群的数据迁移。

其次，有的 Redis 切片集群（如 Codis）使用 Proxy 接受请求操作，Redis-shake 也同样支持和 proxy 进行数据迁移。

另外，因为 Redis-shake 是阿里云团队开发的，所以除了支持开源的 Redis 版本以外，Redis-shake 还支持云下的 Redis 和云上的 Redis 实例进行迁移，可以帮助我们实现 Redis 服务上云的目标。

在数据迁移后，我们通常需要对比源实例和目的实例中的数据是否一致。如果有不一致的数据，我们需要把它们找出来，从目的实例中提出，或者是再次迁移这些不一致的数据。

这里要介绍一个数据一致性比对的工具了，Redis-full-check。

Redis-full-check 的工作原理很简单，就是对源实例和目的实例中的数据进行权利对比，从而完成数据校验。不过，为了降低数据校验的对比开销，Redis-full-check 采用了多轮比较的方法。

在第一轮校验时，Redis-full-check 会找出在源实例上的所有key，然后从源实例和目的实例中把响应的值也都查出来，进行比对。在第一次比对后，Redis-full-check 会把目的实例中和源实例中不一致的数据，记录到 sqlite 数据库中。

从第二轮校验开始，Redis-full-check 只会比较上一轮结束后记录在数据库中不一致的数据。

为了避免对实例的正常请求处理造成影响，Redis-full-check 在每一轮对比结束后，会暂停一段时间。随着 Redis-shake 增量同步的进行，源实例和目的实例中的不一致数据也会逐步减少，所以，我们的校验独臂的轮数不用很多。

等所有轮数据都比对完成后，数据库中记录的数据就是源实例和目的实例最终的差异结果。

这里有个地方需要注意下，Redis-full-check 提供了三种对比模式，我们可以通过 comparemode 参数进行设置：

• keyOutline：只比对 key 值是否相等。
• valueOutline：值对比 value 值的长度是否相等
• FullValue：对比 key 值、value 长度、value 值是否相等。

2.4 集群管理工具 CacheCloud

CacheCloud 是面向 Redis 运维管理的云平台，它实现了主从集群、哨兵集群和 Redis Cluster 的自动部署和管理，用户可以直接在平台的管理界面上进行操作。

针对常见的集群运维需求，CacheCloud 提供了 5 个运维操作：

• 下线实例：关闭实例及实例相关的监控任务。
• 上线实例：重新启动已经下线的实例，并进行监控。
• 添加从节点：在主从集群中给主节点添加一个从节点。
• 故障切换：手动完成 Redis Cluster 主从节点的故障转移。
• 配置管理：用户提交配置修改的工单后，管理员进行审核，并完成配置修改。

当然，作为运维管理平台，CacheCloud 除了提供运行操作外，还提供了丰富的监控信息。

CacheCloud 不仅会收集 INFO 命令提供的实例实时运行状态信息，进行可视化展示，而且还会把实例运行状态信息保存下来，例如内存使用情况、客户端连接数、键值对数据量。这些一来，当 Redis 运行发生问题时，运维人员可以查询保存的历史记录，并结合当时的运行状态信息进行分析。

如果你希望有一个统一平台，把 Redis 实例管理相关的任务集中托管起来，CacheCloud 是一个不错的工具。

3. Redis的使用规范小建议

3.1 键值对使用规范

关于键值对的使用规范，主要有两方面：

1. key 的命名规范，只有命名规范，才能提供可读性强、可维护性好的 key，方便日常管理。
2. value 的设计规范，包括避免 bigkey、选择高效率序列化方法和压缩方法、使用证书对象、共享池、数据类型选择。

规范一：key 的命名规范

一个 Redis 实例默认可以支持 16 个数据库，我们可以把不同的业务数据分散保存到不同的数据中。但是客户端在使用不同数据库时，需要使用 SELECT 命令进行数据库切换，相当于增加了一次额外的操作。

我们可以通过合理命名 key，减少这个操作。具体的做法是，把业务名作为前缀，然后用冒号分割，再加上具体的业务数据名。这样一来，我们可以通过 key 的前缀区分不同的业务数据，就不用在多个数据库间来回切换了。

比如说，如果我们要统计网页的独立访客量，就可以用下面的代码设置 key，这就表示，这个数据对应的业务 unique （独立访客量），而且对应的页面编号是 1024。

uv:page:1024

这里有个地方需要注意下。key 本身是字符串，底层的数据结构是 SDS。SDS 结构中会包括字符串长度、分配空间大小等元数据信息。从 Redis 3.2 版本开始，当 key 字符串的长度增加时，SDS 中的元数据也会占用更多内存空间。

所以，我们在设置 key 的名称时，要注意控制 key 的长度。否则，如果 key 很长的话，就会消耗较多内存空间，而且，SDS 元数据也会额外消耗一定的内存空间。

SDS 结构中的字符串长度和元数据大小的对应关系：

字符串大小（字节）	SDS结构元数据大小（字节）
1 ~ 2^5 - 1	1
2^5 ~ 2^8 -1	3
2^8 ~ 2^16 -1	5
2^16 ~ 2^32 -1	9
2^32 ~ 2^64 -1	17

为了减少 key 占用的内存空间，给你一个小建议：对于业务或数据名，可以使用相应的英文单词的首字母表示，（比如 user 用 u 表示，message 用 m），或者是用缩写表示（例如 unique 是石头人使用 uv）。

规范二：避免使用 bigkey

Redis 是使用单线程读写数据，bigkey 的读写操作会阻塞，降低 Reids 的处理效率。所以，在应用 Redis 时，关于 value 的设计规范，非常重要的一点就是避免 bigkey。

bigkey 通常由两种情况。

• 情况一： 键值对的值大小本身就很大，例如 value 为 1MB 的 String 类型数据。为了避免 String 类型的 bigkey，在业务层，我们要尽量把 String 类型的数据大小控制在 10 KB 以下。
• 情况二：键值对的值是集合类型，集合元素个数非常多，例如包含 100 万个元素的 Hash 集合类型数据。为了避免集合类型的 bigkey，我给你的设计规范建议是，尽量把集合类型的元素个数控制在 1 万以下。

当然，这些建议知识为了尽量避免 bigkey，如果业务层的 String 类型数据确实很大，我们还可以通过数据压缩来减少数据大小；如果集合类型的元素的确很多，我们可以将一个大集合拆分成多个小集合来保存。

Redis 的 4 种集合类型 List、Hash、Set 和 Sorted Set，在集合元素个数小于一定的阈值时，会使用内存紧凑型的底层数据结构进行保存，从而节省内存。例如，假设 Hash 集合的 hash-max-ziplist-entries 配置项是 1000，如果 Haash 集合元素不超过 1000 个，就会使用 ziplist。

紧凑型数据结构虽然可以节省内存，但是会在一定程度上导致数据的读写性能下降。所以，如果业务应用更加需要保持高性能访问，而不是节省内存的话，在不会导致 bigkey 的前提下，就不用刻意控制集合元素个数了。

规范三：使用高效序列化方法和压缩方法

为了节省内存，除了采用紧凑型数据结构外，还可以使用高效的序列化方法和压缩方法，来减少 value 的大小。

Redis 中的字符串都是使用二进制安全的字节数组来保存的，所以，我们可以把业务数据序列化成二进制数据写入 Redis 中。

但是，不同的序列化方法，在序列化速度和数据序列化后的占用内存空间这两个方面，效果是不一样的。比如，protostuff 和 kryo 这两种序列化方法，就要比 Java 内置的序列化方法（java-build-in-serializer）效率更高。

此外，业务应用优势会使用字符串形式的 XML 和 JSON 格式保存数据。这样做的好处是，可读性好，便于调试，不同的开发语言都支持这两种格式的解析。

缺点在于， XML 和 JSON 格式的数据占用的内存空间大。为了避免数据占用过大的内存空间，我建议使用压缩工具（例如 snappy 或 gzip），把数据压缩后再写入 Redis。

规范四：使用证书对象共享池

证书是常用的数据类型，Redis 内部维护了 0 到 9999 这 1 万个整数对象，并把这些整数作为一个共享池使用。换句话说，如果一个键值对中有 0 到 9999 范围的整数，Redis 就不会专门为这个键值对专门创建整数对象了，而是会复用共享池中的整数对象。 这样一来，可以节省内存空间。

基于这个特点，我建议你，在满足业务数据需求的前提下，能用整数时就尽量使用整数。

不能使用整数对象共享池的情况：

• 第一种情况是，如果 Redis 中设置了 maxmemory ，而且启动了 LRU 策略（allkeys-lru 或 volatile-lru 策略），那么整数对象共享池就无法使用了。这是因为，LRU 策略需要统计每个键值对的使用时间，如果不同的键值对都共享一个整数对象，LRU 策略就无法进行统计了。
• 第二种情况，如果集合类型数据采用 ziplist 编码，而集合元素是整数，这个时候，也不能使用共享池。因为 ziplist 是紧凑内存结构，判断整数对象的共享情况效率低。

3.2 数据保存规范

规范一：使用 Redis 保存热数据

一般来说，在实际应用 Redis 时，我们会更多地把它作为缓存保存热数据，这样既可以利用 Redis 的高性能特性，还可以把宝贵的内存资源用在服务热数据上。

规范二：不同业务数据库分实例存储

虽然，我们可以使用 key 的前缀把不同业务的数据区分开，但是，如果所有业务的数据量都很大，而且访问特性也不一样，这些操作就会相互干扰。

假如数据采集业务使用 Redis 保存数据时，以写操作为主，而用户统计业务使用 Redis 时，是以读为主，如果这两个业务数据混合在一起保存，读写操作相互干扰，肯定会导致业务响应变慢。

我建议把不同的业务数据放到不同的 Redis 实例中。这样，既可以避免单实例的内存使用量过大，也避免不同业务的操作相互干扰。

规范三：在数据保存时，要设置过期时间

Redis 的内存资源非常宝贵，Redis 通常是用来保存热数据的，而热数据一般都有使用的时效性。

所以，在保存数据时，建议你根据业务使用数据的时长，设置数据的过期时间。不然的话，这些数据会一直占用内存，如果数据持续增多，就可能达到机器的内存上线，造成内存溢出。

规范四：控制 Redis 实例的容量

Redis 单实例的内存大小都不要太大，建议你设置在 2~6GB。这样一来，无论是 RDB 快照，还是主从集群进行数据同步，都能很快完成，不会阻塞正常请求的处理。

3.3 命令使用规范

规范一：线上禁用部分命令

Redis 是单线程处理请求操作，所以一些涉及大量操作、耗时长的命令，会验证阻塞主线程，导致其他请求无法得到正常处理，这类命令主要有 3 种：

• KEYS，按照键值对的 key 内容进行匹配，返回符合匹配条件的键值对，该命令需要对全局哈希表进行全表扫描，严重阻塞 Redis 主线程。
• FLUSHALL，删除 Redis 实例上的所有数据，如果数据量很大，会严重阻塞 Redis 主线程。
• FLUSHDB，删除当前数据库中的数据，如果数据量很大，同样会阻塞 Redis 主线程。

具体做法是，管理员用 rename-command 命令在配置文件中对这些命令进行重命名，让客户端 无法使用这些命令。

当然，你还可以使用其他命令代替这三个命令：

• 对 KEYS 来说，可以使用 SCAN 代替 KEYS 命令，分批返回符合条件的键值对，避免造成主线程阻塞。
• 对于 FLUSHALL、FLUSHDB，可以加上 ASYNC 选项，让这两个命令使用后台线程异步删除数据，避免造成主线程阻塞。

规范二：慎用 MONITOR 命令

Redis 的 MONITOR 命令在执行后，会持续输出检测到的各个命令操作。我们通常会用 MONITOR 命令返回的结果，检测命令的执行情况。

但是，MONITOR 会把监控到的内容持续写入输出缓冲区，如果线上命令的操作很多，输出缓冲区很快就会溢出了，这就会对 Redis 性能造成影响，甚至引起服务崩溃。

除非十分需要监测某些命令（如，Redis 性能突然变慢，我们想看下客户端执行了哪些命令），可以偶尔在短时间内使用下 MONITOR。

规范三：慎用全量操作命令

对于集合类型的数据来说，一般不加你使用权利操作的命令（如 Hash 类型的 HGETALL、Set 类型的 SMEMBERS）。这些操作会对 Hash 和 Set 类型的底层结构进行全量扫描，如果集合类型数据较多的话，就会阻塞主线程。

如果想要获得集合类型的全量数据，我给你三个小建议。

• 第一个建议是，使用 SSCAN、HSCAN 命令分批次返回集合中的数据，减少主线程的阻塞。
• 第二个建议是，你可以化整为零，把一个大的 Hash 集合拆分成多个小的 Hash 集合。这个操作对应到业务层，就是对业务数据进行拆分，按照时间、地域、用户 ID 等属性把一个大集合的业务数据拆分成多个小集合数据。例如，当你统计用户的访问情况时，就可以按照天的粒度，把每天的数据作为一个 Hash 集合。
• 最后一个建议是，如果集合类型保存的是业务数据的多个属性，而每次查询时，也需要返回这些属性，那么，你可以使用 String 类型，将这些属性序列化后保存，每次直接返回 String 数据就行，不用在对集合类型做全量扫描了。

Redis的使用规范小结

规范类别	规范内容
强制	禁用 KEYS、FLUSHALL、FLUSHDB
推荐	事业业务名做key的前缀，并使用缩写形式
推荐	控制key的长度
推荐	使用高效序列化方法和压缩方法
推荐	使用整数对象共享池
推荐	不同业务数据保存到不同的实例
推荐	数据保存时设置过期时间
推荐	慎用 MONITOR 命令
推荐	慎用全量操作命令
建议	控制String类型数据的大小不超过 10KB
建议	控制集合类型的元素个数不超过1万个
建议	使用 Redis 保存热数据
建议	把Redis实例的容量控制在2~6GB

• 强制类的规范：如果不按照规范内容来执行，就会给 Redis 的应用带来极大的负面影响，例如性能受损。
• 推荐类的规范：这个规范的内容能有效提升性能、节省内存空间，或是增加开发和运维的便捷性，你可以直接应用到实践中。
• 建议类的规范：这类规范内容和实际业务应用相关，只是从经验给你一个建议，你需要结合自己的业务场景参考使用。