Redis数据库是以一个redisServer结构为核心的键值对数据库，其中包含一个redisDb的数组，每一个redisDb就代表一个数据库。而redisDb其本质就是一个dict字典，该结构保存了数据库所有的键值对，我们称这个结构为键空间。

Redis数据库结构

• 默认情况下Redis客户端的目标数据库是0号数据库也就是db[0]，可以通过命令设置
• redisDb结构中dict字典保存了所有的数据库字典键值对，这个结构也叫做键空间；
• blocking_keys/ready_keys用于实现BLPOP，详见BLPOP实现原理
• watched_keys用于Redis事务，详见Redis事务实现
• expires为字典过期相关（expires所指向的dict中键对象与键空间中的键对象是同一个对象，图中有两个重复键对象是为了展示方便）

服务端启动流程

• 通用配置设置
• 启动模式选择主要是判断是否是Sentinel模式启动，本流程主要是Redis服务器启动流程，Sentinel模式详见：高可用架构-Sentinel模式。
• 主要的业务逻辑是在initServer方法中，里面包含了redisServer对象的初始化，服务器状态的初始化，以及一些redis事件驱动设计的初始化工作。
• 初始化Redis服务器主要资源后则开始初始化辅助资源，如Redis4.0引进的lazy free模式，以及Redis6.0引进的I/O多线程模型，详见：Redis架构演进。
• 上述工作完成后则开始加载数据，通过RDB文件或者AOF文件加载。
• 一切准备就绪，则开始执行Redis主线程逻辑，开始处理aeEventLoop监听到的事件。

数据库的淘汰策略

缓存过期淘汰策略

详见：Redis过期策略原理及其实现

内存耗尽时的淘汰策略

Redis淘汰机制的存在是为了更好的使用内存，用一定的缓存丢失来换取内存的使用效率。当Redis内存快耗尽时，Redis会启动内存淘汰机制，将部分key清掉以腾出内存。当达到内存使用上限超过maxmemory时，可在配置文件redis.conf中指定 maxmemory-policy 的清理缓存方式。

# 配置最大内存限制 maxmemory 1000MB

# 配置淘汰策略 maxmemory-policy volatile-lru

LRU(最近最少使用)

• volatile-lru：从已设置过期时间的key中，挑选**最近最少使用(最长时间没有使用)**的key进行淘汰
• allkeys-lru：从所有key中，挑选最近最少使用的数据淘汰

LFU(最近最不经常使用)

• volatile-lfu：从已设置过期时间的key中，挑选**最近最不经常使用(使用次数最少)**的key进行淘汰
• allkeys-lfu：从所有key中，选择某段时间内内最近最不经常使用的数据淘汰

Random(随机淘汰)

• volatile-random：从已设置过期时间的key中，任意选择数据淘汰
• allkeys-random：从所有key中，任意选择数据淘汰

TTL(过期时间)

• volatile-ttl：从已设置过期时间的key中，挑选将要过期的数据淘汰
• allkeys-random：从所有key中，任意选择数据淘汰

No-Enviction(驱逐)

• noenviction（驱逐）：当达到最大内存时直接返回错误，不覆盖或逐出任何数据

持久化机制

Redis作为一个内存数据库，它将自己的数据库状态存储在内存里，所以如果不想办法将存储的内存数据库状态保存到磁盘里，那么一旦进程退出，服务器中所有的数据库状态将永久消失。为了解决这个问题，Redis提供了RDB与AOF持久化功能。通常来说，应该同时使用两种持久化方案，以保证数据安全：

• 如果数据不敏感，且可以从其他地方重新生成，可以关闭持久化
• 如果数据比较重要，且能够承受几分钟的数据丢失，比如缓存等，只需要使用RDB即可
• 如果是用做内存数据，要使用Redis的持久化，建议是RDB和AOF都开启，即混合模式
• 如果只用AOF，优先使用everysec的配置选择，因为它在可靠性和性能之间取了一个平衡

当RDB与AOF两种方式都开启时，Redis会优先使用AOF恢复数据，因为AOF保存的文件比RDB文件更完整

RDB模式（内存快照）

RDB（Redis Database Backup File，Redis数据备份文件）持久化方式：是指用数据集快照的方式记录 Redis 数据库的所有键值对，在某个时间点将数据写入一个临时文件，持久化结束后，用这个临时文件替换上次持久化的文件，达到数据恢复。

自动间隔性保存

自动保存基于serverCron函数（每间隔100毫秒执行一次）该函数会检查自动保存配置saveparams看是否满足条件，若满足则执行BGSAVE命令。

RDB文件结构

RDB文件采用二进制存储，如下是一个详细的文件结构图

持久化流程

模式优缺点

优点

• RDB快照是一个压缩过的非常紧凑的文件。保存着某个时间点的数据集，适合做数据的备份，灾难恢复
• 在使用BISAVE保存RDB文件时，服务器进程只需要fork一个子进程来完成RDB文件创建，父进程不会阻塞可以继续处理客户端的请求
• 恢复大数据集的时候比AOF快

缺点

• RDB的数据安全性是不如AOF的，保存整个数据集的过程是比繁重的，备份的频率不能太频繁，因此在两次备份的间隔期间服务宕机则会导致期间数据丢失
• Redis数据集较大时，fork的子进程要完成快照会比较耗CPU、耗时长

AOF模式（日志追加）

AOF（Append Only File，追加日志文件）持久化方式：是指所有的命令行记录以 Redis 命令请求协议的格式完全持久化存储保存为 aof 文件。Redis 是先执行命令，把数据写入内存，然后才记录日志。因为该模式是只追加的方式，所以没有任何磁盘寻址的开销，所以很快，有点像 Mysql 中的binlog，AOF更适合做热备。

持久化流程

数据加载

文件加载步骤

• 创建一个不带网络连接的伪客户端
• 从 AOF 文件中分析并读取出一条写命令
• 使用伪客户端执行被读出的写命令
• 循环执行中间步骤，直到 AOF 文件中的所有写命令都被处理完毕为止

文件重写

为何需要文件重写

• 为了解决 AOF 文件体积膨胀的问题
• 通过重写创建一个新的 AOF 文件来替代现有的 AOF 文件，新的 AOF 文件不会包含任何浪费空间的冗余命令

文件重写的实现原理

• 不需要对现有的 AOF 文件进行任何操作
• 从数据库中直接读取键现在的值
• 用一条命令记录键值对，从而代替之前记录这个键值对的多条命令

模式优缺点

优点

• 数据更完整，安全性更高，秒级数据丢失（取决fsync策略，如果是everysec，最多丢失1秒的数据）
• AOF文件是一个只进行追加的日志文件，且写入操作是以Redis协议的格式保存的，内容是可读的，适合误删紧急恢复

缺点

• 对于相同的数据集，AOF文件的体积要大于RDB文件，数据恢复也会比较慢
• 根据所使用的fsync策略，AOF的速度可能会慢于RDB。 不过在一般情况下，每秒fsync的性能依然非常高

事件实现

Redis服务器是一个事件驱动的程序，有以下两类事件：

• 文件事件：Redis服务器通过套接字与客户端或者其他的Redis服务器连接，而文件事件就是服务器套接字操作的抽象。与客户端或者其它服务器通信产生相应的文件事件，服务器通过监听处理这些事件来完成一系列的网络通信操作。
• 时间事件：Redis服务器中的一些操作（如serverCron函数）需要在给定的时间点执行，而时间事件就是服务器对这类定时操作的抽象。

文件事件

Redis基于Reactor模式开发了自己的网络事件处理器，利用IO多路复用程序来监听套接字，当监听到连接应答、读取、写入、关闭等操作是，就会调用对应关联的事件处理器来处理。

文件事件处理器结构

文件事件执行过程

时间事件

Redis的时间事件分为两种，定时事件：让一个函数在指定的时间之后执行一次；周期性任务：让一个函数每间隔指定时间执行一次；时间事件是基于serverCron函数实现，该函数主要对服务器自身资源和状态检查和调整，确保服务器的长期、稳定运行，具体工作详见本文中事件的调度执行。

事件的调度执行

• apiPoll函数阻塞并等待文件事件产生，该方法避免了服务器对时间事件进行频繁的轮询，该函数有阻塞过期，时间到达立即返回
• 文件事件的到达是随机的，随着文件事件的执行，时间事件的到达时间开始接近，当时间事件执行时间到达后服务器开始执行时间事件
• 文件事件与时间事件都是同步、有序、原子的执行的，整个过程尽量减少阻塞时间，耗时相对久的函数都会设置run_with_period（最大运行时长），当执行耗时比较久的函数时，Redis会采用子线程或子进程的方式来异步处理，比如持久化操作。
• Redis 6.0对processEvents流程进行了优化，引入多线程模型提升eventLoop 处理效率，详见：Redis多线程处理模型

Redis客户端

Redis服务器是一个典型的一对多服务器程序：一个服务器可以与多个客户端建立网络连接。每个客户端可以向服务器发送请求，服务端收到请求处理并向客户端返回命令回复。

客户端结构

客户端的创建与关闭

客户端创建：

如果客户端是通过网络连接与服务器连接的普通客户端，服务器通过调用连接事件的处理器，为客户端创建一个redisClient，并将这个新的客户端添加到redisServer中的clients链表的末尾。

客户端关闭场景：

• 客户端因为自身原因进程退出或者网络抖动与服务器断连。
• 客户端向服务器发送了不合法的命令。
• 执行CLIENT KILL命令。
• 设置了客户端超时间，客户端空转时间超过了超时时间。
• 客户端发送的命令请求超过了输入缓冲区大小限制。
• 发给客户端的命令回复超过了输出缓冲区的大小限制。

伪客户端

执行Lua脚本的伪客户端

Lua客户端随着服务器的启动而创建，其伴随着整个服务器的生命周期，只有服务器关闭该客户端才会退出。

载入AOF文件的伪客户端

服务器在载入AOF文件时，会创建用于执行AOF文件包含的Redis命令的伪客户端，当文件载入完成后该客户端将被关闭。具体过程详见本文 持久化机制->AOF模式

以上就是Redis单机数据库介绍，如果各位还想了解更多，欢迎转发评论+关注，Redis图解系列专栏持续更新中。