Redis 的使⽤和原理

第一章:初识 Redis

1.1盛赞 Redis

Redis 是⼀种基于键值对（key-value）的 NoSQL 数据库，与很多键值对数据库不同的是，Redis

中的值可以是由 string（字符串）、hash（哈希）、list（列表）、set（集合）、zset（有序集合）、 Bitmaps（位图）、HyperLogLog、GEO（地理信息定位）等多种数据结构和算法组成，因此 Redis可以满⾜很多的应⽤场景，⽽且因为 Redis 会将所有数据都存放再内存中，所以它的读写性能⾮常惊⼈。不仅如此，Redis 还可以将内存的数据利⽤快照和⽇志的形式保存到硬盘上，这样在发⽣类似断电或者机器故障的时候，内存中的数据不会“丢失”。除了上述功能以外，Redis 还提供了键过期、发布订阅、事务、流⽔线、Lua 脚本等附加功能。总之，如果在合适的场景使⽤号 Redis，它就会像⼀把瑞⼠军⼑⼀样所向披靡。

2008 年，Redis 的作者 Salvatore Sanfilippo 在开发⼀个叫 LLOOGG 的⽹站时，需要实现⼀个⾼

性能的队列功能，最开始是使⽤ MySQL 来实现的，但后来发现⽆论怎么优化 SQL 语句等都不能使⽹站的性能提⾼上去，再加上⾃⼰囊中羞涩，于是他决定⾃⼰做⼀个专属于 LLOOGG 的数据库，这个就是 Redis 的前⾝。后来，Salvatore Sanfilippo 将 Redis 1.0 的源码发布到 Github 上，可能连他⾃⼰都没想到，Redis 后来如此受欢迎。

假如现在有⼈问 Redis 的作者都有谁在使⽤ Redis，我想他可以开句玩笑的回答：还有谁不使⽤

Redis，当然这只是开玩笑，但是从 Redis 的官⽅公司统计来看，有很多重量级的公司都在使⽤

Redis，如国外的 Twitter、Instagram、Stack Overflow、Github 等，国内就更多了，如果单单从体量来统计，新浪微博可以说是全球最⼤的 Redis 使⽤者，除了新浪微博，还有像阿⾥巴巴、腾讯、搜狐、优酷⼟⾖、美团、⼩⽶、唯品会等公司都是 Redis 的使⽤者。除此之外，许多开源技术像 ELK 等

已经把 Redis 作为它们组件中的重要⼀环，⽽且 Redis 还提供了模块系统让第三⽅⼈员实现功能扩展，让 Redis 发挥出更⼤的威⼒。所以，可以这么说，熟练使⽤和运维 Redis 已经成为开发运维⼈员的⼀个必备技能。

1.2 Redis 特性

Redis 之所以受到如此多公司的⻘睐，必然有之过⼈之处，下⾯是关于 Redis 的 8 个重要特性。

1. 速度快

正常情况下，Redis 执⾏命令的速度⾮常快，官⽅给出的数字是读写性能可以达到 10 万 / 秒，当

然这也取决于机器的性能，但这⾥先不讨论机器性能上的差异，只分析⼀下是什么造就了 Redis 如此之快，可以⼤概归纳为以下四点：

• Redis 的所有数据都是存放在内存中的，下表是⾕歌公司 2009 年给出的各层级硬件执⾏速度，所以把数据放在内存中是 Redis 速度快的最主要原因。

2. 基于键值对的数据结构服务器

⼏乎所有的编程语⾔都提供了类似字典的功能，例如 C++ ⾥的 map、Java ⾥的 map、Python ⾥

的 dict 等，类似于这种组织数据的⽅式叫做基于键值对的⽅式，与很多键值对数据库不同的是，

Redis 中的值不仅可以是字符串，⽽且还可以是具体的数据结构，这样不仅能便于在许多应⽤场景的开发，同时也能提⾼开发效率。Redis 的全程是 REmote Dictionary Server，它主要提供了 5 种数据结构：字符串（string）、哈希（hash）、列表（list）、集合（set）、有序集合（ordered set / zset），同时在字符串的基础之上演变出了位图（Bitmaps）和 HyperLogLog 两种神奇的 ”数据结构“，并且随着 LBS（Location Based Service，基于位置服务）的不断发展，Redis 3.2. 版本种加⼊有关 GEO（地理信息定位）的功能，总之在这些数据结构的帮助下，开发者可以开发出各种 “有意思” 的应⽤。

3. 丰富的功能

除了 5 种数据结构，Redis 还提供了许多额外的功能：

• 提供了键过期功能，可以⽤来实现缓存。

• 提供了发布订阅功能，可以⽤来实现消息系统。

• ⽀持 Lua 脚本功能，可以利⽤ Lua 创造出新的 Redis 命令。

• 提供了简单的事务功能，能在⼀定程度上保证事务特性。

• 提供了流⽔线（Pipeline）功能，这样客⼾端能将⼀批命令⼀次性传到 Redis，减少了⽹络的开

销。

4. 简单稳定

Redis 的简单主要表现在三个⽅⾯。⾸先，Redis 的源码很少，早期版本的代码只有 2 万⾏左右，

3.0 版本以后由于添加了集群特性，代码增⾄ 5 万⾏左右，相对于很多 NoSQL 数据库来说代码量相对要少很多，也就意味着普通的开发和运维⼈员完全可以 “吃透” 它。其次， Redis 使⽤单线程模型 ， 这样不仅使得 Redis 服务端处理模型变得简单，⽽且也使得客⼾端开发变得简单。最后，Redis 不需要依赖于操作系统中的类库（例如 Memcache 需要依赖 libevent 这样的系统类库），Redis ⾃⼰实现了事件处理的相关功能。

但与简单相对的是 Redis 具备相当的稳定性，在⼤量使⽤过程中，很少出现因为 Redis ⾃⾝ BUG

⽽导致宕掉的情况。

5. 客⼾端语⾔多

Redis 提供了简单的 TCP 通信协议，很多编程语⾔可以很⽅便地接⼊到 Redis，并且由于 Redis 受到社区和各⼤公司的⼴泛认可，所以⽀持 Redis 的客⼾端语⾔也⾮常多，⼏乎涵盖了主流的编程语⾔，例如 C、C++、Java、PHP、Python、NodeJS 等，后续我们会对 Redis 的客⼾端使⽤做详细说明。

6. 持久化（Persistence）

通常看，将数据放在内存中是不安全的，⼀旦发⽣断电或者机器故障，重要的数据可能就会丢

失，因此 Redis 提供了两种持久化⽅式：RDB 和 AOF，即可以⽤两种策略将内存的数据保存到硬盘中

（如图 1-1 所⽰），这样就保证了数据的可持久性，后续我们将对 Redis 的持久化进⾏详细说明。

7. 主从复制（Replication）

Redis 提供了复制功能，实现了多个相同数据的 Redis 副本（Replica）（如图 1- 2 所⽰），复制

功能是分布式 Redis 的基础。后续我们会对 Redis 的复制功能进⾏详细演⽰。

8. ⾼可⽤（High Availability）和分布式（Distributed）

Redis 提供了⾼可⽤实现的 Redis 哨兵（Redis Sentinel），能够保证 Redis 结点的故障发现和故

障⾃动转移。也提供了 Redis 集群（Redis Cluster），是真正的分布式实现，提供了⾼可⽤、读写和容量的扩展性

1.3 Redis 使⽤场景

1.3.1 Redis 可以做什么

1. 缓存（Cache）

缓存机制⼏乎在所有⼤型⽹站都有使⽤，合理地使⽤缓存不仅可以加速数据的访问速度，⽽且能

够有效地降低后端数据源的压⼒。Redis 提供了键值过期时间设置，并且也提供了灵活控制最⼤内存和内存溢出后的淘汰策略。可以这么说，⼀个合理的缓存设计能够为⼀个⽹站的稳定保驾护航。

2. 排⾏榜系统

排⾏榜系统⼏乎存在于所有的⽹站，例如按照热度排名的排⾏榜，按照发布时间的排⾏榜，按照

各种复杂维度计算出的排⾏榜，Redis 提供了列表和有序集合的结构，合理地使⽤这些数据结构可以很⽅便地构建各种排⾏榜系统。

3. 计数器应⽤

计数器在⽹站中的作⽤⾄关重要，例如视频⽹站有播放数、电商⽹站有浏览数，为了保证数据的

实时性，每⼀次播放和浏览都要做加 1 的操作，如果并发量很⼤对于传统关系型数据的性能是⼀种挑战。Redis 天然⽀持计数功能⽽且计数的性能也⾮常好，可以说是计数器系统的重要选择。

4. 社交⽹络

赞 / 踩、粉丝、共同好友 / 喜好、推送、下拉刷新等是社交⽹站的必备功能，由于社交⽹站访问量

通常⽐较⼤，⽽且传统的关系型数据不太合适保存这种类型的数据，Redis 提供的数据结构可以相对⽐较容易地实现这些功能。

5. 消息队列系统

消息队列系统可以说是⼀个⼤型⽹站的必备基础组件，因为其具有业务解耦、⾮实时业务削峰等

特性。Redis 提供了发布订阅功能和阻塞队列的功能，虽然和专业的消息队列⽐还不够⾜够强⼤，但是对于⼀般的消息队列功能基本可以满⾜

1.3.2 Redis 不可以做什么

实际上和任何⼀⻔技术⼀样，每个技术都有⾃⼰的应⽤场景和边界，也就是说 Redis 并不是万⾦

油，有很多合适它解决的问题，但是也有很多不合适它解决的问题。 我们可以站在数据规模和数据冷热的⻆度来进⾏分析。

站在数据规模的⻆度看，数据可以分为⼤规模数据和⼩规模数据，我们知道 Redis 的数据是存放

在内存中的，虽然现在内存已经⾜够便宜，但是如果数据量⾮常⼤，例如每天有⼏亿的⽤⼾⾏为数

据，使⽤ Redis 来存储的话，基本上是个⽆底洞，经济成本相当⾼。

站在数据冷热的⻆度，数据分为热数据和冷数据，热数据通常是指需要频繁操作的数据，反之为

冷数据 ，例如对于视频⽹站来说，视频基本信息基本上在各个业务线都是经常要操作的数据，⽽⽤⼾的观看记录不⼀定是经常需要访问的数据，这⾥暂且不讨论两者数据规模的差异，单纯站在数据冷热的⻆度上看，视频信息属于热数据，⽤⼾观看记录属于冷数据。如果将这些冷数据放在 Redis 上，基本上是对于内存的⼀种浪费，但是对于⼀些热数据可以放在 Redis 中加速读写，也可以减轻后端存储的负载，可以说是事半功倍。

所以，Redis 并不是万⾦油，相信随着我们对 Redis 的逐步学习，能够清楚 Redis 真正的使⽤场

景。

第⼆章 Redis 常⻅数据类型

2.1.1 基本全局命令

Redis 有 5 种数据结构，但它们都是键值对种的值，对于键来说有⼀些通⽤的命令。

KEYS

返回所有满⾜样式（pattern）的 key。⽀持如下统配样式。

• h?llo 匹配 hello , hallo 和 hxllo

• h*llo 匹配 hllo 和 heeeello

• h[ae]llo 匹配 hello 和 hallo 但不匹配 hillo

• h[^e]llo 匹配 hallo , hbllo , ... 但不匹配 hello

• h[a-b]llo 匹配 hallo 和 hbllo

返回值：匹配 pattern 的所有 key。

EXISTS

判断某个 key 是否存在。

DEL

删除指定的 key。

返回值：删除掉的 key 的个数

EXPIRE

为指定的 key 添加秒级的过期时间（Time To Live TTL）

返回值：1 表⽰设置成功。0 表⽰设置失败

TTL

获取指定 key 的过期时间，秒级

剩余过期时间。-1 表⽰没有关联过期时间，-2 表⽰ key 不存在。

关于键过期机制，可以参考图 2-1 所⽰。

TYPE

返回 key 对应的数据类型。

返回值： none , string , list , set , zset , hash and stream

2.1.2 数据结构和内部编码

type 命令实际返回的就是当前键的数据结构类型，它们分别是：string（字符串）、list（列

表）、hash（哈希）、set（集合）、zset（有序集合），但这些只是 Redis 对外的数据结构。

Redis 的 5 种数据类型

实际上 Redis 针对每种数据结构都有⾃⼰的底层内部编码实现，⽽且是多种实现，这样 Redis 会

在合适的场景选择合适的内部编码，如表 2-1 所⽰。

可以看到每种数据结构都有⾄少两种以上的内部编码实现，例如 list 数据结构包含了 linkedlist 和

ziplist 两种内部编码。同时有些内部编码，例如 ziplist，可以作为多种数据结构的内部实现，可以通过 object encoding 命令查询内部编码

可以看到 hello 对应值的内部编码是 embstr，键 mylist 对应值的内部编码是 ziplist。

Redis 这样设计有两个好处：

1）可以改进内部编码，⽽对外的数据结构和命令没有任何影响，这样⼀旦开发出更优秀的内部编码，⽆需改动外部数据结构和命令，例如 Redis 3.2 提供了 quicklist，结合了 ziplist 和 linkedlist 两者的优势，为列表类型提供了⼀种更为优秀的内部编码实现，⽽对⽤⼾来说基本⽆感知。

2）多种内部编码实现可以在不同场景下发挥各⾃的优势，例如 ziplist ⽐较节省内存，但是在列表元素⽐较多的情况下，性能会下降，这时候 Redis 会根据配置选项将列表类型的内部实现转换为

linkedlist，整个过程⽤⼾同样⽆感知。

2.1.3 单线程架构

Redis 使⽤了单线程架构来实现⾼性能的内存数据库服务，本节⾸先通过多个客⼾端命令调⽤的例

⼦说明 Redis 单线程命令处理机制，接着分析 Redis 单线程模型为什么性能如此之⾼，最终给出为什么理解单线程模型是使⽤和运维 Redis 的关键。

1. 引出单线程模型

redis单线程,只有一个线程去接收处理所有的请求,并不是服务器进程内部只有一个线程,其实也有很多线程,这些线程都在处理网络IO

上面这个情况,可能会有线程安全问题

其实redis服务器并不会有这种情况,因为redis服务器是单线程服务器,把接收到的请求串行执行,多个请求到达redis队列中,也是需要进行排队等候的.

redis能够使用单线程模型,很好的工作,是因为redis处理的业务逻辑是短平快,不消耗CPU资源,如果一个操作执行的时间太长,就会影响其他的请求的执行

2.为什么redis是单线程,速度还能这么快,效率这么高?

他的速度快和效率高是与关系性数据库(MySQL,Orcale)进行对比

1.redis直接访问的是内存,而关系性数据库访问的硬盘

2.redis的核心功能,比关系性数据库的核心功能要简单,数据库对于数据的插入查询,都有更复杂的功能支持,

3.单线程模型,减少了不必要的线程竞争开销,redis每个操作都是短平快,不涉及特别消耗cpu的操作

4.处理网络IO的时候,使用了epoll这样的IO多路复用机制,IO多路复用机制,一个线程就可以处理多个socket,,epoll事件通知/回调机制,一个线程可以完成好多任务,前提是这些任务的交互不频繁,大部分时间都在等,可以采取epoll多路复用机制

1.String 字符串

在redis中,所以的key都是string类型,value的数据类型才有差异

字符串类型是 Redis 最基础的数据类型，直接按照二进制数据的方式进行存储,不会做任何的编码转化,存的是啥,取出来就是啥,关于字符串需要特别注意：1）⾸先 Redis 中所有的键的 类型都是字符串类型，⽽且其他⼏种数据结构也都是在字符串类似基础上构建的，例如列表和集合的元素类型是字符串类型，所以字符串类型能为其他 4 种数据结构的学习奠定基础。2）其次，如图 2-7所⽰，字符串类型的值实际可以是字符串，包含⼀般格式的字符串或者类似 JSON、XML 格式的字符串；数字，可以是整型或者浮点型；甚⾄是⼆进制流数据，例如图⽚、⾳频、视频等。不过⼀个字符串的最⼤值不能超过 512 MB。

常见命令

SET

将 string 类型的 value 设置到 key 中。如果 key 之前存在，则覆盖，⽆论原来的数据类型是什么。之前关于此 key 的 TTL 也全部失效。

语法：

1 SET key value [expiration EX seconds|PX milliseconds] [NX|XX]

命令有效版本：1.0.0 之后

时间复杂度：O(1)

SET 命令⽀持多种选项来影响它的⾏为：

• EX seconds⸺使⽤秒作为单位设置 key 的过期时间。

• PX milliseconds ⸺使⽤毫秒作为单位设置 key 的过期时间。

• NX ⸺只在 key 不存在时才进⾏设置，即如果 key 之前已经存在，设置不执⾏。

• XX ⸺只在 key 存在时才进⾏设置，即如果 key 之前不存在，设置不执⾏。

返回值：

• 如果设置成功，返回 OK。

• 如果由于 SET 指定了 NX 或者 XX 但条件不满⾜，SET 不会执⾏，并返回 (nil)。

GET

获取 key 对应的 value。如果 key 不存在，返回 nil。如 果 value 的数据类型不是 string，会报错 。

语法：

1 GET key

命令有效版本：1.0.0 之后

时间复杂度：O(1)

返回值：key 对应的 value，或者 nil 当 key 不存在。

MGET

⼀次性获取多个 key 的值。如果对应的 key 不存在或者对应的数据类型不是 string，返回 nil。

语法：

1 MGET key [key ...]

命令有效版本：1.0.0 之后

时间复杂度：O(N) N 是 key 数量

返回值：对应 value 的列表

MSET

⼀次性设置多个 key 的值。

语法：

1 MSET key value [key value ...]

命令有效版本：1.0.1 之后

时间复杂度：O(N) N 是 key 数量

返回值：永远是 OK

学会使⽤批量操作，可以有效提⾼业务处理效率，但是要注意，每次批量操作所发送的键的数量也不是⽆节制的，否则可能造成单⼀命令执⾏时间过⻓，导致 Redis 阻塞。

SETNX

设置 key-value 但只允许在 key 之前不存在的情况下。

语法：

1 SETNX key value

命令有效版本：1.0.0 之后

时间复杂度：O(1)

返回值：1 表⽰设置成功。0 表⽰没有设置。

SET、SET NX、SET XX 执⾏流程

计数命令

INCR

将 key 对应的 string 表⽰的数字加⼀。如果 key 不存在，则视为 key 对应的 value 是 0。如果 key 对应的 string 不是⼀个整型或者范围超过了 64 位有符号整型，则报错。

INCRBY

将 key 对应的 string 表⽰的数字加上对应的值。如果 key 不存在，则视为 key 对应的 value 是 0。如果 key 对应的 string 不是⼀个整型或者范围超过了 64 位有符号整型，则报错。

返回值：integer 类型的加完后的数值。

DECR

将 key 对应的 string 表⽰的数字减⼀。如果 key 不存在，则视为 key 对应的 value 是 0。如果 key 对应的 string 不是⼀个整型或者范围超过了 64 位有符号整型，则报错

DECYBY

将 key 对应的 string 表⽰的数字减去对应的值。如果 key 不存在，则视为 key 对应的 value 是 0。如果 key 对应的 string 不是⼀个整型或者范围超过了 64 位有符号整型，则报错。

INCRBYFLOAT

将 key 对应的 string 表⽰的浮点数加上对应的值。如果对应的值是负数，则视为减去对应的值。如果key 不存在，则视为 key 对应的 value 是 0。如果 key 对应的不是 string，或者不是⼀个浮点数，则报错。允许采⽤科学计数法表⽰浮点数。

很多存储系统和编程语⾔内部使⽤ CAS 机制实现计数功能，会有⼀定的 CPU 开销，但在 Redis 中完全不存在这个问题，因为 Redis 是单线程架构，任何命令到了 Redis 服务端都要顺序执⾏。

APPEND

如果 key 已经存在并且是⼀个 string，命令会将 value 追加到原有 string 的后边。如果 key 不存在，则效果等同于 SET 命令。

语法：

1 APPEND KEY VALUE

时间复杂度：O(1). 追加的字符串⼀般⻓度较短, 可以视为 O(1).

返回值：追加完成之后 string 的⻓度。

GETRANGE

返回 key 对应的 string 的⼦串，由 start 和 end 确定（左闭右闭）。可以使⽤负数表⽰倒数。-1 代表倒数第⼀个字符，-2 代表倒数第⼆个，其他的与此类似。超过范围的偏移量会根据 string 的⻓度调整成正确的值。

语法：

1 GETRANGE key start end

时间复杂度：O(N). N 为 [start, end] 区间的⻓度. 由于 string 通常⽐较短, 可以视为是 O(1)

返回值：string 类型的⼦串

SETRANGE

覆盖字符串的⼀部分，从指定的偏移开始。

语法：

1 SETRANGE key offset value

时间复杂度：O(N), N 为 value 的⻓度. 由于⼀般给的 value ⽐较短, 通常视为 O(1).

返回值：替换后的 string 的⻓度。

STRLEN

获取 key 对应的 string 的⻓度。当 key 存放的类似不是 string 时，报错。

语法：

1 STRLEN key

时间复杂度：O(1)

返回值：string 的⻓度。或者当 key 不存在时，返回 0

命令⼩结

字符串类型命令的效果、时间复杂度，可以参考此表，结合业务需求和数据⼤⼩选择合适的命令。

内部编码

字符串类型的内部编码有 3 种：使用object encoding来查询当前编码

int：8 个字节的⻓整型。

embstr：⼩于等于 39 个字节的字符串。

raw：⼤于 39 个字节的字符串

典型使⽤场景

缓存（Cache）功能

图 2-10 是⽐较典型的缓存使⽤场景，其中 Redis 作为缓冲层，MySQL 作为存储层，绝⼤部分请

求的数据都是从 Redis 中获取。由于 Redis 具有⽀撑⾼并发的特性，所以缓存通常能起到加速读写和降低后端压⼒的作⽤。

举一个例子来理解一下缓存

这是一段伪代码

1）假设业务是根据⽤⼾ uid 获取⽤⼾信息

UserInfo getUserInfo(long uid) {

...

}

2）⾸先从 Redis 获取⽤⼾信息，我们假设⽤⼾信息保存在 "user:info:<uid>" 对应的键中：

// 根据 uid 得到 Redis 的键

String key = "user:info:" + uid;

// 尝试从 Redis 中获取对应的值

String value = Redis 执⾏命令： get key;

// 如果缓存命中（ hit ）

if (value != null) {

// 假设我们的⽤⼾信息按照 JSON 格式存储

UserInfo userInfo = JSON 反序列化 (value);

return userInfo;

}

如果没有从 Redis 中得到⽤⼾信息，及缓存 miss，则进⼀步从 MySQL 中获取对应的信息，随后写⼊缓存并返回：

// 如果缓存未命中（ miss ）

if (value == null) {

// 从数据库中，根据 uid 获取⽤⼾信息

UserInfo userInfo = MySQL 执⾏ SQL ： select * from user_info where uid = <uid>

// 如果表中没有 uid 对应的⽤⼾信息

if (userInfo == null) {

响应 404

return null;

}

// 将⽤⼾信息序列化成 JSON 格式

String value = JSON 序列化 (userInfo);

// 写⼊缓存，为了防⽌数据腐烂（ rot ），设置过期时间为 1 ⼩时（ 3600 秒）

Redis 执⾏命令： set key value ex 3600

// 返回⽤⼾信息

return userInfo;

}

redis这样的缓存,经常存储"热点"数据(被高频使用的数据),最近一段时间都会反复用到的数据,

计数（Counter）功能

许多应⽤都会使⽤ Redis 作为计数的基础⼯具，它可以实现快速计数、查询缓存的功能，同时数

据可以异步处理或者落地到其他数据源。如图 2-11 所⽰，例如视频⽹站的视频播放次数可以使⽤

Redis 来完成：⽤⼾每播放⼀次视频，相应的视频播放数就会⾃增 1。

// 在 Redis 中统计某视频的播放次数

long incrVideoCounter(long vid) {

key = "video:" + vid;

long count = Redis 执⾏命令： incr key

return count;

}

共享会话（Session）

如图 2-12 所⽰，⼀个分布式 Web 服务将⽤⼾的 Session 信息（例如⽤⼾登录信息）保存在各⾃

的服务器中，但这样会造成⼀个问题：出于负载均衡的考虑，分布式服务会将⽤⼾的访问请求均衡到不同的服务器上，并且通常⽆法保证⽤⼾每次请求都会被均衡到同⼀台服务器上，这样当⽤⼾刷新⼀次访问是可能会发现需要重新登录，这个问题是⽤⼾⽆法容忍的。

为了解决这个问题，可以使⽤ Redis 将⽤⼾的 Session 信息进⾏集中管理，如图 2-13 所⽰，在这种模式下，只要保证 Redis 是⾼可⽤和可扩展性的，⽆论⽤⼾被均衡到哪台 Web 服务器上，都集中从Redis 中查询、更新 Session 信息。

⼿机验证码

很多应⽤出于安全考虑，会在每次进⾏登录时，让⽤⼾输⼊⼿机号并且配合给⼿机发送验证码，

然后让⽤⼾再次输⼊收到的验证码并进⾏验证，从⽽确定是否是⽤⼾本⼈。为了短信接⼝不会频繁访问，会限制⽤⼾每分钟获取验证码的频率，例如⼀分钟不能超过 5 次

此功能可以⽤以下伪代码说明基本实现思路：

2.Hash 哈希

⼏乎所有的主流编程语⾔都提供了哈希（hash）类型，它们的叫法可能是哈希、字典、关联数

组、映射。在 Redis 中，哈希类型是指值本⾝⼜是⼀个键值对结构，形如 key = "key"，value = { {

field1, value1 }, ..., {fieldN, valueN } }，Redis 键值对和哈希类型⼆者的关系可以⽤图 2-15 来表⽰。

常见命令

1.HSET

设置 hash 中指定的字段（field）的值（value）。

语法：

HSET key field value [field value ...]

时间复杂度：插⼊⼀组 field 为 O(1), 插⼊ N 组 field 为 O(N)

返回值：添加的字段的个数。

2.HGET

获取 hash 中指定字段的值。

语法：

1 HGET key field

时间复杂度：O(1)

返回值：字段对应的值或者 nil。

3.HEXISTS

判断 hash 中是否有指定的字段。

语法：

HEXISTS key field

时间复杂度：O(1)

返回值：1 表⽰存在，0 表⽰不存在。

4.HDEL

删除 hash 中指定的字段。

语法：

1 HDEL key field [field ...]

时间复杂度：删除⼀个元素为 O(1). 删除 N 个元素为 O(N).

返回值：本次操作删除的字段个数。

5.HKEYS

获取 hash 中的所有字段。

语法：

HKEYS key

时间复杂度：O(N), N 为 field 的个数.

返回值：字段列表。

6.HVALS

获取 hash 中的所有的值。

语法：

HVALS key

时间复杂度：O(N), N 为 field 的个数.

返回值：所有的值。

6.HGETALL

获取 hash 中的所有字段以及对应的值。

语法：

HGETALL key

时间复杂度：O(N), N 为 field 的个数.

返回值：字段和对应的值。

7.HMGET

⼀次获取 hash 中多个字段的值。

语法：

HMGET key field [field ...]

时间复杂度：只查询⼀个元素为 O(1), 查询多个元素为 O(N), N 为查询元素个数.

返回值：字段对应的值或者 nil。

在使⽤ HGETALL 时，如果哈希元素个数⽐较多，会存在阻塞 Redis 的可能。如果开发⼈员只

需要获取部分 field，可以使⽤ HMGET，如果⼀定要获取全部 field，可以尝试使⽤ HSCAN

命令，该命令采⽤渐进式遍历哈希类型，

8.HLEN

获取 hash 中的所有字段的个数。

语法：

HLEN key

时间复杂度：O(1)

返回值：字段个数。

9.HSETNX

在字段不存在的情况下，设置 hash 中的字段和值。

语法：

HSETNX key field value

时间复杂度：O(1)

返回值：1 表⽰设置成功，0 表⽰失败。

10.HINCRBY

将 hash 中字段对应的数值添加指定的值。

语法：

HINCRBY key field increment

时间复杂度：O(1)

返回值：该字段变化之后的值

HINCRBYFLOAT

HINCRBY 的浮点数版本。

语法：

HINCRBYFLOAT key field increment

时间复杂度：O(1)

返回值：该字段变化之后的值。

命令⼩结

表 2-4 是哈希类型命令的效果、时间复杂度，开发⼈员可以参考此表，结合⾃⾝业务需求和数据

⼤⼩选择合适的命令。

内部编码

哈希的内部编码有两种：

ziplist（压缩列表）：

当哈希类型元素个数⼩于 hash-max-ziplist-entries 配置（默认 512 个）、

同时所有值都⼩于 hash-max-ziplist-value 配置（默认 64 字节）时，Redis 会使⽤ ziplist 作为哈

希的内部实现，ziplist 使⽤更加紧凑的结构实现多个元素的连续存储，所以在节省内存⽅⾯⽐

hashtable 更加优秀。

hashtable（哈希表）：

当哈希类型⽆法满⾜ ziplist 的条件时，Redis 会使⽤ hashtable 作为哈希

的内部实现，因为此时 ziplist 的读写效率会下降，⽽ hashtable 的读写时间复杂度为 O(1)。

下⾯的⽰例演⽰了哈希类型的内部编码，以及响应的变化

1）当 field 个数⽐较少且没有⼤的 value 时，内部编码为 ziplist：

2）当有 value ⼤于 64 字节时，内部编码会转换为 hashtable：

3）当 field 个数超过 512 时，内部编码也会转换为 hashtable：

使⽤场景

图 2-16 为关系型数据表记录的两条⽤⼾信息，⽤⼾的属性表现为表的列，每条⽤⼾信息表现为

⾏。

。如果映射关系表⽰这两个⽤⼾信息，则如图 2-17 所⽰。

相⽐于使⽤ JSON 格式的字符串缓存⽤⼾信息，哈希类型变得更加直观，并且在更新操作上变得

更灵活。可以将每个⽤⼾的 id 定义为键后缀，多对 field-value 对应⽤⼾的各个属性

注意

哈希类型和关系型数据库有两点不同之处：

•

哈希类型是稀疏的，⽽关系型数据库是完全结构化的，例如哈希类型每个键可以有不同的 field，⽽

关系型数据库⼀旦添加新的列，所有⾏都要为其设置值，即使为 null，如图 2-18 所⽰。

•

关系数据库可以做复杂的关系查询，⽽ Redis 去模拟关系型复杂查询，例如联表查询、聚合查询等

基本不可能，维护成本⾼。

缓存⽅式对⽐

截⾄⽬前为⽌，我们已经能够⽤三种⽅法缓存⽤⼾信息，下⾯给出三种⽅案的实现⽅法和优缺点

分析。

1. 原⽣字符串类型

使⽤字符串类型，每个属性⼀个键。

set user:1:name James

set user:1:age 23

set user:1:city Beijing

优点：实现简单，针对个别属性变更也很灵活。

缺点：占⽤过多的键，内存占⽤量较⼤，同时⽤⼾信息在 Redis 中⽐较分散，缺少内聚性，所以这种⽅案基本没有实⽤性。

2. 序列化字符串类型，例如 JSON 格式

set user:1 经过序列化后的⽤⼾对象字符串

优点：针对总是以整体作为操作的信息⽐较合适，编程也简单。同时，如果序列化⽅案选择合适，内存的使⽤效率很⾼。

缺点：本⾝序列化和反序列需要⼀定开销，同时如果总是操作个别属性则⾮常不灵活。

3. 哈希类型         

hmset user:1 name James age 23 city Beijing

优点：简单、直观、灵活。尤其是针对信息的局部变更或者获取操作。

缺点：需要控制哈希在 ziplist 和 hashtable 两种内部编码的转换，可能会造成内存的较⼤消耗。

关于内聚和耦合

高内聚:有关联的代码紧密联系在一起

低耦合:代码的各个模块之间影响不大

3.List列表

列表类型是⽤来存储多个有序的字符串，如图 2-19 所⽰，a、b、c、d、e 五个元素从左到右组成

了⼀个有序的列表，列表中的每个字符串称为元素（element），⼀个列表最多可以存储 个元

素。在 Redis 中，可以对列表两端插⼊（push）和弹出（pop），还可以获取指定范围的元素列表、获取指定索引下标的元素等（如图 2-19 和图 2-20 所⽰）。列表是⼀种⽐较灵活的数据结构，它可以充当栈和队列的⻆⾊，在实际开发上有很多应⽤场景

列表类型的特点：

第⼀:

列表中的元素是有序的，这意味着可以通过索引下标获取某个元素或者某个范围的元素列表，

例如要获取图 2-20 的第 5 个元素，可以执⾏ lindex user:1:messages 4 或者倒数第 1 个元素，lindex user:1:messages -1 就可以得到元素 e。

第⼆

区分获取和删除的区别，例如图 2-20 中的 lrem 1 b 是从列表中把从左数遇到的前 1 个 b 元素删

除，这个操作会导致列表的⻓度从 5 变成 4；但是执⾏ lindex 4 只会获取元素，但列表⻓度是不会变化的。

第三

列表中的元素是允许重复的，例如图 2-21 中的列表中是包含了两个 a 元素的。

常见命令

LPUSH(头插)

将⼀个或者多个元素从左侧放⼊（头插）到 list 中。

语法：

LPUSH key element [element ...]

时间复杂度：只插⼊⼀个元素为 O(1), 插⼊多个元素为 O(N), N 为插⼊元素个数.

返回值：插⼊后 list 的⻓度

LPUSHX

在 key 存在时，将⼀个或者多个元素从左侧放⼊（头插）到 list 中。不存在，直接返回0

语法：

1 LPUSHX key element [element ...]

时间复杂度：只插⼊⼀个元素为 O(1), 插⼊多个元素为 O(N), N 为插⼊元素个数.

返回值：插⼊后 list 的⻓度。

RPUSH(尾插)

将⼀个或者多个元素从右侧放⼊（尾插）到 list 中。

语法：

RPUSH key element [element ...]

时间复杂度：只插⼊⼀个元素为 O(1), 插⼊多个元素为 O(N), N 为插⼊元素个数.

返回值：插⼊后 list 的⻓度。

RPUSHX

在 key 存在时，将⼀个或者多个元素从右侧放⼊（尾插）到 list 中。

语法：

RPUSHX key element [element ...]

时间复杂度：只插⼊⼀个元素为 O(1), 插⼊多个元素为 O(N), N 为插⼊元素个数.

返回值：插⼊后 list 的⻓度。

LRANGE

获取从 start 到 end 区间的所有元素，左闭右闭。

语法：

LRANGE key start stop

时间复杂度：O(N)

返回值：指定区间的元素。

LPOP(头删)

从 list 左侧取出元素（即头删）。

语法：

LPOP key

时间复杂度：O(1)

返回值：取出的元素或者 nil。

RPOP(尾删)

从 list 右侧取出元素（即尾删）。

语法：

RPOP key

时间复杂度：O(1)

返回值：取出的元素或者 nil。

LINDEX

获取从左数第 index 位置的元素。

语法：

LINDEX key index

时间复杂度：O(N)

返回值：取出的元素或者 nil

LINSERT

在特定位置插⼊元素。

语法：

LINSERT key <BEFORE | AFTER> pivot element

时间复杂度：O(N)

返回值：插⼊后的 list ⻓度。

LLEN

获取 list ⻓度。

语法：

LLEN key

时间复杂度：O(1)

返回值：list 的⻓度。

LREM

指定元素精准删除

1.当count>0时,从头开始删除指定元素的次数

2.当count<0时,从尾开始删除指定元素的次数

3.当count=0时,删除全部指定的元素

LTRIM

只保留范围内的元素

LSET

根据下标修改元素

阻塞版本命令

blpop 和 brpop 是 lpop 和 rpop 的阻塞版本，和对应⾮阻塞版本的作⽤基本⼀致，除了：

•

在列表中有元素的情况下，阻塞和⾮阻塞表现是⼀致的。但如果列表中没有元素，⾮阻塞版本会理

解返回 nil，但阻塞版本会根据 timeout，阻塞⼀段时间，期间 Redis 可以执⾏其他命令，但要求执

⾏该命令的客⼾端会表现为阻塞状态（如图 2-22 所⽰）。

•

命令中如果设置了多个键，那么会从左向右进⾏遍历键，⼀旦有⼀个键对应的列表中可以弹出元

素，命令⽴即返回。

•

如果多个客⼾端同时多⼀个键执⾏ pop，则最先执⾏命令的客⼾端会得到弹出的元素。

BLPOP

LPOP 的阻塞版本。

语法：

BLPOP key [key ...] timeout

时间复杂度：O(1)

返回值：取出的元素或者 nil。

BRPOP

RPOP 的阻塞版本。

语法：

BRPOP key [key ...] timeout

时间复杂度：O(1)

返回值：取出的元素或者 nil。

 

内部编码

列表类型的内部编码有两种：

•

ziplist（压缩列表）：

当列表的元素个数⼩于 list-max-ziplist-entries 配置（默认 512 个），同时

列表中每个元素的⻓度都⼩于 list-max-ziplist-value 配置（默认 64 字节）时，Redis 会选⽤

ziplist 来作为列表的内部编码实现来减少内存消耗。

linkedlist（链表）：

当列表类型⽆法满⾜ ziplist 的条件时，Redis 会使⽤ linkedlist 作为列表的内部实现。

quicklist

每个节点都是一个压缩列表,以链表的形式连接起来

使⽤场景

作为数组

消息队列

如图 2-22 所⽰，Redis 可以使⽤ lpush + brpop 命令组合实现经典的阻塞式⽣产者-消费者模型队列，⽣产者客⼾端使⽤ lpush 从列表左侧插⼊元素，多个消费者客⼾端使⽤ brpop 命令阻塞式地从队列中"争抢" 队⾸元素。通过多个客⼾端来保证消费的负载均衡和⾼可⽤性。

分频道的消息队列

如图 2-23 所⽰，Redis 同样使⽤ lpush + brpop 命令，但通过不同的键模拟频道的概念，不同的消费者可以通过 brpop 不同的键值，实现订阅不同频道的理念。

微博 Timeline

每个⽤⼾都有属于⾃⼰的 Timeline（微博列表），现需要分⻚展⽰⽂章列表。此时可以考虑使⽤

列表，因为列表不但是有序的，同时⽀持按照索引范围获取元素。

1）每篇微博使⽤哈希结构存储，例如微博中 3 个属性：title、timestamp、content：

hmset mblog:1 title xx timestamp 1476536196 content xxxxx

...

hmset mblog:n title xx timestamp 1476536196 content xxxxx

2）向⽤⼾ Timeline 添加微博，user:<uid>:mblogs 作为微博的键：

lpush user:1:mblogs mblog:1 mblog:3

...

lpush user:k:mblogs mblog:9

3）分⻚获取⽤⼾的 Timeline，例如获取⽤⼾ 1 的前 10 篇微博：

keylist = lrange user:1:mblogs 0 9

for key in keylist {

hgetall key

}

此⽅案在实际中可能存在两个问题：

1. 1 + n 问题。即如果每次分⻚获取的微博个数较多，需要执⾏多次 hgetall 操作，此时可以考虑使⽤pipeline（流⽔线）模式批量提交命令，或者微博不采⽤哈希类型，⽽是使⽤序列化的字符串类型，使⽤ mget 获取。

2. 分裂获取⽂章时，lrange 在列表两端表现较好，获取列表中间的元素表现较差，此时可以考虑将列表做拆分。

4.set集合

集合类型也是保存多个字符串类型的元素的，但和列表类型不同的是，集合中 1）元素之间是⽆序

的 2）元素不允许重复，如图 2-24 所⽰。⼀个集合中最多可以存储 个元素。Redis 除了⽀持

集合内的增删查改操作，同时还⽀持多个集合取交集、并集、差集，合理地使⽤好集合类型，能在实际开发中解决很多问题。

set这个术语有不同的含义,如果是集合的话,就是把有关联的数据联系在一起,集合中的元素是无序的,集合中的元素是唯一的,集合中的每个元素都是string类型的

基本命令

SADD

将⼀个或者多个元素添加到 set 中。注意，重复的元素⽆法添加到 set 中。

语法：

SADD key member [member ...]

时间复杂度：O(1)

返回值：本次添加成功的元素个数

SMEMBERS

获取⼀个 set 中的所有元素，注意，元素间的顺序是⽆序的。

语法：

SMEMBERS key

时间复杂度：O(N)

返回值：所有元素的列表。

SISMEMBER

判断⼀个元素在不在 set 中。

语法：

SISMEMBER key member

时间复杂度：O(1)

返回值：1 表⽰元素在 set 中。0 表⽰元素不在 set 中或者 key 不存在。

SCARD

获取⼀个 set 的基数（cardinality），即 set 中的元素个数。

语法：

SCARD key

时间复杂度：O(1)

返回值：set 内的元素个数。

SPOP

从 set 中删除并返回⼀个或者多个元素。注意，由于 set 内的元素是⽆序的，所以取出哪个元素实际是未定义⾏为，即可以看作随机的。

语法：

SPOP key [count]

时间复杂度：O(N), n 是 count

返回值：取出的元素。

srandmember

从set中随机获取一个元素,但是不会移除该元素

SMOVE

将⼀个元素从源 set 取出并放⼊⽬标 set 中。

语法：

SMOVE source destination member

时间复杂度：O(1)

返回值：1 表⽰移动成功，0 表⽰失败

SREM

将指定的元素从 set 中删除。

语法：

SREM key member [member ...]

时间复杂度：O(N), N 是要删除的元素个数.

返回值：本次操作删除的元素个数。

集合间操作

交集（inter）、并集（union）、差集（diff）的概念如图 2-25 所⽰。

SINTER

获取给定 set 的交集中的元素。

语法：

SINTER key [key ...]

时间复杂度：O(N * M), N 是最⼩的集合元素个数. M 是最⼤的集合元素个数.

返回值：交集的元素。

SINTERSTORE

获取给定 set 的交集中的元素并保存到⽬标 set 中。

语法：

SINTERSTORE destination key [key ...]

时间复杂度：O(N * M), N 是最⼩的集合元素个数. M 是最⼤的集合元素个数.

返回值：交集的元素个数。

SUNION

获取给定 set 的并集中的元素。

语法：

SUNION key [key ...]

时间复杂度：O(N), N 给定的所有集合的总的元素个数.

返回值：并集的元素。

SUNIONSTORE

获取给定 set 的并集中的元素并保存到⽬标 set 中。

语法：

1 SUNIONSTORE destination key [key ...]

时间复杂度：O(N), N 给定的所有集合的总的元素个数.

返回值：并集的元素个数。

SDIFF

获取给定 set 的差集中的元素。

语法：

SDIFF key [key ...]

时间复杂度：O(N), N 给定的所有集合的总的元素个数.

返回值：差集的元素。

SDIFFSTORE

获取给定 set 的差集中的元素并保存到⽬标 set 中。

语法：

SDIFFSTORE destination key [key ...]

时间复杂度：O(N), N 给定的所有集合的总的元素个数.

返回值：差集的元素个数

命令小结

内部编码

集合类型的内部编码有两种：

•

intset（整数集合）：

当集合中的元素都是整数并且元素的个数⼩于 set-max-intset-entries 配置

（默认 512 个）时，Redis 会选⽤ intset 来作为集合的内部实现，从⽽减少内存的使⽤。

•

hashtable（哈希表）：

当集合类型⽆法满⾜ intset 的条件时，Redis 会使⽤ hashtable 作为集合

的内部实现。

使⽤场景

集合类型⽐较典型的使⽤场景是标签（tag）。例如 A ⽤⼾对娱乐、体育板块⽐较感兴趣，B ⽤⼾

对历史、新闻⽐较感兴趣，这些兴趣点可以被抽象为标签。有了这些数据就可以得到喜欢同⼀个标签的⼈，以及⽤⼾的共同喜好的标签，这些数据对于增强⽤⼾体验和⽤⼾黏度都⾮常有帮助。 例如⼀个电⼦商务⽹站会对不同标签的⽤⼾做不同的产品推荐。

1.使用set来保存用户的标签

2.使用set来计算共同好友,基于集合求交集

3.使用set来计算uv

Zset 有序集合

有序集合相对于字符串、列表、哈希、集合来说会有⼀些陌⽣。它保留了集合不能有重复成员的

特点，但与集合不同的是，有序集合中的每个元素都有⼀个唯⼀的浮点类型的分数（score）与之关联，着使得有序集合中的元素是可以维护有序性的，但这个有序不是⽤下标作为排序依据⽽是⽤这个分数。如图 2-26 所⽰，该有序集合显⽰了三国中的武将的武⼒

有序集合提供了获取指定分数和元素范围查找、计算成员排名等功能，合理地利⽤有序集合，可

以帮助我们在实际开发中解决很多问题。

常见命令

zadd

添加或者更新指定的元素以及关联的分数到 zset 中，分数应该符合 double 类型，+inf/-inf 作为正负

极限也是合法的。

ZADD 的相关选项：

XX：仅仅⽤于更新已经存在的元素，不会添加新元素。

NX：仅⽤于添加新元素，不会更新已经存在的元素。

CH：默认情况下，ZADD 返回的是本次添加的元素个数，但指定这个选项之后，就会还包含本次更新的元素的个数。

INCR：此时命令类似 ZINCRBY 的效果，将元素的分数加上指定的分数。此时只能指定⼀个元素和分数。

ZCARD

获取⼀个 zset 的基数（cardinality），即 zset 中的元素个数。

ZCOUNT

返回分数在 min 和 max 之间的元素个数，默认情况下，min 和 max 都是包含的，可以通过 (,表示开区间

ZRANGE

返回指定区间⾥的元素，分数按照升序。带上 WITHSCORES 可以把分数也返回。

ZREVRANGE

返回指定区间⾥的元素，分数按照降序。带上 WITHSCORES 可以把分数也返回。

备注：这个命令可能在 6.2.0 之后废弃，并且功能合并到 ZRANGE 中。

ZRANGEBYSCORE

返回分数在 min 和 max 之间的元素，默认情况下，min 和 max 都是包含的，可以通过 ( 排除。

备注：这个命令可能在 6.2.0 之后废弃，并且功能合并到 ZRANGE 中。

ZPOPMAX

删除并返回分数最⾼的 count 个元素。

BZPOPMAX

ZPOPMAX 的阻塞版本。

ZPOPMIN

删除并返回分数最低的 count 个元素。

BZPOPMIN

ZPOPMIN 的阻塞版本。

ZRANK

返回指定元素的排名，升序。

ZREVRANK

返回指定元素的排名，降序。

ZSCORE

返回指定元素的分数。

ZREM

删除指定的元素。

ZREMRANGEBYRANK

按照排序，升序删除指定范围的元素，左闭右闭。

ZREMRANGEBYSCORE

按照分数删除指定范围的元素，左闭右闭。

ZINCRBY

为指定的元素的关联分数添加指定的分数值

集合间操作

ZINTERSTORE(交集)

求出给定有序集合中元素的交集并保存进⽬标有序集合中，在合并过程中以元素为单位进⾏合并，元素对应的分数按照不同的聚合⽅式和权重得到新的分数。

时间复杂度：O(N*K)+O(M*log(M)) N 是输⼊的有序集合中, 最⼩的有序集合的元素个数; K 是输⼊了⼏个有序集合; M 是最终结果的有序集合的元素个数.

ZUNIONSTORE并集

求出给定有序集合中元素的并集并保存进⽬标有序集合中，在合并过程中以元素为单位进⾏合并，元素对应的分数按照不同的聚合⽅式和权重得到新的分数。

语法：

ZUNIONSTORE destination numkeys key [key ...] [WEIGHTS weight

[weight ...]] [AGGREGATE <SUM | MIN | MAX>]

时间复杂度：O(N)+O(M*log(M)) N 是输⼊的有序集合总的元素个数; M 是最终结果的有序集合的元素个数.

返回值：⽬标集合中的元素个数

命令⼩结

内部编码

有序集合类型的内部编码有两种：

ziplist（压缩列表）：

当有序集合的元素个数⼩于 zset-max-ziplist-entries 配置（默认 128 个）， 同时每个元素的值都⼩于 zset-max-ziplist-value 配置（默认 64 字节）时，Redis 会⽤ ziplist 来作

为有序集合的内部实现，ziplist 可以有效减少内存的使⽤。

skiplist（跳表）：

当 ziplist 条件不满⾜时，有序集合会使⽤ skiplist 作为内部实现，因为此时ziplist 的操作效率会下降

1）当元素个数较少且每个元素较⼩时，内部编码为 ziplist：

2）当元素个数超过 128 个，内部编码 skiplist：

3）当某个元素⼤于 64 字节时，内部编码 skiplist：

使⽤场景

有序集合⽐较典型的使⽤场景就是排⾏榜系统。例如常⻅的⽹站上的热榜信息，榜单的维度可能

是多⽅⾯的：按照时间、按照阅读量、按照点赞量。本例中我们使⽤点赞数这个维度，维护每天的热榜：