探究 | 谁再说Redis慢，我跟谁急( 二 ) 作为一名服务端工程师

因此获取链表长度时不用再遍历整个链表，直接拿到 len 值就可以了，这个时间复杂度是 O(1) 。
你看，这些特性都降低了 List 使用时的时间开销。
压缩列表
双端链表我们已经熟悉了。不知道你有没有注意到一个问题：如果在一个链表节点中存储一个小数据，比如一个字节。那么对应的就要保存头节点，前后指针等额外的数据。
这样就浪费了空间，同时由于反复申请与释放也容易导致内存碎片化。这样内存的使用效率就太低了。
于是，压缩列表上场了!
文章插图
它是经过特殊编码，专门为了提升内存使用效率设计的。所有的操作都是通过指针与解码出来的偏移量进行的。
并且压缩列表的内存是连续分配的，遍历的速度很快。
字典
Redis 作为 K-V 型数据库，所有的键值都是用字典来存储的。
日常学习中使用的字典你应该不会陌生，想查找某个词通过某个字就可以直接定位到，速度非常快。
这里所说的字典原理上是一样的，通过某个 key 可以直接获取到对应的 value 。
字典又称为哈希表，这点没什么可说的。哈希表的特性大家都很清楚，能够在 O(1) 时间复杂度内取出和插入关联的值。
跳跃表
作为 Redis 中特有的数据结构-跳跃表，其在链表的基础上增加了多级索引来提升查找效率。
文章插图
这是跳跃表的简单原理图，每一层都有一条有序的链表，最底层的链表包含了所有的元素。这样跳跃表就可以支持在 O(logN) 的时间复杂度里查找到对应的节点。
下面这张是跳表真实的存储结构，和其它数据结构一样，都在头节点里记录了相应的信息，减少了一些不必要的系统开销。
文章插图
合理的数据编码
对于每一种数据类型来说，底层的支持可能是多种数据结构，什么时候使用哪种数据结构，这就涉及到了编码转化的问题。
那我们就来看看，不同的数据类型是如何进行编码转化的：

String：存储数字的话，采用 int 类型的编码，如果是非数字的话，采用 raw 编码。
List：字符串长度及元素个数小于一定范围使用 ziplist 编码，任意条件不满足，则转化为 linkedlist 编码。
Hash：hash 对象保存的键值对内的键和值字符串长度小于一定值及键值对。
Set：保存元素为整数及元素个数小于一定范围使用 intset 编码，任意条件不满足，则使用 hashtable 编码。
Zset：zset 对象中保存的元素个数小于及成员长度小于一定值使用 ziplist 编码，任意条件不满足，则使用 skiplist 编码。

合适的线程模型
Redis 快的原因还有一个是因为使用了合适的线程模型：

文章插图
I/O 多路复用模型
I/O ：网络 I/O;多路：多个 TCP 连接;复用：共用一个线程或进程。
生产环境中的使用，通常是多个客户端连接 Redis ，然后各自发送命令至 Redis 服务器，最后服务端处理这些请求返回结果。

文章插图
应对大量的请求， Redis 中使用 I/O 多路复用程序同时监听多个套接字，并将这些事件推送到一个队列里，然后逐个被执行。最终将结果返回给客户端。
避免上下文切换
你一定听说过， Redis 是单线程的。那么单线程的 Redis 为什么会快呢?
因为多线程在执行过程中需要进行 CPU 的上下文切换，这个操作比较耗时。
Redis 又是基于内存实现的，对于内存来说，没有上下文切换效率就是最高的。多次读写都在一个CPU 上，对于内存来说就是最佳方案。
单线程模型
顺便提一下，为什么 Redis 是单线程的。
Redis 中使用了 Reactor 单线程模型，你可能对它并不熟悉。没关系，只需要大概了解一下即可。

文章插图
这张图里，接收到用户的请求后，全部推送到一个队列里，然后交给文件事件分派器，而它是单线程的工作方式。 Redis 又是基于它工作的，所以说 Redis 是单线程的。
Redis 单线程与多线程
Redis是单线程的，这话搁以前，是横着走的，谁都知道的真理。现在不一样， Redis 变了。再说这句话，多少得有质疑的语气来跟你辩驳一番。意志不坚定的，可能就缴械投降，顺着别人走了。