<b>2.1 预备</b>
在正式介绍5种数据结构之前，了解一下redis的一些全局命令、数据结构和内部编码、单线程命令处理机制是十分有必要的，它们能为后面内容的学习打下一个好的基础，主要体现在两个方面：第一、redis的命令有上百个，如果纯靠死记硬背比较困难，但是如果理解redis的一些机制，会发现这些命令有很强的通用性。第二、redis不是万金油，有些数据结构和命令必须在特定场景下使用，一旦使用不当可能对redis本身或者应用本身造成致命伤害。
<b>2.1.1 全局命令</b>
redis有5种数据结构，它们是键值对中的值，对于键来说有一些通用的命令。
1.?查看所有键
keys *
下面插入了3对字符串类型的键值对：
127.0.0.1:6379> set hello world
ok
127.0.0.1:6379> set java jedis
127.0.0.1:6379> set python redis-py
keys *命令会将所有的键输出：
127.0.0.1:6379> keys *
1) "python"
2) "java"
3) "hello"
2.?键总数
dbsize
下面插入一个列表类型的键值对（值是多个元素组成）：
127.0.0.1:6379> rpush mylist a b c d e f
g
(integer) 7
dbsize命令会返回当前数据库中键的总数。例如当前数据库有4个键，分别是hello、java、python、mylist，所以dbsize的结果是4：
127.0.0.1:6379> dbsize
(integer) 4
dbsize命令在计算键总数时不会遍历所有键，而是直接获取redis内置的键总数变量，所以dbsize命令的时间复杂度是o(1)。而keys命令会遍历所有键，所以它的时间复杂度是o(n)，当redis保存了大量键时，线上环境禁止使用。
3.?检查键是否存在
exists key
如果键存在则返回1，不存在则返回0：
127.0.0.1:6379> exists java
(integer) 1
127.0.0.1:6379> exists not_exist_key
(integer) 0
4.?删除键
del key [key ...]
del是一个通用命令，无论值是什么数据结构类型，del命令都可以将其删除，例如下面将字符串类型的键java和列表类型的键mylist分别删除：
127.0.0.1:6379> del java
127.0.0.1:6379> del mylist
127.0.0.1:6379> exists mylist
返回结果为成功删除键的个数，假设删除一个不存在的键，就会返回0：
127.0.0.1:6379> del not_exist_key
同时del命令可以支持删除多个键：
127.0.0.1:6379> set a 1
127.0.0.1:6379> set b 2
127.0.0.1:6379> set c 3
127.0.0.1:6379> del a b c
(integer) 3
5.?键过期
expire key seconds
redis支持对键添加过期时间，当超过过期时间后，会自动删除键，例如为键hello设置了10秒过期时间：
127.0.0.1:6379> expire hello 10
ttl命令会返回键的剩余过期时间，它有3种返回值：
大于等于0的整数：键剩余的过期时间。
-1：键没设置过期时间。
-2：键不存在
可以通过ttl命令观察键hello的剩余过期时间：
#还剩7秒
127.0.0.1:6379> ttl hello
...
#还剩1秒
#返回结果为-2，说明键hello已经被删除
(integer) -2
127.0.0.1:6379> get hello
(nil)
有关键过期更为详细的使用以及原理会在2.7节介绍。
6.?键的数据结构类型
type key
例如键hello是字符串类型，返回结果为string。键mylist是列表类型，返回结果为list：
127.0.0.1:6379> set a b
127.0.0.1:6379> type a
string
127.0.0.1:6379> type mylist
list
如果键不存在，则返回none：
127.0.0.1:6379> type not_exsit_key
none
本小节只是抛砖引玉，给出几个通用的命令，为5种数据结构的使用做一个热身，2.7节将对键管理做一个更为详细的介绍。
<b>2.1.2 数据结构和内部编码</b>
type命令实际返回的就是当前键的数据结构类型，它们分别是：string（字符串）、hash（哈希）、list（列表）、set（集合）、zset（有序集合），但这些只是redis对外的数据结构，如图2-1所示。
实际上每种数据结构都有自己底层的内部编码实现，而且是多种实现，这样redis会在合适的场景选择合适的内部编码，如图2-2所示。
可以看到每种数据结构都有两种以上的内部编码实现，例如list数据结构包含了linkedlist和ziplist两种内部编码。同时有些内部编码，例如ziplist，可以作为多种外部数据结构的内部实现，可以通过object encoding命令查询内部编码：
127.0.0.1:6379> object encoding hello
"embstr"
127.0.0.1:6379> object encoding mylist
"ziplist"
图2-1 redis的5种数据结构 图2-2 redis数据结构和内部编码
可以看到键hello对应值的内部编码是embstr，键mylist对应值的内部编码是ziplist。
redis这样设计有两个好处：第一，可以改进内部编码，而对外的数据结构和命令没有影响，这样一旦开发出更优秀的内部编码，无需改动外部数据结构和命令，例如redis 3.2提供了quicklist，结合了ziplist和linkedlist两者的优势，为列表类型提供了一种更为优秀的内部编码实现，而对外部用户来说基本感知不到。第二，多种内部编码实现可以在不同场景下发挥各自的优势，例如ziplist比较节省内存，但是在列表元素比较多的情况下，性能会有所下降，这时候redis会根据配置选项将列表类型的内部实现转换为linkedlist。
<b>2.1.3 单线程架构</b>
redis使用了单线程架构和i/o多路复用模型来实现高性能的内存数据库服务，本节首先通过多个客户端命令调用的例子说明redis单线程命令处理机制，接着分析redis单线程模型为什么性能如此之高，最终给出为什么理解单线程模型是使用和运维redis的关键。
1.?引出单线程模型
现在开启了三个redis-cli客户端同时执行命令。
客户端1设置一个字符串键值对：
客户端2对counter做自增操作：
127.0.0.1:6379> incr counter
客户端3对counter做自增操作：
redis客户端与服务端的模型可以简化成图2-3，每次客户端调用都经历了发送命令、执行命令、返回结果三个过程。
其中第2步是重点要讨论的，因为redis是单线程来处理命令的，所以一条命令从客户端达到服务端不会立刻被执行，所有命令都会进入一个队列中，然后逐个被执行。所以上面3个客户端命令的执行顺序是不确定的（如图2-4所示），但是可以确定不会有两条命令被同时执行（如图2-5所示），所以两条incr命令无论怎么执行最终结果都是2，不会产生并发问题，这就是redis单线程的基本模型。但是像发送命令、返回结果、命令排队肯定不像描述的这么简单，redis使用了i/o多路复用技术来解决i/o
的问题，下一节将进行介绍。
2.?为什么单线程还能这么快
通常来讲，单线程处理能力要比多线程差，例如有10?000斤货物，每辆车的运载能力是每次200斤，那么要50次才能完成，但是如果有50辆车，只要安排合理，只需要一次就可以完成任务。那么为什么redis使用单线程模型会达到每秒万级别的处理能力呢？可以将其归结为三点：
第一，纯内存访问，redis将所有数据放在内存中，内存的响应时长大约为100纳秒，这是redis达到每秒万级别访问的重要基础。
第二，非阻塞i/o，redis使用epoll作为i/o多路复用技术的实现，再加上redis自身的事件处理模型将epoll中的连接、读写、关闭都转换为事件，不在网络i/o上浪费过多的时间，如图2-6所示。
第三，单线程避免了线程切换和竞态产生的消耗。
既然采用单线程就能达到如此高的性能，那么也不失为一种不错的选择，因为单线程能带来几个好处：第一，单线程可以简化数据结构和算法的实现。如果对高级编程语言熟悉的读者应该了解并发数据结构实现不但困难而且开发测试比较麻烦。第二，单线程避免了线程切换和竞态产生的消耗，对于服务端开发来说，锁和线程切换通常是性能杀手。
但是单线程会有一个问题：对于每个命令的执行时间是有要求的。如果某个命令执行过长，会造成其他命令的阻塞，对于redis这种高性能的服务来说是致命的，所以redis是面向快速执行场景的数据库。
单线程机制很容易被初学者忽视，但笔者认为redis单线程机制是开发和运维人员使用和理解redis的核心之一，随着后面的学习，相信读者会逐步理解。
![Java String.format方法的简单使用[图]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)