Redis架构原理探究

Redis架构原理

无论从设计还是源码，Redis都尽量做到简单，其中的原理也通俗易懂。

Redi本质

是一个数据结构处理器，已高效的方式实现了多种现成的数据结构，没有MySQL那样的索引机制，内建一个基于hash的字典。

Redis设计

1. 采用单线程，简化了数据结构和算法的实现

2. 通过异步IO和pipelining等机制来实现高速的并发访问

3. 使用dict基础数据结构，解决了算法中的查找问题，解决了快速相应

网络模型

基于Reactor的事件驱动类型，整体分为接受请求处理器、响应处理器和应答处理器三个同步模块，每一个请求都是要经历这三个部分。

Reactor 模式也叫 Dispatcher 模式，我觉得这个名字更贴合该模式的含义，即 I/O 多路复用监听事件，收到事件后，根据事件类型分配（Dispatch）给某个进程 / 线程。

Redis集成了libevent/epoll/kqueue/select等多种事件管理机制，可以根据操作系统 版本自由选择合适的管理机制，其中libevent是最优选择的机制。

持久化

Redis是内存数据库，数据都是存储在内存中，为了避免进程退出导致数据的永久丢失，需要定期将Redis中的数据以某种形式(数据或命令)从内存保存到硬盘；当下次Redis重启时，利用持久化文件实现数据恢复。除此之外，为了进行灾难备份，可以将持久化文件拷贝到一个远程位置

过程

1. 客户端向服务端发送写操作（数据在客户端的内存中）

2. 数据库服务接收到请求的数据（数据在服务端的内存中）

3. 服务器调用write这个系统调用，将数据往磁盘上写（数据在系统内存的缓冲区中）

4. 操作系统将缓冲区中的数据转移到磁盘控制器上(数据在磁盘缓存中)

5. 磁盘控制器将数据写到磁盘的物理介质中(数据真正落到磁盘上)

RDB机制和原理

RDB是将当前进程中的数据生成快照保存到硬盘，当Redis重新启动时，可以读取快照文件恢复数据。

触发机制

save（手动触发）、bgsave（手动触发）、自动化

save（手动触发）

执行save命令期间，Redis不能处理其他命令，直到RDB过程完成为止。

执行完成后，如果存在老的RDB文件，就会用新的替换旧的，对于用户多的客户端显然不可取

bgsave（手动触发）

自动化也是采取的这种方式，手动执行该命令：

Redis进程执行fork操作创建子进程，RDB持久化过程由子进程负责，完成后自动结束。阻塞只发生在fork阶段，一般时间非常短。具体流程如下：

1. 执行besave命令，父进程检查是否有需要运行的子进程，有的话就直接返回（类似于函数返回值）

1. 父进程执行fork创建子进程，fork过程中父进程可能会发生堵塞，通过info status命令可以查看latest_fork_usec选项，可以获取最近一个fork操作的耗时，单位为微秒

1. fork完成后，bgsave命令返回“Background saving started”信息并不再阻塞父进程，可以继续响应其他命令

1. 子进程创建RDB文件，根据父进程内存生成临时快照文件，完成后 对原有文件进行原子替换。执行lastsave命令可以获取最后一次生成RDB的 时间，对应info统计的rdb_last_save_time选项

1. 进程发送信号给父进程表示完成，父进程更新统计信息

自动化

1. 使用save相关配置，如“save m n”。表示m秒内数据集存在n次修改 时，自动触发bgsave（原理图见上图）。

2. 如果从节点执行全量复制操作，主节点自动执行bgsave生成RDB文件并发送给从节点

3. 执行debug reload命令重新加载Redis时，也会自动触发save操作。

4. 默认情况下执行shutdown命令时，如果没有开启AOF持久化功能则 自动执行bgsave。

AOF机制和原理

AOF（append only file）将Redis执行的每次写命令(读请求不记录到文件中）记录到单独的日志文件中（有点像MySQL的binlog）；当Redis重启时再次执行AOF文件中的命令来恢复数据

说白了就是一个存储之前操作的地方，方便重启后可以通过之前的操作复原

Redis服务器默认开启RDB，关闭AOF；要开启AOF，需要在配置文件中配置：appendonly yes

工作流程

命令写入 （append）、文件同步（sync）、文件重写（rewrite）、重启加载 （load）,流程图如下：

1. 所有的写入命令会追加到aof_buf（缓冲区）中。

2. AOF缓冲区根据对应的策略向硬盘做同步操作。

3. 随着AOF文件越来越大，需要定期对AOF文件进行重写，达到压缩的目的。

AOF命令追加（append）

Redis先将写命令追加到缓冲区，而不是直接写入文件，主要是为了避免每次有写命令都直接写入硬盘，导致硬盘IO成为Redis负载的瓶颈。（写命令都攒一起，最后一起写）

AOF文件写入(write)和文件同步(sync)

为了提高文件写入效率，在现代操作系统中，当用户调用write函数将数据写入文件时，操作系统通常会将数据暂存到一个内存缓冲区里，当缓冲区被填满或超过了指定时限后，才真正将缓冲区的数据写入到硬盘里。这样的操作虽然提高了效率，但也带来了安全问题：如果计算机停机，内存缓冲区中的数据会丢失；因此系统同时提供了fsync、fdatasync等同步函数，可以强制操作系统立刻将缓冲区中的数据写入到硬盘里，从而确保数据的安全性。

两种持久化方式的对比

RDB的优缺点

RDB优点

1. RDB是一个紧凑压缩的二进制文件，代表Redis在某个时间点上的数据 快照。非常适用于备份，全量复制等场景。比如每6小时执行bgsave备份， 并把RDB文件拷贝到远程机器或者文件系统中（如hdfs），用于灾难恢复

2. Redis加载RDB恢复数据远远快于AOF的方式

3. 如果对于完整性要求不高，可以考虑RDB

4. 生产环境可以定期将RDB文件备份，用于恢复数据

RDB缺点

1. RDB方式数据没办法做到实时持久化/秒级持久化。生成快照数据属于重量级操作，频繁执行成本过高

2. RDB文件使用特定二进制格式保存，Redis版本演进过程中有多个格式 的RDB版本，存在老版本Redis服务无法兼容新版RDB格式的问题

3. 需要一定的时间间隔持久化时间，如果redis意外宕机了，最后一段时间的修改数据就没有了

4. 针对RDB不适合实时持久化的问题，Redis提供了AOF持久化方式来解决

AOF的优缺点

AOF的优点

1. AOF可以更好的保护数据不丢失，一般AOF会每隔1秒，通过一个后台线程执行一次fsync操作，最多丢失1秒钟的数据

2. AOF日志文件没有任何磁盘寻址的开销，写入性能非常高，文件不容易破损

3. AOF日志文件即使过大的时候，出现后台重写操作，也不会影响客户端的读写

4. AOF日志文件的命令通过非常可读的方式进行记录，这个特性非常适合做灾难性的误删除的紧急恢复。比如某人不小心用flushall命令清空了所有数据，只要这个时候后台rewrite还没有发生，那么就可以立即拷贝AOF文件，将最后一条flushall命令给删了，然后再将该AOF文件放回去，就可以通过恢复机制，自动恢复所有数据

AOF的缺点

1. 对于同一份数据来说，AOF日志文件通常比RDB数据快照文件更大

2. AOF开启后，支持的写QPS会比RDB支持的写QPS低，因为AOF一般会配置成每秒fsync一次日志文件，当然，每秒一次fsync，性能也还是很高的

故障恢复

在redis宕机后，如果有持久化文件，可以通过加载持久化文件恢复数据

加载RDB恢复数据

RDB文件的载入工作是在服务器启动时自动执行的，并没有专门的命令。但是由于AOF的优先级更高，因此当AOF开启时，Redis会优先载入AOF文件来恢复数据；只有当AOF关闭时，才会在Redis服务器启动时检测RDB文件，并自动载入。服务器载入RDB文件期间处于阻塞状态，直到载入完成为止。

Redis载入RDB文件时，会对RDB文件进行校验，如果文件损坏，则日志中会打印错误，Redis启动失败。

加载AOF恢复数据

如果aof文件有错位（被改了内容），redis会启动不起来，需要修复aof文件，可以用redis自带的redis-check-aof来修复aof文件

哨兵模式

概述

当主服务器宕机后，手动将一台从服务器切换为主服务器，需要人工处理，费时费力并且响应速度慢，会造成一段时间内服务不可用，所以引入哨兵模式，自动处理

核心功能

哨兵的核心功能是主节点的自动故障转移，哨兵是一个独立的进程，作为进程，它会独立运行。其原理是哨兵通过发送命令，等待Redis服务器响应，从而监控运行的多个Redis实例。

当哨兵检测的主机挂了，会选举一个从机当主机，原本的主机再次启动后会变成从机

下面是Redis官方文档对于哨兵功能的描述：

1. 监控（Monitoring）：哨兵会不断地检查主节点和从节点是否运作正常。

2. 自动故障转移（Automatic failover）：当主节点不能正常工作时，哨兵会开始自动故障转移操作，它会将失效主节点的其中一个从节点升级为新的主节点，并让其他从节点改为复制新的主节点。

3. 配置提供者（Configuration provider）：客户端在初始化时，通过连接哨兵来获得当前Redis服务的主节点地址。

4. 通知（Notification）：哨兵可以将故障转移的结果发送给客户端。

布隆过滤器

可以理解为一个不怎么精确的 set 结构，当你使用它的 contains 方法判断某个对象是否存在时，它可能会误判。但是布隆过滤器也不是特别不精确，只要参数设置的合理，它的精确度可以控制的相对足够精确，只会有小小的误判概率。

当布隆过滤器说某个值存在时，这个值可能不存在；当它说不存在时，那就肯定不存在。打个比方，当它说不认识你时，肯定就不认识；当它说见过你时，可能根本就没见过面，不过因为你的脸跟它认识的人中某脸比较相似 (某些熟脸的系数组合)，所以误判以前见过你。

添加数据

如下图所示：当要向布隆过滤器中添加一个元素key时，我们通过多个hash函数，算出一个值，然后将这个值所在的方格置为1。

比如，下图hash1(key)=1，那么在第2个格子将0变为1（数组是从0开始计数的），hash2(key)=7，那么将第8个格子置位1，依次类推。

判断数据存在

很简单，我们只需要将这个新的数据通过上面自定义的几个哈希函数，分别算出各个值，然后看其对应的地方是否都是1，如果存在一个不是1的情况，那么我们可以说，该新数据一定不存在于这个布隆过滤器中。

反过来说，如果通过哈希函数算出来的值，对应的地方都是1，那么我们能够肯定的得出：这个数据一定存在于这个布隆过滤器中吗？

答案是否定的，因为多个不同的数据通过hash函数算出来的结果是会有重复的，所以会存在某个位置是别的数据通过hash函数置为的1。

我们可以得到一个结论：布隆过滤器可以判断某个数据一定不存在，但是无法判断一定存在。

参考文章：

原文链接：https://blog.csdn.net/coldstarry/article/details/122777533

【狂神说Java】Redis最新超详细版教程通俗易懂_哔哩哔哩_bilibili

深入学习Redis（2）：持久化 - 编程迷思 - 博客园

应用 5：层峦叠嶂——redis布隆过滤器

Redis 之布隆过滤器