【Redis—基础】概览与基本数据结构应用

概览

Redis是一种基于键值对（key-value）的NoSQL数据库，它的值可以是由string（字符串）、hash（哈希）、list（列表）、set（集合）、zset（有序集合）、Bitmaps（位图）、HyperLogLog、GEO（地理信息定位）等多种数据结构和算法组成，因此Redis可以满足很多的应用场景，而且因为Redis会将所有数据都存放在内存中，所以它的读写性能非常惊人。

不仅如此，Redis还可以将内存的数据利用快照和日志的形式保存到硬盘上，这样在发生类似断电或者机器故障的时候，内存中的数据不会“丢失”。除了上述功能以外，Redis还提供了键过期、发布订阅、事务、流水线、Lua脚本等附加功能。

单线程模型

Redis使用了单线程架构和I/O多路复用模型来实现高性能的内存数据库服务。每次Redis的客户端调用都经历了发送命令、执行命令、返回结果三个过程。

因为Redis是单线程来处理命令的，所以一条命令从客户端达到服务端不会立刻被执行，所有命令都会进入一个队列中，然后逐个被执行。所以客户端命令的执行顺序是不确定的，但是可以确定不会有两条命令被同时执行，所以两条incr命令无论怎么执行最终结果都是2，不会产生并发问题，这就是Redis单线程的基本模型。但是像发送命令、返回结果、命令排队肯定不像描述的这么简单，Redis使用了I/O多路复用技术来解决I/O的问题。

为什么单线程还能这么快

通常来讲，单线程处理能力要比多线程差，那么为什么Redis使用单线程模型会达到每秒万级别的处理能力呢？可以将其归结为三点：

第一，纯内存访问，Redis将所有数据放在内存中，内存的响应时长大约为100纳秒，这是Redis达到每秒万级别访问的重要基础。

第二，非阻塞I/O，Redis使用epoll作为I/O多路复用技术的实现，再加上Redis自身的事件处理模型将epoll中的连接、读写、关闭都转换为事件，不在网络I/O上浪费过多的时间。

第三，单线程避免了线程切换和竞态产生的消耗。

既然采用单线程就能达到如此高的性能，那么也不失为一种不错的选择，因为单线程能带来几个好处：第一，单线程可以简化数据结构和算法的实现。如果对高级编程语言熟悉的读者应该了解并发数据结构实现不但困难而且开发测试比较麻烦。第二，单线程避免了线程切换和锁产生的消耗。

但是单线程会有一个问题：对于每个命令的执行时间是有要求的。如果某个命令执行过长，会造成其他命令的阻塞，对于Redis这种高性能的服务来说是致命的，所以Redis是面向快速执行场景的数据库。

全局命令

对于Redis来说，有一些通用并且使用频率很高的命令。

键管理

有关键管理的命令在Redis中很常用，其中最重要的有keys、dbsize、exists、del、expire、type、rename、randomkey等。其中有几点需要注意：

• 使用rename命令时，由于重命名键期间会执行del命令删除旧的键，如果键对应的值比较大，会存在阻塞Redis的可能性。
• 给键设置过期时间时，如果过期时间为负值，键会立即被删除。
• 对于字符串类型键，执行set命令会去掉过期时间。

Redis发展历程中提供了move、dump+restore、migrate三组迁移键的方法，migrate命令就是将dump、restore、del三个命令进行组合，从而简化了操作流程。migrate命令具有原子性，而且从Redis3.0.6版本以后已经支持迁移多个键的功能，有效地提高了迁移效率。

下表总结了move、dump+restore、migrate三种迁移方式的异同点，建议使用migrate命令进行键值迁移。

遍历键

Redis提供了两个命令遍历所有的键，分别是keys和scan。

keys命令是全量遍历键，可以使用glob风格的通配符来做过滤和查找。由于Redis是单线程架构，如果一个实例中包含了大量的键，执行keys命令很可能会造成阻塞，所以一般不建议在生产环境使用。

和keys命令执行时会遍历所有键不同，scan采用渐进式遍历的方式来解决keys命令可能带来的阻塞问题，每次scan命令的时间复杂度是O（1），但是要真正实现keys的功能，需要执行多次scan。

每次执行scan，可以想象成只扫描一个字典中的一部分键，直到将字典中的所有键遍历完毕。scan的使用方法如下：scan cursor [match pattern] [count number]

• cursor是必需参数，实际上cursor是一个游标，第一次遍历从0开始，每次scan遍历完都会返回当前游标的值，直到游标值为0，表示遍历结束。
• match pattern是可选参数，它的作用的是做模式的匹配，这点和keys的模式匹配很像。·count number是可选参数，它的作用是表明每次要遍历的键个数，默认值是10，此参数可以适当增大。

同时Redis还提供了hscan、sscan、zscan渐进式地遍历hash、set、zset。

基本数据结构和内部编码

type命令返回当前键的数据结构类型，它们分别是：string（字符串）、hash（哈希）、list（列表）、set（集合）、zset（有序集合），但这些只是Redis对外的数据结构。实际上每种数据结构都有自己底层的内部编码实现，而且是多种实现，这样Redis会在合适的场景选择合适的内部编码。

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

Redis这样设计有两个好处：

第一，可以改进内部编码，而对外的数据结构和命令没有影响，这样一旦开发出更优秀的内部编码，无需改动外部数据结构和命令，例如Redis3.2提供了quicklist，结合了ziplist和linkedlist两者的优势，为列表类型提供了一种更为优秀的内部编码实现，而对外部用户来说基本感知不到。

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

字符串

常用命令

内部编码

字符串类型的内部编码有3种：

• int：8个字节的长整型。
• embstr：小于等于44个字节的字符串。
• raw：大于44个字节的字符串。

Redis会根据当前值的类型和长度决定使用哪种内部编码实现。

使用场景

• 缓存
• 计数
• 共享session、分布式锁
• 限速

哈希

常用命令

内部编码

哈希类型的内部编码有两种：

• ziplist（压缩列表）：当哈希类型元素个数小于hash-max-ziplist-entries配置（默认512个）、同时所有值都小于hash-max-ziplist-value配置（默认64字节）时，Redis会使用ziplist作为哈希的内部实现，ziplist使用更加紧凑的结构实现多个元素的连续存储，所以在节省内存方面比hashtable更加优秀。
• hashtable（哈希表）：当哈希类型无法满足ziplist的条件时，Redis会使用hashtable作为哈希的内部实现，因为此时ziplist的读写效率会下降，而hashtable的读写时间复杂度为O（1）。

使用场景

• 用户信息
• 文章详情

列表

常用命令

内部编码

3.2版本之前列表类型的内部编码有两种：

• ziplist（压缩列表）：当列表的元素个数小于list-max-ziplist-entries配置（默认512个），同时列表中每个元素的值都小于list-max-ziplist-value配置时（默认64字节），Redis会选用ziplist来作为列表的内部实现来减少内存的使用。
• linkedlist（链表）：当列表类型无法满足ziplist的条件时，Redis会使用linkedlist作为列表的内部实现。

3.2版本之后列表的内部编码均改为quicklist。

使用场景

• 消息队列
• 文章列表

集合

常用命令

内部编码

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

• intset（整数集合）：当集合中的元素都是整数且元素个数小于set-max-intset-entries配置（默认512个）时，Redis会选用intset来作为集合的内部实现，从而减少内存的使用。
• hashtable（哈希表）：当集合类型无法满足intset的条件时，Redis会使用hashtable作为集合的内部实现。

使用场景

• 标签
• 生成随机数、抽奖
• 社交需求

有序集合

常用命令

zpopmax/bzpopmax、zpopmin/bzpopmin(5.0)

内部编码

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

• ziplist（压缩列表）：当有序集合的元素个数小于zset-max-ziplist-entries配置（默认128个），同时每个元素的值都小于zset-max-ziplist-value配置（默认64字节）时，Redis会用ziplist来作为有序集合的内部实现，ziplist可以有效减少内存的使用。
• skiplist（跳跃表）：当ziplist条件不满足时，有序集合会使用skiplist作为内部实现，因为此时ziplist的读写效率会下降。

使用场景

• 排行榜