最全面的Redis知识点总结（上）--原理篇

前言

趁着五一假期，爆肝了一篇《最全面的MySQL知识点总结》，现在迎来了全面总结系列之Redis篇，分享给大家。考虑到内容较多，为了方便大家约定，固将文章分为上下篇，上篇主要介绍原理，下篇主要是在实战中的一些问题分析；

一、基本架构

二、数据结构与对象

1、总体结构

为了实现从键到值的快速访问，Redis 使用了一个哈希表来保存所有键值对

一个哈希表，其实就是一个数组，数组的每个元素称为一个哈希桶，哈希桶中的元素保存的并不是值本身，而是指向具体值的指针，哈希桶中的 entry 元素中保存了key和value指针，分别指向了实际的键和值，这样一来，即使值是一个集合，也可以通过*value指针被查找到，因为这个哈希表保存了所有的键值对，所以，我也把它称为全局哈希表。

1.1、如何解决哈希冲突问题？

既然Redis使用了全局哈希表进行存储，那么它是如何解决哈希冲突问题呢？就是链式哈希。链式哈希也很容易理解，就是指同一个哈希桶中的多个元素用一个链表来保存，它们之间依次用指针连接。但是采用链式哈希存在一个问题，就是如果链表太长会影响效率。所以Redis采用rehash操作来解决这个问题。

1.2、rehash

redis默认使用两个全局哈希表，默认使用哈希表1（ht[0]），此时哈希表2(ht[1])没有分配空间，当随着数据增多或者减少时，需要对哈希表进行扩展或者收缩，即通过rehash来完成，
rehash步骤：

1、给ht[1]分配空间：
如果是扩展操作：空间的大小大于等于ht[0].used * 2(数值为2的n次方），例如ht[0].used是4，那么会扩展到4 * 2=8(2^3);
如果是收缩操作，空间大小为大于登录ht[0].used(2^n)
2、将ht[0]上的键值重新计算哈希值和索引值，放入到ht[1]中；
3、ht[0]完成迁移后释放ht[0]的内存，将ht[1]设置为ht[0],并在ht[1]创建一个空白哈希表，为下次rehash做准备

但是当数据量巨大时，直接一次性迁移数据，会按照Redis线程阻塞，影响服务，所以需要Redis采用渐进式rehash来完成这个操作；

1.3、渐进式rehash

在拷贝数据时，Redis仍然正常处理客户端请求，并且维护了一个索引计数器变量rehashidx，开始值为0，每处理一次请求时，就从ht[0]中对应的索引位置拷贝数据执行rehash操作，操作完rehashidx加1，直到完成所有的数据操作，rehashidx置为-1
执行渐进式rehash期间，如果有查找操作，会先在ht[0]中查找，找不到的话，再继续在ht[1]中查找；如果是新增操作，会直接保存在ht[1]上；

1.4、何时执行扩展与收缩？

上述介绍了Redis是通过渐进式rehash进行扩展和收缩操作，那么什么时候会进行扩展和收缩呢？这个取决于不同场景以及一个重要的参数，负载因子。负载因子的计算公式如下：

负载因子=哈希表已保存节点数量/哈希表大小
load_factor=ht[0].used / ht[0].size

• 扩展：
  • 服务器目前没有在执行BGSAVE命令或者BGRERITEAOF命令，并且负载因子大于等于1时；
  • 服务器目前正在执行BGSAVE命令或者BGREWRITEAOF命令，并且哈希表的负载因子大于等于5时（在执行RDB或者AOF重写操作时，redis会创建当前服务器的子进程执行相应操作，为了避免在子进程存在期间对哈希表进行扩展操作，将扩展因子提高。可以避RDB或者AOF重写时不必要的内存写入操作，最大限度的节约内存）；
• 收缩： 当负载因子小于0.1时，自动开始执行收缩操作

2、数据结构

2.1、Redis数据类型与数据结构对应关系

从上述图中可以知道，Redis的底层数据结构由简单动态字符串、双向链表、压缩列表、哈希表、跳表、整数数组组成，其中哈希表和整数数组基本上大家都很熟悉了，下面重点介绍一下其余的几种数据结构。

2.2、简单动态字符串(SDS)

结构：alloc，len，buf

• buf：字节数组，保存实际数据。为了表示字节数组的结束，Redis 会自动在数组最后加一个“\0”，这就会额外占用 1 个字节的开销。
• len：占 4 个字节，表示 buf 的已用长度。
• alloc：也占个 4 字节，表示 buf 的实际分配长度，一般大于 len。
  那么SDS与C字符串有什么区别呢？区别主要有如下两点：

1、获取字符串长度时间复杂度为O(1)
2、在修改字符串时，会先检查长度是否够长，不够会进行扩展，避免缓冲区溢出

2.3、链表

Redis使用的是双向无环链表，并且具有以下几个特点：

①、双端：链表具有前置节点和后置节点的引用，获取这两个节点时间复杂度都为O(1)。
②、无环：表头节点的 prev 指针和表尾节点的 next 指针都指向 NULL,对链表的访问都是以 NULL 结束。
③、带链表长度计数器：通过 len 属性获取链表长度的时间复杂度为 O(1)。
④、多态：链表节点使用 void* 指针来保存节点值，可以保存各种不同类型的值。

2.4、压缩列表

压缩列表（ziplist）是Redis为了节省内存而开发的，是由一系列特殊编码的连续内存块组成的顺序型数据结构，一个压缩列表可以包含任意多个节点（entry），每个节点可以保存一个字节数组或者一个整数值。压缩列表并不是对数据利用某种算法进行压缩，而是将数据按照一定规则编码在一块连续的内存区域，目的是节省内存。

压缩列表实际上类似于一个数组，数组中的每一个元素都对应保存一个数据。和数组不同的是，压缩列表在表头有三个字段 zlbytes、zltail 和 zllen，分别表示列表长度、列表尾的偏移量和列表中的 entry 个数；压缩列表在表尾还有一个 zlend，表示列表结束；

压缩列表的每个节点构成：
①、previous_entry_ength：记录压缩列表前一个节点的长度。previous_entry_ength的长度可能是1个字节或者是5个字节，如果上一个节点的长度小于254，则该节点只需要一个字节就可以表示前一个节点的长度了，如果前一个节点的长度大于等于254，则previous length的第一个字节为254，后面用四个字节表示当前节点前一个节点的长度。利用此原理即当前节点位置减去上一个节点的长度即得到上一个节点的起始位置，压缩列表可以从尾部向头部遍历。这么做很有效地减少了内存的浪费；
②、encoding：节点的encoding保存的是节点的content的内容类型以及长度，encoding类型一共有两种，一种字节数组一种是整数，encoding区域长度为1字节、2字节或者5字节长；
③、content：content区域用于保存节点的内容，节点内容类型和长度由encoding决定；

我们要查找定位第一个元素和最后一个元素，可以通过表头三个字段的长度直接定位，复杂度是 O(1)。而查找其他元素时，就没有这么高效了，只能逐个查找，此时的复杂度就是 O(N) 了

2.5、跳表

跳表在链表的基础上，增加了多级索引，通过索引位置的几个跳转，实现数据的快速定位，时间复杂度为O(logN)

三、IO模型

1、为什么使用单线程？

Redis是单线程，主要是指Redis的网络io和键值对读写是由一个线程来完成的，这也是对外提供键值存储服务的主要流程，Redis的其他功能，比如持久化、异步删除、集群数据同步等，都是由其他线程执行的，之所以使用单线程主要是为了避免多线程中的并发控制问题。

2、单线程为啥快？

Redis使用单线程但是速度依旧很快，主要是因为以下几点原因：

• 大部分操作是在内存上完成的；
• 高效的数据结构
• 采用多路复用机制IO模型
  对于io多路复用机制主要有以下几种实现方式：
  • select ：select本质上是通过设置或者检查存放fd标志位的数据结构来进行下一步处理
    • 优点：几乎在所有的平台上支持，有良好跨平台支持
    • 缺点：①、单个进程打开的文件描述是有一定限制的，它由FD_SETSIZE设置，默认值是1024（32位机默认是1024个。64位机默认是2048）；
      ②、采用数组存储，另外在检查数组中是否有文件描述需要读写时，采用的是线性扫描的方法，即不管这些socket是不是活跃的，都轮询一遍，所以效率比较低；
      ③、每次调用select，都需要把fd集合从用户态拷贝到内核态，这个开销在fd很多时会很大
  • poll： poll本质上和select没有区别，它将用户传入的数组拷贝到内核空间，然后查询每个fd对应的设备状态，如果设备就绪则在设备等待队列中加入一项并继续遍历；
    • 优点：采样链表的形式存储，它监听的描述符数量没有限制
    • 缺点：在检查链表中是否有文件描述需要读写时，采用的是线性扫描的方法，即不管这些socket是不是活跃的，都轮询一遍，所以效率比较低
  • epoll：epoll可以理解为event poll，不同于忙轮询和无差别轮询，epoll会把哪个流发生了怎样的I/O事件通知我们，epoll使用“事件”的就绪通知方式，通过epoll_ctl注册fd，一旦该fd就绪，内核就会采用类似callback的回调机制来激活该fd，epoll_wait便可以收到通知
    • 触发模式：
      ①、LT模式（默认的模式）：只要这个fd还有数据可读，每次 epoll_wait都会返回它的事件，提醒用户程序去操作；
      ②、ET模式（边缘触发） “高速”模式：它只会提示一次，直到下次再有数据流入之前都不会再提示了，无论fd中是否还有数据可读；
    • 优点：
      ①、epoll 没有最大并发连接的限制，能打开的FD的上限远大于1024（1G的内存上能监听约10万个端口）
      ②、最大的优点就在于它只管你“活跃”的连接，而跟连接总数无关，因此在实际的网络环境中，Epoll的效率就会远远高于select和poll
      ③、内存拷贝，利用mmap()文件映射内存加速与内核空间的消息传递；即epoll使用mmap减少复制开销
    • 缺点：只能在Linux系统中使用；

四、持久化

Redis是内存数据库，宕机后数据会消失，而且Redis重启后快速恢复数据，所以需要提供持久化机制，Redis有两种持久化方式：RDB和AOF

1、AOF

AOF（append only file）是Redis的另一种持久化方式。Redis默认情况下是不开启的。开启AOF持久化后，Redis 将所有对数据库进行过写入的命令（及其参数）（RESP）记录到 AOF 文件， 以此达到记录数据库状态的目的，这样当Redis重启后只要按顺序回放这些命令就会恢复到原始状态了；

1.1、原理

AOF文件中存储的是redis的命令，同步命令到 AOF 文件的整个过程可以分为三个阶段：

• 命令传播：当一个 Redis 客户端需要执行命令时， 它通过网络连接， 将协议文本发送给 Redis 服务器。服务器在接到客户端的请求之后， 它会根据协议文本的内容， 选择适当的命令函数， 并将各个参数从字符串文本转换为 Redis 字符串对象（ StringObject ）。每当命令函数成功执行之后， 命令参数都会被传播到AOF程序；
• 缓存追加 ：当命令被传播到 AOF 程序之后， 程序会根据命令以及命令的参数， 将命令从字符串对象转换回原来的协议文本。协议文本生成之后， 它会被追加到 redis.h/redisServer 结构的 aof_buf 末尾。redisServer 结构维持着 Redis 服务器的状态， aof_buf 域则保存着所有等待写入到 AOF 文件的协议文本（RESP）。
• 文件写入和保存：每当服务器常规任务函数被执行、 或者事件处理器被执行时，aof.c/flushAppendOnlyFile 函数都会被调用， 这个函数执行以下两个工作：
  • WRITE：根据条件，将 aof_buf 中的缓存写入到 AOF 文件。
  • SAVE：根据条件，调用 fsync 或 fdatasync 函数，将 AOF 文件保存到磁盘中；

1.2、AOF三种写回策略

Redis 目前支持三种 AOF写回策略，通过配置项appendfsync来进行选择

三种策略的优缺点

1.3、AOF重写机制

AOF记录数据的变化过程，越来越大，Redis可以在 AOF体积变得过大时，自动地在后台（Fork子进程）对 AOF进行重写，为什么重写机制可以把日志文件变小呢? 实际上，重写机制具有“多变一”功能。所谓的“多变一”，也就是说，旧日志文件中的多条命令，在重写后的新日志中变成了一条命令。

• 重写过程：“一个拷贝，两处日志”：

  • 一个拷贝：每次执行重写时，主线程 fork 出后台的 bgrewriteaof 子进程。此时，fork 会把主线程的内存拷贝一份给 bgrewriteaof 子进程，这里面就包含了数据库的最新数据。然后，bgrewriteaof 子进程就可以在不影响主线程的情况下，逐一把拷贝的数据写成操作，记入重写日志；
    

    fork子进程时，子进程是会拷贝父进程的页表，即虚实映射关系，而不会拷贝物理内存。子进程复制了父进程页表，也能共享访问父进程的内存数据了
    采用写时复制，如果操作系统开启了内存大页机制(Huge Page，页面大小2M)，那么父进程申请内存时阻塞的概率将会大大提高，所以在Redis机器上需要关闭Huge Page机制

  • AOF日志：正在使用的AOF日志

  • AOF重写日志：新的写操作会写日志到AOF重写缓冲中，等从内存拷贝的AOF重写日志生成好后再合并进去，生成完整的AOF重写日志

• 触发方式

  • ①、在redis.conf中配置

    auto-aof-rewrite-percentage 100：表示当前aof文件大小超过上一次aof文件大小的百分之多少的时候会进行重写。如果之前没有重写过，以启动时aof文件大小为准
    auto-aof-rewrite-min-size 64mb：限制允许重写最小aof文件大小，也就是文件大小小于64mb的时候，不需要进行优化

  • ②、执行bgrewriteaof命令

1.4、性能问题

AOF日志太大会引起性能问题，主要在于以下三个方面：

• ①、文件系统本身对文件大小有限制，无法保存过大的文件；
• ②、如果文件太大，之后再往里面追加命令记录的话，效率也会变低；
• ③、如果发生宕机，AOF 中记录的命令要一个个被重新执行，用于故障恢复，如果日志文件太大，整个恢复过程就会非常缓慢，这就会影响到 Redis 的正常使用；

2、RDB

RDB（Redis DataBase），是redis默认的存储方式，RDB方式是通过快照完成的。

2.1、触发方式

• 1、 符合自定义配置的快照规则：在redis.conf中配置：save 多少秒内 数据变了多少

save “” # 不使用RDB存储 不能主从
save 900 1 # 表示15分钟（900秒钟）内至少1个键被更改则进行快照。
save 300 10 # 表示5分钟（300秒）内至少10个键被更改则进行快照。

• 2、执行save或者bgsave命令：save，在主线程中执行，会导致阻塞。bgsave，fork一个子进程，专门用于写入RDB，这是默认配置；
• 3、执行flushall命令
• 4、执行主从复制操作 (第一次)

2.1、执行原理

采用写时复制来解决生成RDB文件时主线程仍然写入数据的问题

2.2、RDB的优缺点

• 优点：RDB是二进制压缩文件，占用空间小，便于传输（传给slaver），主进程fork子进程，可以最大化Redis性能，主进程不能太大，复制过程中主进程阻塞
• 缺点：不保证数据完整性，会丢失最后一次快照以后更改的所有数据；
• 优化：针对于这个缺点，Redis4.0提出混合使用AOF日志和内存快照，简单来说，内存快照以一定的频率执行，在两次快照之间，使用 AOF 日志记录这期间的所有命令操作，这样一来，快照不用很频繁地执行，这就避免了频繁 fork 对主线程的影响。而且，AOF 日志也只用记录两次快照间的操作，也就是说，不需要记录所有操作了，因此，就不会出现文件过大的情况了，也可以避免重写开销。

  开启混合持久化：aof-use-rdb-preamble yes
  如果把混合持久化打开，aofrewrite 的时候就直接把 rdb 的内容写到 aof 文件开头，RDB的头+AOF的身体=appendonly.aof
  在加载时，首先会识别AOF文件是否以REDIS字符串开头，如果是就按RDB格式加载，加载完RDB后继续按AOF格式加载剩余部分

五、高可用

1、主从模式

一主多从，主从同步，实现读写分离，主负责写，从负责读，从而提升Redis的性能和吞吐量

1.1、主从同步

启动多实例时，可以通过repicaof（Redis5.0之前使用slaveof）命令进行例如：replicaof 172.16.19.3 6379，172.16.19.3为主库，主从数据同步主要由三个阶段完成，第一次同步是全量复制生成RDB文件，并且在主库内存中专门用replication buffer，记录RDB文件生成后收到的所有写操作，在第三阶段时将replication buffer中的内容发送给从库，完成同步；

1.2、主从库网络断了怎么办

• Redis2.8之前，从库重连后会进行全量复制，开销很大
• 2.8版本之后，重连会以增量复制的方式进行同步

  主从库断连之后，主库会把断连期间收到的写操作命令写入replication buffer，同时也会写入repl_backlog_buffer这个缓冲区；
  repl_backlog_buffer 是一个环形缓冲区，主库会记录自己写到的位置，从库则会记录自己已经读到的位置。
  repl_backlog_buffer写满时会触发全量复制，所以需要调节repl_backlog_size；

1.3、主从级联模式分担全量复制时的主库压力

一次全量复制中，对于主库来说，需要完成两个耗时的操作：生成 RDB 文件和传输 RDB 文件。会影响主库性能，通过“主 - 从 - 从”模式将主库生成 RDB 和传输 RDB 的压力，以级联的方式分散到从库上。

2、哨兵机制

在主从模式中，从机是主机的备份，主机宕机，从机可读不可写，默认情况下主机宕机后，从机不可为主机，为了能够做到高可用，Redis引入了哨兵机制来实现主从切换；

2.1、哨兵的作用

• 监控 ：周期性给所有主从库发送PING命令，检测是否在线；
• 选主 ：选取新的主库
• 通知：哨兵会把新主库的连接信息发给其他从库，让它们执行 replicaof 命令，和新主库建立连接，并进行数据复制。同时，哨兵会把新主库的连接信息通知给客户端，让它们把请求操作发到新主库上

2.2、选主

防止误判，将主库先标记位主观下线，大于一半的哨兵确认后客观下线，重新选主；对于选主过程是在多个从库中，先按照一定的筛选条件，把不符合条件的从库去掉。然后，我们再按照一定的规则，给剩下的从库逐个打分，将得分最高的从库选为新主库

• 筛选条件：网络状况是否良好：down-after-milliseconds * 10，断连次数超过10次，网络状况不好；
• 规则：
  • 第一轮：优先级最高的从库得分高，可以通过 slave-priority 配置项，给不同的从库设置不同优先级
  • 第二轮：和旧主库同步程度最接近的从库得分高，即slave_repl_offset 需要最接近 master_repl_offset；
  • 第三轮：ID 号小的从库得分高；

2.3、哨兵集群

• 如何配置集群：sentinel monitor < master-name > < ip > < redis-port > < quorum >
• 哨兵之间的消息互通：通过订阅“sentinel:hello”的频道，基于pub/sub机制实现哨兵之间的消息互通；
  
• 与服务端通信：通过向主库发送INFO命令获取从库的ip和端口，从而建立连接
  
• 与客户端通信：基于pub/sub机制的客户端事件通知：客户端可以通过哨兵订阅消息，来获取不同的事件通知
  
• 主从切换：由哪个哨兵来执行主从切换？任何一个哨兵判断主库“主观下线”就会给其他实例发送is-master-down-by-addr命令，收到大于等于quorum数量的Y响应后，就可以标记主库为“客观下线”，这时候会再发送命令希望由自己来执行“选为leader”，需要满足两个条件：1、拿到半数以上的赞成票，2、拿到得票数大于登录quorum值。注意：要保证所有哨兵实例的配置是一致的，尤其是主观下线的判断值 down-after-milliseconds，因为这个值在不同的哨兵实例上配置不一致，会导致哨兵集群一直没有对有故障的主库形成共识，也就没有及时切换主库，最终的结果就是集群服务不稳定。

3、切片集群（Redis Cluster）

3.1、如何存储更多的数据？

随着Redis的使用，存储的数据会越来越多，为了不影响性能，所以需要考虑如何才能存储更多的数据

• 纵向扩展：升级单个 Redis 实例的资源配置，包括增加内存容量、增加磁盘容量、使用更高配置的 CPU。就像下图中，原来的实例内存是 8GB，硬盘是 50GB，纵向扩展后，内存增加到 24GB，磁盘增加到 150GB。
  • 存在两个问题：
    • 第一个问题是，当使用 RDB 对数据进行持久化时，如果数据量增加，需要的内存也会增加，主线程 fork 子进程时就可能会阻塞（比如刚刚的例子中的情况）。不过，如果你不要求持久化保存 Redis 数据，那么，纵向扩展会是一个不错的选择；
    • 第二个问题：纵向扩展会受到硬件和成本的限制。这很容易理解，毕竟，把内存从 32GB 扩展到 64GB 还算容易，但是，要想扩充到 1TB，就会面临硬件容量和成本上的限制了。
• 横向扩展：横向增加当前 Redis 实例的个数，比如原来使用 1 个 8GB 内存、50GB 磁盘的实例，现在使用三个相同配置的实例，与纵向扩展相比，横向扩展是一个扩展性更好的方案。这是因为，要想保存更多的数据，采用这种方案的话，只用增加 Redis 的实例个数就行了，不用担心单个实例的硬件和成本限制。在面向百万、千万级别的用户规模时，横向扩展的 Redis 切片集群会是一个非常好的选择。

3.2、Redis Cluster方案

redis3.0之后官方提供了Redis Cluster方案，其主要原理是，一个切片集群被分为16384个哈希槽，根据键值对的key，按照CRC16算法计算一个16bit的值，然后对16384取模，存入到对应模数的槽中

3.3、容灾（failover）

3.3.1、故障检测

集群中的每个节点都会定期地（每秒）向集群中的其他节点发送PING消息，在一定时间内(cluster-node-timeout)，发送ping的节点A没有收到某节点B的pong回应，则A将B标识为pfail，如果B被标记为pfail的个数大于集群主节点个数的一半（N/2 + 1）时，B会被标记为fail，A向整个集群广播，该节点已经下线；

3.3.2、从节点选举

当切片中的主节点下线后，需要从从节点中重新选举出一个节点充当主节点，使用raft协议，每个从节点，都根据自己对master复制数据的offset，来设置一个选举时间，offset越大（复制数据越多）的从节点，选举时间越靠前，优先进行选举，具体步骤如下：

• ①、slave 通过向其他master发送FAILVOER_AUTH_REQUEST 消息发起竞选；
• ②、master 收到后回复FAILOVER_AUTH_ACK 消息告知是否同意
• ③、所有的Master开始slave选举投票，给要进行选举的slave进行投票，如果大部分master node（N/2 +1）都投票给了某个从节点，那么选举通过，那个从节点可以切换成master

3.3.2、副本漂移

Master1宕机，则Slaver11提升为新的Master1，集群检测到新的Master1是单点的（无从机），集群从拥有最多的从机的节点组（Master3）中，选择节点名称字母顺序最小的从机（Slaver31）漂移到单点的主从节点组(Master1)

3.4、客户端访问哈希槽

各个实例间会互相通知自己的槽信息，每个实例都有完整的哈希槽映射关系，当客户端与集群建立连接后，会将槽信息缓存在本地，当槽的对应关系发生变化时，采用重定向机制来实现客户端的访问，当访问的槽不在原实例上，会返回MOVED命令响应，其中包括了哈希槽的值和新实例的地址
当槽还在迁移中时，返回ASK（GET hello:key (error) ASK 13320 172.16.19.5:6379），和 MOVED 命令不同，ASK 命令并不会更新客户端缓存的哈希槽分配信息