关于redis:Redis-核心篇唯快不破的秘密

天下文治，无坚不摧，唯快不破！

学习一个技术，通常只接触了零散的技术点，没有在脑海里建设一个残缺的常识框架和架构体系，没有零碎观。这样会很吃力，而且会呈现一看如同本人会，过后就遗记，一脸懵逼。

跟着「码哥字节」一起吃透 Redis，深层次的把握 Redis 外围原理以及实战技巧。一起搭建一套残缺的常识框架，学会全局观去整顿整个常识体系。

零碎观其实是至关重要的，从某种程度上说，在解决问题时，领有了零碎观，就意味着你能有根据、有章法地定位和解决问题。

Redis 全景图

全景图能够围绕两个纬度开展，别离是：

利用维度：缓存应用、集群使用、数据结构的奇妙应用

零碎维度：能够归类为三高

1. 高性能：线程模型、网络 IO 模型、数据结构、长久化机制；
2. 高可用：主从复制、哨兵集群、Cluster 分片集群；
3. 高拓展：负载平衡

Redis 系列篇章 围绕如下思维导图开展，这次从 《Redis 唯快不破的机密》一起摸索 Redis 的外围知识点。

唯快不破的机密

65 哥前段时间去面试 996 大厂，被问到「Redis 为什么快？」

65 哥：额，因为它是基于内存实现和单线程模型

面试官：还有呢？

65 哥：没了呀。

很多人仅仅只是晓得基于内存实现，其余外围的起因模凌两可。今日跟着「码哥字节」一起摸索真正快的起因，做一个唯快不破的真男人！

Redis 为了高性能，从各方各面都进行了优化，下次小伙伴们面试的时候，面试官问 Redis 性能为什么如此高，可不能傻傻的只说单线程和内存存储了。

依据官网数据，Redis 的 QPS 能够达到约 100000（每秒申请数），有趣味的能够参考官网的基准程序测试《How fast is Redis？》，地址：https://redis.io/topics/benchmarks

横轴是连接数，纵轴是 QPS。此时，这张图反映了一个数量级，心愿大家在面试的时候能够正确的形容进去，不要问你的时候，你答复的数量级相差甚远！

齐全基于内存实现

65 哥：这个我晓得，Redis 是基于内存的数据库，跟磁盘数据库相比，齐全吊打磁盘的速度，就像段誉的凌波微步。对于磁盘数据库来说，首先要将数据通过 IO 操作读取到内存里。

没错，不管读写操作都是在内存上实现的，咱们别离比照下内存操作与磁盘操作的差别。

磁盘调用栈图

内存操作

内存间接由 CPU 管制，也就是 CPU 外部集成的内存控制器，所以说内存是间接与 CPU 对接，享受与 CPU 通信的最优带宽。

Redis 将数据存储在内存中，读写操作不会因为磁盘的 IO 速度限制，所以速度飞个别的感觉！

最初以一张图量化零碎的各种延时工夫（局部数据援用 Brendan Gregg）

高效的数据结构

65 哥：学习 MySQL 的时候我晓得为了进步检索速度应用了 B+ Tree 数据结构，所以 Redis 速度快应该也跟数据结构无关。

答复正确，这里所说的数据结构并不是 Redis 提供给咱们应用的 5 种数据类型：String、List、Hash、Set、SortedSet。

在 Redis 中，罕用的 5 种数据类型和利用场景如下：

• String： 缓存、计数器、分布式锁等。
• List： 链表、队列、微博关注人时间轴列表等。
• Hash： 用户信息、Hash 表等。
• Set： 去重、赞、踩、独特好友等。
• Zset： 访问量排行榜、点击量排行榜等。

下面的应该叫做 Redis 反对的数据类型，也就是数据的保留模式。「码哥字节」要说的是针对这 5 种数据类型，底层都使用了哪些高效的数据结构来反对。

65 哥：为啥搞这么多数据结构呢？

当然是为了谋求速度，不同数据类型应用不同的数据结构速度才得以晋升。每种数据类型都有一种或者多种数据结构来撑持，底层数据结构有 6 种。

Redis hash 字典

Redis 整体就是一个 哈希表来保留所有的键值对，无论数据类型是 5 种的任意一种。哈希表，实质就是一个数组，每个元素被叫做哈希桶，不论什么数据类型，每个桶外面的 entry 保留着理论具体值的指针。

整个数据库就是一个 全局哈希表，而哈希表的工夫复杂度是 O(1)，只须要计算每个键的哈希值，便晓得对应的哈希桶地位，定位桶外面的 entry 找到对应数据，这个也是 Redis 快的起因之一。

那 Hash 抵触怎么办？

当写入 Redis 的数据越来越多的时候，哈希抵触不可避免，会呈现不同的 key 计算出一样的哈希值。

Redis 通过 链式哈希 解决抵触：也就是同一个 桶外面的元素应用链表保留。然而当链表过长就会导致查找性能变差可能，所以 Redis 为了谋求快，应用了两个全局哈希表。用于 rehash 操作，减少现有的哈希桶数量，缩小哈希抵触。

开始默认应用 hash 表 1 保留键值对数据，哈希表 2 此刻没有调配空间。当数据越来多触发 rehash 操作，则执行以下操作：

1. 给 hash 表 2 调配更大的空间；
2. 将 hash 表 1 的数据从新映射拷贝到 hash 表 2 中；
3. 开释 hash 表 1 的空间。

值得注意的是，将 hash 表 1 的数据从新映射到 hash 表 2 的过程中并不是一次性的，这样会造成 Redis 阻塞，无奈提供服务。

而是采纳了 渐进式 rehash，每次解决客户端申请的时候，先从 hash 表 1 中第一个索引开始，将这个地位的 所有数据拷贝到 hash 表 2 中，就这样将 rehash 扩散到屡次申请过程中，防止耗时阻塞。

SDS 简略动静字符

65 哥：Redis 是用 C 语言实现的，为啥还从新搞一个 SDS 动静字符串呢？

字符串构造应用最宽泛，通常咱们用于缓存登陆后的用户信息，key = userId，value = 用户信息 JSON 序列化成字符串。

C 语言中字符串的获取「MageByte」的长度，要从头开始遍历，直到「0」为止，Redis 作为唯快不破的男人是不能忍耐的。

C 语言字符串构造与 SDS 字符串构造比照图如下所示：

SDS 与 C 字符串区别

O(1) 工夫复杂度获取字符串长度

C 语言字符串布吉路长度信息，须要遍历整个字符串工夫复杂度为 O(n)，C 字符串遍历时遇到 ‘0’ 时完结。

SDS 中 len 保留这字符串的长度，O(1) 工夫复杂度。

空间预调配

SDS 被批改后，程序不仅会为 SDS 调配所须要的必须空间，还会调配额定的未应用空间。

调配规定如下：如果对 SDS 批改后，len 的长度小于 1M，那么程序将调配和 len 雷同长度的未应用空间。举个例子，如果 len=10，重新分配后，buf 的理论长度会变为 10(已应用空间)+10(额定空间)+1(空字符)=21。如果对 SDS 批改后 len 长度大于 1M，那么程序将调配 1M 的未应用空间。

惰性空间开释

当对 SDS 进行缩短操作时，程序并不会回收多余的内存空间，而是应用 free 字段将这些字节数量记录下来不开释，前面如果须要 append 操作，则间接应用 free 中未应用的空间，缩小了内存的调配。

二进制平安

在 Redis 中不仅能够存储 String 类型的数据，也可能存储一些二进制数据。

二进制数据并不是规定的字符串格局，其中会蕴含一些非凡的字符如 ‘0’，在 C 中遇到 ‘0’ 则示意字符串的完结，但在 SDS 中，标记字符串完结的是 len 属性。

zipList 压缩列表

压缩列表是 List、hash、sorted Set 三种数据类型底层实现之一。

当一个列表只有大量数据的时候，并且每个列表项要么就是小整数值，要么就是长度比拟短的字符串，那么 Redis 就会应用压缩列表来做列表键的底层实现。

ziplist 是由一系列非凡编码的间断内存块组成的程序型的数据结构，ziplist 中能够蕴含多个 entry 节点，每个节点能够寄存整数或者字符串。

ziplist 在表头有三个字段 zlbytes、zltail 和 zllen，别离示意列表占用字节数、列表尾的偏移量和列表中的 entry 个数；压缩列表在表尾还有一个 zlend，示意列表完结。

 struct ziplist<T> {
  int32 zlbytes; // 整个压缩列表占用字节数
  int32 zltail_offset; // 最初一个元素间隔压缩列表起始地位的偏移量，用于疾速定位到最初一个节点
  int16 zllength; // 元素个数
  T[] entries; // 元素内容列表，挨个挨个紧凑存储
  int8 zlend; // 标记压缩列表的完结，值恒为 0xFF
 }

如果咱们要查找定位第一个元素和最初一个元素，能够通过表头三个字段的长度间接定位，复杂度是 O(1)。而查找其余元素时，就没有这么高效了，只能一一查找，此时的复杂度就是 O(N)

双端列表

Redis List 数据类型通常被用于队列、微博关注人时间轴列表等场景。不论是先进先出的队列，还是先进后出的栈，双端列表都很好的反对这些个性。

Redis 的链表实现的个性能够总结如下：

• 双端：链表节点带有 prev 和 next 指针，获取某个节点的前置节点和后置节点的复杂度都是 O（1）。
• 无环：表头节点的 prev 指针和表尾节点的 next 指针都指向 NULL，对链表的拜访以 NULL 为起点。
• 带表头指针和表尾指针：通过 list 构造的 head 指针和 tail 指针，程序获取链表的表头节点和表尾节点的复杂度为 O（1）。
• 带链表长度计数器：程序应用 list 构造的 len 属性来对 list 持有的链表节点进行计数，程序获取链表中节点数量的复杂度为 O（1）。
• 多态：链表节点应用 void* 指针来保留节点值，并且能够通过 list 构造的 dup、free、match 三个属性为节点值设置类型特定函数，所以链表能够用于保留各种不同类型的值。

后续版本对列表数据结构进行了革新，应用 quicklist 代替了 ziplist 和 linkedlist。

quicklist 是 ziplist 和 linkedlist 的混合体，它将 linkedlist 按段切分，每一段应用 ziplist 来紧凑存储，多个 ziplist 之间应用双向指针串接起来。

这也是为何 Redis 快的起因，不放过任何一个能够晋升性能的细节。

skipList 跳跃表

sorted set 类型的排序功能便是通过「跳跃列表」数据结构来实现。

跳跃表（skiplist）是一种有序数据结构，它通过在每个节点中维持多个指向其余节点的指针，从而达到快速访问节点的目标。

跳跃表反对均匀 O（logN）、最坏 O（N）复杂度的节点查找，还能够通过程序性操作来批量解决节点。

跳表在链表的根底上，减少了多层级索引，通过索引地位的几个跳转，实现数据的疾速定位，如下图所示：

当须要查找 40 这个元素须要经验 三次查找。

整数数组（intset）

当一个汇合只蕴含整数值元素，并且这个汇合的元素数量不多时，Redis 就会应用整数汇合作为汇合键的底层实现。构造如下：

 typedef struct intset{
  // 编码方式
  uint32_t encoding;
  // 汇合蕴含的元素数量
  uint32_t length;
  // 保留元素的数组
  int8_t contents[];
 }intset;

contents 数组是整数汇合的底层实现：整数汇合的每个元素都是 contents 数组的一个数组项（item），各个项在数组中按值的大小从小到大有序地排列，并且数组中不蕴含任何反复项。length 属性记录了整数汇合蕴含的元素数量，也即是 contents 数组的长度。

正当的数据编码

Redis 应用对象（redisObject）来示意数据库中的键值，当咱们在 Redis 中创立一个键值对时，至多创立两个对象，一个对象是用做键值对的键对象，另一个是键值对的值对象。

例如咱们执行 SET MSG XXX 时，键值对的键是一个蕴含了字符串“MSG“的对象，键值对的值对象是蕴含字符串 ”XXX” 的对象。

redisObject

 typedef struct redisObject{
  // 类型
  unsigned type:4;
  // 编码
  unsigned encoding:4;
  // 指向底层数据结构的指针
  void *ptr;
  //…
  }robj;

其中 type 字段记录了对象的类型，蕴含字符串对象、列表对象、哈希对象、汇合对象、有序汇合对象。

对于每一种数据类型来说，底层的反对可能是多种数据结构，什么时候应用哪种数据结构，这就波及到了编码转化的问题。

那咱们就来看看，不同的数据类型是如何进行编码转化的：

String：存储数字的话，采纳 int 类型的编码，如果是非数字的话，采纳 raw 编码；

List：List 对象的编码能够是 ziplist 或 linkedlist，字符串长度 < 64 字节且元素个数 < 512 应用 ziplist 编码，否则转化为 linkedlist 编码；

留神：这两个条件是能够批改的，在 redis.conf 中：

 list-max-ziplist-entries 512
 list-max-ziplist-value 64

Hash：Hash 对象的编码能够是 ziplist 或 hashtable。

当 Hash 对象同时满足以下两个条件时，Hash 对象采纳 ziplist 编码：

• Hash 对象保留的所有键值对的键和值的字符串长度均小于 64 字节。
• Hash 对象保留的键值对数量小于 512 个。

否则就是 hashtable 编码。

Set：Set 对象的编码能够是 intset 或 hashtable，intset 编码的对象应用整数汇合作为底层实现，把所有元素都保留在一个整数汇合外面。

保留元素为整数且元素个数小于肯定范畴应用 intset 编码，任意条件不满足，则应用 hashtable 编码；

Zset：Zset 对象的编码能够是 ziplist 或 zkiplist，当采纳 ziplist 编码存储时，每个汇合元素应用两个紧挨在一起的压缩列表来存储。

Ziplist 压缩列表第一个节点存储元素的成员，第二个节点存储元素的分值，并且按分值大小从小到大有序排列。

当 Zset 对象同时满足一下两个条件时，采纳 ziplist 编码：

• Zset 保留的元素个数小于 128。
• Zset 元素的成员长度都小于 64 字节。

如果不满足以上条件的任意一个，ziplist 就会转化为 zkiplist 编码。留神：这两个条件是能够批改的，在 redis.conf 中：

 zset-max-ziplist-entries 128
 zset-max-ziplist-value 64

单线程模型

65 哥：为什么 Redis 是单线程的而不必多线程并行执行充分利用 CPU 呢？

咱们要明确的是：Redis 的单线程指的是 Redis 的网络 IO 以及键值对指令读写是由一个线程来执行的。 对于 Redis 的长久化、集群数据同步、异步删除等都是其余线程执行。

至于为啥用单线程，咱们先理解多线程有什么毛病。

多线程的弊病

应用多线程，通常能够减少零碎吞吐量，充分利用 CPU 资源。

然而，应用多线程后，没有良好的零碎设计，可能会呈现如下图所示的场景，减少了线程数量，后期吞吐量会减少，再进一步新增线程的时候，零碎吞吐量简直不再新增，甚至会降落！

在运行每个工作之前，CPU 须要晓得工作在何处加载并开始运行。也就是说，零碎须要帮忙它事后设置 CPU 寄存器和程序计数器，这称为 CPU 上下文。

这些保留的上下文存储在零碎内核中，并在从新打算工作时再次加载。这样，工作的原始状态将不会受到影响，并且该工作将看起来正在间断运行。

切换上下文时，咱们须要实现一系列工作，这是十分耗费资源的操作。

另外，当多线程并行批改共享数据的时候，为了保证数据正确，须要加锁机制就会带来额定的性能开销，面临的共享资源的并发访问控制问题。

引入多线程开发，就须要应用同步原语来爱护共享资源的并发读写，减少代码复杂度和调试难度。

单线程又什么益处？

1. 不会因为线程创立导致的性能耗费；
2. 防止上下文切换引起的 CPU 耗费，没有多线程切换的开销；
3. 防止了线程之间的竞争问题，比方增加锁、开释锁、死锁等，不须要思考各种锁问题。
4. 代码更清晰，解决逻辑简略。

单线程是否没有充分利用 CPU 资源呢？

官网答案：因为 Redis 是基于内存的操作，CPU 不是 Redis 的瓶颈，Redis 的瓶颈最 有可能是机器内存的大小或者网络带宽。既然单线程容易实现，而且 CPU 不会成为瓶颈，那就牵强附会地采纳单线程的计划了。原文地址：https://redis.io/topics/faq。

I/O 多路复用模型

Redis 采纳 I/O 多路复用技术，并发解决连贯。采纳了 epoll + 本人实现的简略的事件框架。epoll 中的读、写、敞开、连贯都转化成了事件，而后利用 epoll 的多路复用个性，绝不在 IO 上节约一点工夫。

65 哥：那什么是 I/O 多路复用呢？

在解释 IO 多虑复用之前咱们先理解下根本 IO 操作会经验什么。

根本 IO 模型

一个根本的网络 IO 模型，当解决 get 申请，会经验以下过程：

1. 和客户端建设建设 accept;
2. 从 socket 种读取申请 recv;
3. 解析客户端发送的申请 parse;
4. 执行 get 指令；
5. 响应客户端数据，也就是 向 socket 写回数据。

其中，bind/listen、accept、recv、parse 和 send 属于网络 IO 解决，而 get 属于键值数据操作。既然 Redis 是单线程，那么，最根本的一种实现是在一个线程中顺次执行下面说的这些操作。

关键点就是 accept 和 recv 会呈现阻塞，当 Redis 监听到一个客户端有连贯申请，但始终未能胜利建设起连贯时，会阻塞在 accept() 函数这里，导致其余客户端无奈和 Redis 建设连贯。

相似的，当 Redis 通过 recv() 从一个客户端读取数据时，如果数据始终没有达到，Redis 也会始终阻塞在 recv()。

阻塞的起因因为应用传统阻塞 IO，也就是在执行 read、accept、recv 等网络操作会始终阻塞期待。如下图所示：

IO 多路复用

多路 指的是多个 socket 连贯，复用 指的是复用一个线程。多路复用次要有三种技术：select，poll，epoll。epoll 是最新的也是目前最好的多路复用技术。

它的基本原理是，内核不是监督应用程序自身的连贯，而是监督应用程序的文件描述符。

当客户端运行时，它将生成具备不同事件类型的套接字。在服务器端，I / O 多路复用程序（I / O 多路复用模块）会将音讯放入队列（也就是 下图的 I/O 多路复用程序的 socket 队列），而后通过文件事件分派器将其转发到不同的事件处理器。

简略来说：Redis 单线程状况下，内核会始终监听 socket 上的连贯申请或者数据申请，一旦有申请达到就交给 Redis 线程解决，这就实现了一个 Redis 线程解决多个 IO 流的成果。

select/epoll 提供了基于事件的回调机制，即针对不同事件的产生，调用相应的事件处理器。所以 Redis 始终在处理事件，晋升 Redis 的响应性能。

Redis 线程不会阻塞在某一个特定的监听或已连贯套接字上，也就是说，不会阻塞在某一个特定的客户端申请解决上。正因为此，Redis 能够同时和多个客户端连贯并解决申请，从而晋升并发性。

唯快不破的原理总结

65 哥：学完之后我终于晓得 Redis 为何快的实质起因了，「码哥」你别谈话，我来总结！一会我再点赞和分享这篇文章，让更多人晓得 Redis 快的外围原理。

1. 纯内存操作，个别都是简略的存取操作，线程占用的工夫很多，工夫的破费次要集中在 IO 上，所以读取速度快。
2. 整个 Redis 就是一个全局 哈希表，他的工夫复杂度是 O(1)，而且为了避免哈希抵触导致链表过长，Redis 会执行 rehash 操作，裁减 哈希桶数量，缩小哈希抵触。并且避免一次性 从新映射数据过大导致线程阻塞，采纳 渐进式 rehash。奇妙的将一次性拷贝摊派到屡次申请过程后总，防止阻塞。
3. Redis 应用的是非阻塞 IO：IO 多路复用，应用了单线程来轮询描述符，将数据库的开、关、读、写都转换成了事件，Redis 采纳本人实现的事件分离器，效率比拟高。
4. 采纳单线程模型，保障了每个操作的原子性，也缩小了线程的上下文切换和竞争。
5. Redis 全程应用 hash 构造，读取速度快，还有一些非凡的数据结构，对数据存储进行了优化，如压缩表，对短数据进行压缩存储，再如，跳表，应用有序的数据结构放慢读取的速度。
6. 依据理论存储的数据类型抉择不同编码

下一篇「码哥字节」将带来 《Redis 日志篇：无畏宕机疾速复原的杀手锏》，关注我，获取真正的硬核知识点。

另外技术读者群也开明了，后盾回复「加群」获取「码哥字节」作者微信，一起成长交换。

以上就是 Redis 唯快不破的机密详解，感觉不错请点赞、分享，「码哥字节」感激不尽。