Redis 为什么快

<li>

基于内存实现：Redis 将数据存储在内存中，读写操作不会受到磁盘 IO 速度限制；

CPU 不是 Redis 的瓶颈，Redis 的瓶颈在于机器内存的大小或者网络带宽

li>

• I/O多路复用模型的使用：Redis 线程不会阻塞在某一个特定的客户端请求处理上；

  可以同时和多个客户端连接并处理请求，从而提升了并发性

  li>

• 采用单线程模型：Redis 的网络 IO 以及键值对指令读写是由一个线程来执行的；

  对于 Redis 的持久化、集群数据同步、异步删除等都是其他线程执行的

  单线程避免了线程切换和竟态产生的消耗，对于服务端开发来说，锁和线程切换 通常为性能累赘

  li>

• 高效的数据结构：不同数据类型使用不同的数据结构得以提升速度

  li>

数据结构

数据类型

• string 字符串
• list 列表
• hash 哈希
• set 集合
• zset 有序集合

为什么加入 listpack？

在 redis7.2 之前，sds 类型的数据会直接放入到编码结构为 hashtable 的set 中

• 其中，sds 其实就是 redis 中的 string 类型

在 redis7.2 之后，sds 类型的数据，首先会使用 listpack 结构，当 set 达到一定的阈值时，才会自动转换为 hashtable。添加 listpack 结构是为了提高内存利用率和操作效率，因为 hashtable 的空间开销和碰撞概率都比较高

内存机制

内存回收策略

Redis 的内存回收机制主要表现为以下两方面：

• 删除到达过期时间的键对象
• 内存使用达到 Maxmemory 上限，触发内存溢出控制策略

删除过期对象：Redis 所有的键都可以设置过期属性，内部保存在过期字典中

• 惰性删除：当客户端读取带有超时属性键时，如果已经超过键设置的过期时间，将执行删除操作，并返回空li>
• 定时任务删除：Redis 内部维护了一个定时任务，默认每秒运行 10 次li>

内存溢出策略

当 Redis 所有内存达到 Maxmemory 上限时会触发相应的溢出策略：

优先使用 allkeys-lru 策略：业务数据中有明显的冷热数据区分，建议使用 allkeys-lru 策略

业务应用访问频率相差不大，没有明显的冷热数据区分，建议使用 allkeys-random 策略

业务中有置顶的需求，比如置顶视频、新闻，可以使用 volatile-lru 策略

持久化

RDB 持久化

概览

将内存中的数据生成快照保存到磁盘里面，保存的文件后缀是 .rdb

rdb 文件是一个经过压缩的二进制文件，当 Redis 重新启动时，可以读取 rdb 快照文件恢复数据

其中，包括 rdbSave 和 rdbLoad 两个函数

<li>rdbSave 用于生成 RDB 文件并保存到磁盘
• rdbLoad 用于将 RDB 文件中的数据加载到内存中

RDB 文件是一个单文件的全量数据，适合数据的容灾备份与恢复

<li>通过 RDB 文件恢复数据库耗时较短，通常 1G 的快照文件加载到内存只需要 20s 左右

RDB 文件生成方式

1. 手动触发快照生成，通过 SAVE 和 BGSAVE 命令li>

• SAVE 是一个同步式的命令，ta 会阻塞 Redis 服务器进程，直到 RDB 文件创建完成为止
  <li>在服务器阻塞期间，服务器不能处理任何其他的命令请求
• BGSAVE 是一个异步式的命令，会派生一个子进程，由子进程负责创建 RDB 文件，服务器进程（父进程）继续处理客户的命令
  <li>基本过程：
  <li>客户端发起 BGSAVE 命令，Redis 主进程判断当前是否存在正在执行备份的子进程，如果存在则直接返回
  • 父进程 fork 一个子进程（fork 的过程中会造成阻塞的情况）li>
  • fork 创建的子进程开始根据父进程的内存数据生成临时的快照文件，然后替换源文件
  • 子进程备份完毕后会向父进程发送完成信息

<li>自动触发保存

通过 save 选项设置多个保存条件，只要其中任意一个条件被满足，服务器就会执行 BGSAVE 命令

只要满足以下 3 个条件中的任意一个，BGSAVE 命令就会被自动执行：

<li>服务器在 900s 之内，对数据库进行了至少 1次 修改
• 服务器在 300s 之内，对数据库进行了至少 10次 修改
• 服务器在 60s 之内，对数据库进行了至少 10000次 修改

AOF 持久化

概览

AOF 会把 Redis 服务器每次执行的写命令记录到一个日志文件中，当服务器重启时，再次执行 AOF 文件中的命令来恢复数据

如果 Redis 服务器开启了 AOF 持久化，会优先使用 AOF 文件来还原数据库状态

只有在 AOF 的持久化功能处于关闭状态时，服务器才会使用 RDB 文件还原数据库状态

AOF 优先级大于 RDB

执行流程

AOF 不需要设置任何触发条件，对 Redis 服务器的所有写命令都会自动记录到 AOF 文件中

AOF 文件的写入流程可以分为 3个 步骤：

<li>命令追加（append）：将 Redis 执行的写命令追加到 AOF 的缓存区 aof_bufli>
1. 文件写入（write）和文件同步（fsync）：AOF 根据对应的策略将 aof_buf 的数据同步到硬盘li>
2. 文件重写（rewrite）：定期对 AOF 进行重写，从而实现对写命令的压缩li>

AOF 缓存区的文件同步策略

• appendfysnc always：每执行一次命令保存一次
  • 命令写入 aof_buf 缓存区后立即调用系统 fsync 函数同步到 AOF 文件，fsync 操作完成后线程返回，整个过程是阻塞的
• appendfysnc no：不保存
  • 命令写入 aof_buf 缓存区调用系统 write 操作，不对 AOF 文件做 fsync 同步
  • 同步由操作系统负责，通常同步周期为 30s
• appendfysnc everysec：每秒钟保存一次
  • 命令写入 aof_buf 缓存区后调用系统 write 操作，write 完成后线程立刻返回，fsync 同步文件操作由单独的进程每秒调用一次

文件重写

把对 AOF 文件中的写命令进行合并，压缩文件体积，同步到新的 AOF 文件中，然后使用新的 AOF 文件覆盖旧的 AOF 文件

触发机制：

<li>手动触发：调用 bgrewriteaof 命令，执行与 bgsave 有些类似li>
• 自动触发：
  <li>根据 auto-aof-rewrite-min-size 和 auto-aof-rewrite-percentage 配置项，以及 aof_current_size 和 aof_base_size 的状态确定触发时机
  • auto-aof-rewrite-min-size：执行 AOF 重写时，文件的最小体积，默认值为 64MB
  • auto-aof-rewrite-percentage：执行 AOF 时，当前 AOF 大小（aof_current_size）和上一次重写时 AOF 大小（aof_base_size） 的比值

重写流程：

<li>客户端通过 bgrewriteaof 命令对 Redis 主进程发起 AOF 重写请求
• 主进程通过 fork 操作创建子进程，这个过程主进程是阻塞的
• 主进程的 fork 操作完成后，继续处理其他命令，把新的命令同时追加到 aof_buf 和 aof_rewrite_buf 缓冲区中
  • 在文件重写完成之前，主进程会继续把命令追加到 aof_buf 缓冲区，这样可以避免 AOF 重写失败造成数据丢失，保证原有的 AOF 文件的正确性
  • 由于 fork 操作运用写时复制技术，子进程只能共享 fork 操作时的内存数据，主进程会把新命令追加到一个 aof_rewrite_buf 缓冲区中，避免 AOF 重写时丢失这部分数据
• 子进程读取 Redis 进程中的数据快照，生成写入命令并按照命令合并规则批量写入到新的 AOF 我呢间
• 子进程写完新的 AOF 的文件后，向主进程发信号（怎么进行的信号发送？？？？）
• 主进程接收到子进程的信号后，将 aof_rewrite_buf 缓冲区中的写命令追加到 AOF 文件
• 主进程使用新的 AOF 文件替换旧的 AOF 文件，AOF 重写过程完成

RDB&AOF

RDB的优缺点

• 优点：

  • RDB 是一个压缩过的非常紧凑的文件，保存着某个时间点的数据集，适合做数据的备份、灾难恢复
  • 与 AOF 持久化相比，恢复大数据集会更快些

• 缺点：

  • 数据安全性不入 AOF，保存整个数据集是个重量级的过程，可能几分钟一次持久化，如果服务器宕机，可能丢失几分钟的数据
  • Redis 数据集较大时，fork 的子进程要完成快照会比较耗费 cpu 和时间

AOF 的优缺点

• 优点：
  • 数据更完整，安全性更高，秒级数据丢失
  • AOF 文件是一个只进行追加的命令文件，且写入操作是以 Redis 协议的格式保存，内容是可读的，适合误删紧急恢复
• 缺点：
  • 对于相同的数据集，AOF 文件的体积要远大于 RDB 文件，数据恢复也会比较慢

RDB&AOF 混合持久化

Redis 4.0 版本提供了一套基于 AOF-RDB 的混合持久化机制，保留了两种持久化机制的优点

然后，重写的 AOF 文件由两部分组成，一部分是 RDB 格式的头数据，另一部分是 AOF 格式的尾部命令

在 Redis 服务器启动的时候：

<li>可以预先加载 AOF 文件头部全量的 RDB 数据
• 然后再重放 AOF 文件尾部增量的 AOF 命令，从而大大减少重启过程中数据还原的时间

基本原理

redis 协议

RESP，是一种简单的文本协议，用于在客户端和服务器之间操作和传输数据

RESP 协议描述了不同类型数据结构，并且定义了请求和响应之间如何以这些数据结构进行交互

单线程模式

Redis 的网络 IO 和键值对读写是由一个线程来完成的

Redis 在处理客户端请求时包括获取（读）、解析、执行、内容返回（写）等都由一个顺序串行的主线程处理

由于 Redis 在处理命令的时候是单线程作业的，所以会有一个 Socket 队列

• 每一个到达 de 服务端命令来了之后不会立马被执行，而是进入队列，然后被线程的事件分发器逐个执行

Redis 的其他功能，比如持久化、异步删除、集群数据同步等，都是交由额外线程执行的

哨兵模式

概览

Redis 的主从复制模式下，一旦主节点由于故障不能提供服务，需要手动将从节点晋升为主节点，同时还需要通知客户端更新主节点地址

Redis 2.8 以后提供了 Redis Sentinel 哨兵机制来解决这个问题

（注册中心 心跳机制）

Redis Sentinel 的主要功能

Sentinel 是一个管理多个 Redis 实例的工具，ta 可以实现对 Redis 的监控、通知、自动故障转移

<li>监控：Sentinel 会不断检查主服务器和从服务器是否正常运行
• 通知：当被监控的某一个 Redis 服务器出现问题，Sentinel 通过 API 脚本向管理员或其他的应用程序发送通知
• 自动故障转移：当主节点不能正常工作时，Sentinel 会开始一次自动的故障转移操作，ta 会将与失效主节点是主从关系的其中一个从节点升级为新的主节点，并且将其他的从节点指向新的主节点
• 配置提供者：在 Redis Sentinel 模式下，客户端应用在初始化时连接的是 Sentinel 节点集合，从中获取主节点的信息

主观下线和客观下线

默认情况下，每个 Sentinel 节点会以每秒一次的频率对 Redis 节点和其 ta 的 Sentinel 节点发送 PING 命令，并通过节点的回复来判断节点是否在线

主观下线

• 适用于所有主节点和从节点
• 如果 down-after-millisenconds 毫秒内，Sentinel 没有收到目标节点的有效回复，则会判定该节点为主观下线

客观下线

• 只适用于主节点
• 如果主节点出现故障，Sentinel 节点会通过 sentinel is-master-down-by-addr 命令，向其他 Sentinel 节点询问对该节点的状态判断
• 如果超过 quorum 个数的节点判定主节点不可达，则该 Sentinel 节点会判断主节点为客观下线

工作原理

1. 每个 Sentinel 以每秒钟一次的评率，向 ta 所知的主服务器、从服务器以及其 ta Sentinel 实例发送一个 PING 命令
2. 如果实例距离最后一次有效回复 PING 命令的时间超过 down-after-millisenconds 所指定的值，这个实例会被 Sentinel 标记为主观下线
3. 如果一个主服务器被标记为主观下线，并且有足够的 Sentinel 在指定的时间范围内同意这一判断，那么这个主服务器被标记为客观下线
4. Sentinel 和其 ta Sentinel 协商主节点的状态，如果主节点处于 SDOWN 状态，则投票自动选出新的主节点，将剩余的从节点指向新的主节点进行数据复制

脑裂问题

在 Redis 哨兵模式或集群模式中，由于网络原因，导致主节点（Master）与哨兵（Sentinel）和从节点（Slave）的通讯中断。此时，哨兵就会误以为主节点已宕机，就会 在从节点中选举出一个新的主节点，此时 Redis 的集群中就会出现了两个主节点的问题。

脑裂问题影响

Redis 脑裂问题会导致数据丢失

当旧的 Master 变为 Slave 之后 de 执行流程如下：

<li>Slave（旧Master）会向 Master（新）申请全量数据
• Master 会通过 Bgsave 的 方式生成当前 RDB 快照，并且将 RDB 发送给 Slave
• Slave 拿到 RDB 之后，先进行 Flush 清空当前数据（此时第四步旧客户端给 ta 的发送的数据就丢失了）
• 之后再加载 RDB 数据，初始化自己当前的数据

在执行到第三步时，原客户端在旧 Master 写入的数据就丢失了

解决脑裂问题

Redis 提供了一下两个配置，通过一下两个配置可以尽可能的避免脑裂导致数据丢失的问题：

• min-slaves-to-write：与主节点通信的从节点数量必须大于等于该值主节点，否知主节点拒绝写入li>
• min-slaves-max-lag：主节点与从节点通信 de ACK 消息延迟必须小于该值，否则主节点拒绝写入li>

这两个配置项必须同时满足，不然主节点拒绝写入

集群

概览

Redis 3.0 之前，使用哨兵（Sentinel）机制来监控各个节点之间的状态

在 3.0 版本正式推出，解决了 Redis 在分布式方面的需求

数据分区

Redis Cluster 采用虚拟槽分区，所有的键根据哈希函数映射到 0~16383 整数槽内

• 计算公式：slot = CRC16（KEY） & 16383
• 每个节点负责维护一部分槽以及槽所映射的键值数据

为什么 Redis 集群的最大槽数是 16384 个

2^14 = 16384、 2^16 = 65536

• 如果槽位是 65536 个，发送心跳信息的消息头是 65536 / 8 / 1024 = 8k
• 如果槽位是 16384 个，发送心跳信息的消息头是 16384 / 8 / 1024 = 2k

因为 Redis 每秒都会发送一定数据量的心跳包，如果消息头是 8k，有些太大了，浪费网络资源

Redis 的集群主节点数量一般不会超过 1000 个

• 集群中节点越多，心跳包的消息体内的数据就越多，如果节点过多，也会造成网络拥堵

so，Redis Cluster 的节点建议不超过 1000 个，对于节点数在 1000 个以内的 Redis Cluster，16384 个槽位完全够用

集群的功能限制

• key 批量操作支持有限：类似 mset、mget 操作，目前支持对具有相同 slot 值 key 执行批量操作；对于映射为不同 slot 值的 key 由于执行 mset、mget等操作可能存在于多个节点上，因此不被支持
• key 事务操作支持有限：只支持多 key 在同一节点上的事务操作，当多个 key 分布在不同的节点上时，无法使用事务功能；单机下 Redis 可以支持 16个数据库（db0~db15），集群模式下只能使用一个数据库空间，即 db0