2.Redis常见数据类型(字符串篇）

Redis 提供了 5 种数据结构，理解每种数据结构的特点对于 Redis 开发运维非常重要，同时掌握每种数据结构的常见命令，会在使用 Redis 的时候做到游刃有余。本章内容如下：
• 预备知识：几个全局（generic）命令，数据结构和内部编码，单线程模式机制分析。
• 5 种数据结构的特点、命令使用、应用场景示例。
• 键遍历、数据库管理。

预备知识：

在正式介绍5种数据结构之前，了解一下 Redis 的一些全局命令、数据结构和内部编码、单线程命令处理机制是十分必要的，它们能为后面内容的学习打下一个良好的基础.
主要体现在两个方面：
1）Redis 的命令有上百个，如果纯靠死记硬背比较困难，但是如果理解 Redis 的一些机制，会发现这些命令有很强的通用性。
2）Redis 不是万金油，有些数据结构和命令必须在特定场景下使用，一旦使用不当可能对 Redis本身或者应用本身造成致命伤害。

基本全局命令：

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

语法：

KEYS pattern

命令有效版本：1.0.0之后

时间复杂度：O（N）

返回值：匹配pattern的所有key

示例：

这里的这个多余的是笔者之前插入的。

EXISTS

判断某个key是否存在。

语法：

EXISTS key [key ...]

命令有效版本：1.0.0 之后
时间复杂度：O(1)
返回值：key 存在的个数。
示例：

 DEL

删除指定的key。

语法：

 DEL key [key ...]

命令有效版本：1.0.0 之后
时间复杂度：O(1)

返回值：删除掉的 key 的个数。
示例：

 EXPIRE：

为指定的key添加秒级国企实际（Time To Live TTL）

语法：

EXPIRE key seconds

命令有效版本：1.0.0 之后
时间复杂度：O(1)
返回值：1 表示设置成功。0 表示设置失败。

示例：

这里的-2，可以看后面的结果。

TTL 

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

语法： 

TTL key

命令有效版本：1.0.0 之后
时间复杂度：O(1)
返回值：剩余过期时间。-1 表示没有关联过期时间，-2 表示 key 不存在。
示例：

从这里能看到设置过期时间的返回值。没有关联过期时间，不存在的返回值。

EXPIRE 和TTL命令都有对应的支持毫秒为单位的版本：PEXPIRE和PTTL

关于键的过期机制，可以参考图：

键的过期机制

TYPE

返回key对应的数据类型。

语法

TYPE key

 命令有效版本：1.0.0 之后

时间复杂度：O(1)
返回值： none , string , list , set , zset , hash and stream .。
示例：

 这里只是抛砖引玉，给出几个通用的命令，为五种数据结构的使用做一个热身，后续章节将对键管理做一个更为详细的介绍。

数据结构和内部编码

type 命令实际返回的就是当前键的数据结构类型，它们分别是：string（字符串）、list（列表）、hash（哈希）、set（集合）、zset（有序集合），但这些只是 Redis 对外的数据结构，如图 所示。

Redis的5种数据类型

实际上Redis针对每种数据结构都有自己的底层编码实现，而且是多种实现，这样Redis会在合适的场景选择合适的内部编码，如表所示：

Redis数据结构和内部编码

可以看到每种数据结构都有至少两种以上的内部编码实现，例如list数据结构包含了linkedlist和ziplist两种内部编码。同时有些内部编码，例如ziplist，可以作为多种数据机构的内部实现，可以通过object encoding 命令查询内部编码：

 可以看到 hello 对应值的内部编码是 embstr，键 mylist 对应值的内部编码是 ziplist。（这里跟版本有关）

Redis这样设计有两个好处；
1）可以改进内部编码，而对外的数据结构和命令没有任何影响，这样一旦开发出更优秀的内部编码，无需改动外部数据结构和命令，例如 Redis 3.2 提供了 quicklist，结合了 ziplist 和 linkedlist 两者的优势，为列表类型提供了一种更为优秀的内部编码实现，而对用户来说基本无感知。
2）多种内部编码实现可以在不同场景下发挥各自的优势，例如 ziplist 比较节省内存，但是在列表元素比较多的情况下，性能会下降，这时候 Redis 会根据配置选项将列表类型的内部实现转换为linkedlist，整个过程用户同样无感知。

单线程架构

Redis使用了单线程架构来实现高性能的内存数据库事务，本节先来通过多个客户端命令的调用例子说明Redis单线程命令处理机制，接着分析Redis单线程模型为什么性能如此之高，最终给出为什么理解了单线程模型是使用和运维Redis的关键。

1.引出单线程模型：

现在开启了三个redis-cli客户端同时执行命令。

客户端 1 设置一个字符串键值对：

客户端 2 对 counter 做自增操作：

客户端 3 对 counter 做自增操作：

       我们已经知道从客户端发送命令经历了：发送命令、执行命令、返回结果三个阶段，其中我们重点关注第 2 步。我们所谓的 Redis 是采用单线程模型执行命令的是指：虽然三个客户端看起来是同时要求 Redis 去执行命令的，但微观角度，这些命令还是采用线性方式去执行的，只是原则上命令的执行顺序是不确定的，但一定不会有两条命令被同步执行，如图 所示，可以想象 Redis内部只有一个服务窗口，多个客户端按照它们达到的先后顺序被排队在窗口前，依次接受 Redis 的服务，所以两条 incr 命令无论执行顺序，结果一定是 2，不会发生并发问题，这个就是 Redis 的单线程执行模型。

宏观上同时要求服务的客户端

微观上客户端发送命令的时间有先后次序的。

Redis的单线程模型

2.为什么单线程还能这么快？

       通常来讲，单线程处理能力要比多线程差，例如有 10 000 公斤货物，每辆车的运载能力是每次200 公斤，那么要 50 次才能完成；但是如果有 50 辆车，只要安排合理，只需要依次就可以完成任务。那么为什么 Redis 使用单线程模型会达到每秒万级别的处理能力呢？可以将其归结为三点：

        a. 纯内存访问。Redis 将所有数据放在内存中，内存的响应时长大约为 100 纳秒，这是 Redis 达到每秒万级别访问的重要基础。
        b. 非阻塞 IO。Redis 使用 epoll 作为 I/O 多路复用技术的实现，再加上 Redis 自身的事件处理模型将 epoll 中的连接、读写、关闭都转换为事件，不在网络 I/O 上浪费过多的时间。
        c. 单线程避免了线程切换和竞态产生的消耗。单线程可以简化数据结构和算法的实现，让程序模型更简单；其次多线程避免了在线程竞争同一份共享数据时带来的切换和等待消耗。

        虽然单线程给 Redis 带来很多好处，但还是有一个致命的问题：对于单个命令的执行时间都是有要求的。如果某个命令执行过长，会导致其他命令全部处于等待队列中，迟迟等不到响应，造成客户端的阻塞，对于 Redis 这种高性能的服务来说是非常严重的，所以 Redis 是面向快速执行场景的数据库。

String字符串

        字符串类型是 Redis 最基础的数据类型，关于字符串需要特别注意：

1）首先 Redis 中所有的键的类型都是字符串类型，而且其他几种数据结构也都是在字符串类似基础上构建的，例如列表和集合的元素类型是字符串类型，所以字符串类型能为其他 4 种数据结构的学习奠定基础。

2）其次，如图所示，字符串类型的值实际可以是字符串，包含一般格式的字符串或者类似 JSON、XML 格式的字符串；数字，可以是整型或者浮点型；甚至是二进制流数据，例如图片、音频、视频等。不过一个字符串的最大值不能超过 512 MB。

        由于 Redis 内部存储字符串完全是按照二进制流的形式保存的，所以 Redis 是不处理字符集编码问题的，客户端传入的命令中使用的是什么字符集编码，就存储什么字符集编码。

常见命令

SET 

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

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

命令有效版本：1.0.0 之后
时间复杂度：O(1)
选项：
SET 命令支持多种选项来影响它的行为：
• EX seconds —— 使用秒作为单位设置 key 的过期时间。
• PX milliseconds —— 使用毫秒作为单位设置 key 的过期时间。
• NX —— 只在 key 不存在时才进行设置，即如果 key 之前已经存在，设置不执行。
• XX —— 只在 key 存在时才进行设置，即如果 key 之前不存在，设置不执行。
 注意：由于带选项的 SET 命令可以被 SETNX 、SETEX 、PSETEX 等命令代替，所以之后的版本中，Redis 可能进行合并。
返回值：
• 如果设置成功，返回 OK。
• 如果由于 SET 指定了 NX 或者 XX 但条件不满足，SET 不会执行，并返回 (nil)。
示例：

 GET

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

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 的值。
语法：

MSET key value 1 [key value ...]

命令有效版本：1.0.1 之后
时间复杂度：O(N) N 是 key 数量
返回值：永远是 OK
示例：

多次GET vs 单次GET

         如图所示，使用 mget / mset 由于可以有效地减少了网络时间，所以性能相较更高。假设网络耗时 1 毫秒，命令执行时间耗时 0.1 毫秒，则执行时间如表所示。

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

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

SETNX key value

 命令有效版本：1.0.0 之后
时间复杂度：O(1)
返回值：1 表示设置成功。0 表示没有设置。
示例：

SET、SET NX 和 SET XX 的执行流程如图 2-9 所示。

SET、SET NX、SET XX执行流程

计数命令

INCR

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

INCR key

 命令有效版本：1.0.0 之后
时间复杂度：O(1)
返回值：integer 类型的加完后的数值。
示例：

 INCRBY

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

INCRBY key decrement

 命令有效版本：1.0.0 之后
时间复杂度：O(1)
返回值：integer 类型的加完后的数值。
示例：

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

DECR key

命令有效版本：1.0.0 之后
时间复杂度：O(1)
返回值：integer 类型的减完后的数值。
示例：

DECRBY

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

DECRBY key decrement

命令有效版本：1.0.0 之后
时间复杂度：O(1)
返回值：integer 类型的减完后的数值。
示例：

INCRBYFLOAT

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

INCRBYFLOAT 1 key increment

命令有效版本：2.6.0 之后
时间复杂度：O(1)
返回值：加/减完后的数值。
示例：

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

其他命令

APPEND

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

APPEND KEY VALUE

 命令有效版本：2.0.0 之后
时间复杂度：O(1). 追加的字符串一般长度较短, 可以视为 O(1).
返回值：追加完成之后 string 的长度。
示例：

GETRANGE

返回 key 对应的 string 的子串，由 start 和 end 确定（左闭右闭）。可以使用负数表示倒数。-1 代表倒数第一个字符，-2 代表倒数第二个，其他的与此类似。超过范围的偏移量会根据 string 的长度调整成正确的值。
语法：

GETRANGE 1 key start end

命令有效版本：2.4.0 之后
时间复杂度：O(N). N 为 [start, end] 区间的长度. 由于 string 通常比较短, 可以视为是 O(1)
返回值：string 类型的子串
示例：

 SETRANGE
覆盖字符串的一部分，从指定的偏移开始。
语法：

SETRANGE 1 key offset value

命令有效版本：2.2.0 之后
时间复杂度：O(N), N 为 value 的长度. 由于一般给的 value 比较短, 通常视为 O(1).
返回值：替换后的 string 的长度。
示例：

STRLEN

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

STRLEN key

命令有效版本：2.2.0 之后
时间复杂度：O(1)
返回值：string 的长度。或者当 key 不存在时，返回 0。
示例：

命令小结：

        下表 是字符串类型命令的效果、时间复杂度，开发人员可以参考此表，结合自身业务需求和数据大小选择合适的命令。

字符串类型命令小结

内部编码：

 字符串类型的内部编码有 3 种：
• int：8 个字节的长整型。
• embstr：小于等于 39 个字节的字符串。
• raw：大于 39 个字节的字符串。
Redis 会根据当前值的类型和长度动态决定使用哪种内部编码实现。
整型类型示例如下：

短字符串示例如下：

长字符串示例如下：

典型使用场景

缓存（Cache）功能

下图是比较典型的缓存使用场景，其中 Redis 作为缓冲层，MySQL 作为存储层，绝大部分请求的数据都是从 Redis 中获取。由于 Redis 具有支撑高并发的特性，所以缓存通常能起到加速读写和降低后端压力的作用。
Redis + MySQL 组成的缓存存储架构

        通过增加缓存功能，在理想情况下，每个用户信息，一个小时期间只会有一次 MySQL 查询，极大地提升了查询效率，也降低了 MySQL 的访问数。

        与 MySQL 等关系型数据库不同的是，Redis 没有表、字段这种命名空间，而且也没有对键名有强制要求（除了不能使用一些特殊字符）。但设计合理的键名，有利于防止键冲突和项目的可维护性，比较推荐的方式是使用 "业务名:对象名:唯一标识:属性" 作为键名。例如MySQL 的数据库名为 vs，用户表名为 user_info，那么对应的键可用"vs:user_info:6379"、"vs:user_info:6379:name" 来表示，如果当前 Redis 只会被一个业务使用，可以省略业务名 "vs:"。如果键名过程，则可以使用团队内部都认同的缩写替代，例如"user:6379:friends:messages:5217" 可被"u:6379:fr:m:5217" 代替。毕竟键名过长，还是会导致 Redis 的性能明显下降的。

计数（Counter）功能
        许多应用都会使用 Redis 作为计数的基础工具，它可以实现快速计数、查询缓存的功能，同时数据可以异步处理或者落地到其他数据源。如图 2-11 所示，例如视频网站的视频播放次数可以使用Redis 来完成：用户每播放一次视频，相应的视频播放数就会自增 1。
 记录视频播放次数

        实际中要开发一个成熟、稳定的真实计数系统，要面临的挑战远不止如此简单：防作弊、按照不同维度计数、避免单点问题、数据持久化到底层数据源等。

共享会话（Session）
        如图 所示，一个分布式 Web 服务将用户的 Session 信息（例如用户登录信息）保存在各自的服务器中，但这样会造成一个问题：出于负载均衡的考虑，分布式服务会将用户的访问请求均衡到不同的服务器上，并且通常无法保证用户每次请求都会被均衡到同一台服务器上，这样当用户刷新一次访问是可能会发现需要重新登录，这个问题是用户无法容忍的。

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

Redis 集中管理 Session

手机验证码
        很多应用出于安全考虑，会在每次进行登录时，让用户输入手机号并且配合给手机发送验证码，然后让用户再次输入收到的验证码并进行验证，从而确定是否是用户本人。为了短信接口不会频繁访问，会限制用户每分钟获取验证码的频率，例如一分钟不能超过 5 次，如图 所示。

        以上介绍了使用 Redis 的字符串数据类型可以使用的几个场景，但其适用场景远不止于此，开发人员可以结合字符串类型的特点以及提供的命令，充分发挥自己的想象力，在自己的业务中去找到合适的场景去使用 Redis 的字符串类型。