【Redis】Redis 预备知识

1. 基本全局命令

KEYS

EXISTS

DEL

EXPIRE

TTL

TYPE

2. 数据结构和内部编码

3. 单线程架构

Redis 提供了5种数据结构，理解每种数据结构的特点对于 Redis 开发运维非常重要，同时掌握每种数据结构的常见命令，会在使用 Redis 的时候做到游刃有余。本章内容如下:

预备知识:几个全局(generic)命令，数据结构和内部编码，单线程式机制分析。
5 种数据结构的特点、命令使用、应用场景示例。
键遍历、数据库管理。

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

1. 基本全局命令

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

KEYS

返回所有满足样式 (pattern) 的 key。支持如下统配样式。

语法

KEYS pattern

时间复杂度:0(N)

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

示例:

127.0.0.1:6379> keys *name*
1) "lastname"
2) "firstname"
127.0.0.1:6379> keys a??
1) "age"
127.0.0.1:6379> keys *
1) "lastname"
2) "age"
3) "firstname"

EXISTS

判断某个 key 是否存在。

语法:

EXISTS key [key ...]

返回值:key存在的个数。

时间复杂度:0(1)

示例:

127.0.0.1:6379> set key1 "hello"
OK
127.0.0.1:6379> exists key1
(integer) 1
127.0.0.1:6379> exists nosuchkey
(integer) 0
127.0.0.1:6379> set key2 "world"
OK
127.0.0.1:6379> exists key1 key2 nosuchkey
(integer) 2

DEL

删除指定的 key。

语法:

DEL key [key ...]

返回值:删除掉的 key 的个数。

时间复杂度:0(1)

示例:

127.0.0.1:6379> set key1 "hello"
OK
127.0.0.1:6379> set key2 "world"
OK
127.0.0.1:6379> del key1 key2 key3
(integer) 2

EXPIRE

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

语法:

EXPIRE key seconds

时间复杂度:0O(1)

返回值:1表示设置成功。0表示设置失败。

示例:

127.0.0.1:6379> set key "hello"
OK
127.0.0.1:6379> expire key 10
(integer) 1
127.0.0.1:6379> ttl key
(integer) 8

TTL

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

语法:

TTL key

时间复杂度:0(1)

返回值:剩余过期时间。-1表示没有关联过期时间，-2 表示 key不存在。

示例:

127.0.0.1:6379> flushall
OK
127.0.0.1:6379> set key "hello"
OK
127.0.0.1:6379> expire key 10
(integer) 1
127.0.0.1:6379> ttl key
(integer) 9
127.0.0.1:6379> ttl nokey
(integer) -2

关于键过期机制，可以参考下图所示。

键的过期机制

Redis 的 key 的过期删除策略是怎样的?

惰性过期

只有当访问一个key时，才会判断该key是否已过期，过期则清除。该策略可以最大化地节省CPU资源，却对内存非常不友好。极端情况可能出现大量的过期key没有再次被访问，从而不会被清除，占用大量内存。

定期过期

每隔一定的时间，会扫描一定数量的数据库的expires字典中一定数量的key，并清除其中已过期的key。该策略是前两者的一个折中方案。通过调整定时扫描的时间间隔和每次扫描的限定耗时，可以在不同情况下使得CPU和内存资源达到最优的平衡效果。
expires字典会保存所有设置了过期时间的key的过期时间数据，其中，key是指向键空间中的某个键的指针，value是该键的毫秒精度的UNIX时间戳表示的过期时间。键空间是指该Redis集群中保存的所有键。

Redis 中同时使用了惰性过期和定期过期两种过期策略:

每隔 100ms 就随机抽取一定数量的key来检查和删除的。
在获取某个key的时候，redis 会检查一下，这个key如果设置了过期时间并且已经过期了，此时就会删除。

TYPE

返回 key 对应的数据类型。

语法:

TYPE key

时间复杂度:0(1)

返回值: none，string，list, set，zset，hash，stream

示例:

127.0.0.1:6379> set key1 "value"
OK
127.0.0.1:6379> lpush key2 value
(integer) 1
127.0.0.1:6379> sadd key3 value
(integer) 1
127.0.0.1:6379> type key1
string
127.0.0.1:6379> type key2
list
127.0.0.1:6379> type key3
set

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

2. 数据结构和内部编码

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

Redis的5种数据类型

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

Redis 数据结构和内部编码

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

127.0.0.1:6379> set hello world
OK
127.0.0.1:6379> lpush mylist a b c
(integer) 3
127.0.0.1:6379> object encoding hello
"embstr"
127.0.0.1:6379> object encoding mylist
"quicklist"

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

Redis 这样设计有两个好处:

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

3. 单线程架构

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

引出单线程模型

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

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

127.0.0.1:6379> set hello world

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

127.0.0.1:6379> incr counter

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

127.0.0.1:6379> incr counter

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