Redis 交互流程

原创于 2025-10-30 17:40:57 发布 · 772 阅读

27 ·

CC 4.0 BY-SA版权

文章标签：

#redis #交互 #数据库

Redis 专栏收录该内容

4 篇文章

订阅专栏

1 C/S 主体交互

连接处理

@startuml
autonumber
participant "server.c" as Server
participant "networking.c" as NetWorking #orange
participant "ae.c" as Ae #red

Server -> Server: aeCreateFileEvent
Server -> NetWorking: acceptTcpHandler
NetWorking -> NetWorking: acceptCommonHandler
NetWorking -> NetWorking: createClient
NetWorking -> Ae: aeCreateFileEvent
Ae -> NetWorking: readQueryFromClient

@enduml

2 持久化

Redis 支持 RDB 和 AOF 两种持久化机制，持久化功能有效地避免因进程退出造成数据丢失问题，当下次重启时利用之前持久化的文件即可实现数据恢复。

2.1 RDB

在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是行话讲的Snapshot快照，它恢复时是将快照文件直接读到内存里。

2.1.1 触发方式

手动触发：
- save 命令：阻塞当前 Redis 服务器，直到 RDB 过程完成为止，对于内存比较大的实例造成长时间阻塞，基本不采用。
- bgsave 命令：Redis 进程执行 fork 操作创建子进程，RDB 持久化过程由子进程负责，完成后自动结束。阻塞只发生在 fork 阶段，一般时间很短。
自动触发：

# Save the DB on disk:
#
#   save <seconds> <changes>
#
#   Will save the DB if both the given number of seconds and the given
#   number of write operations against the DB occurred.
#
#   In the example below the behavior will be to save:
#   after 900 sec (15 min) if at least 1 key changed
#   after 300 sec (5 min) if at least 10 keys changed
#   after 60 sec if at least 10000 keys changed
#
#   Note: you can disable saving completely by commenting out all "save" lines.
#
#   It is also possible to remove all the previously configured save
#   points by adding a save directive with a single empty string argument
#   like in the following example:
#
#   save ""
 
save 900 1
save 300 10
save 60 10000

2.1.2 持久化流程

在这里插入图片描述

2.1.3 总结

在这里插入图片描述

2.2 AOF

以日志的形式来记录每个写操作（增量保存），将Redis执行过的所有写指令记录下来(读操作不记录)，只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据。

2.2.1 持久化流程

在这里插入图片描述

客户端的请求写命令会被append追加到AOF缓冲区内；
AOF缓冲区根据AOF持久化策略[always,everysec,no]将操作sync同步到磁盘的AOF文件中；
AOF文件大小超过重写策略或手动重写时，会对AOF文件rewrite重写，压缩AOF文件容量；
Redis服务重启时，会重新load加载AOF文件中的写操作达到数据恢复的目的；

2.2.2 配置

AOF 开启配置
appendonly yes，默认不开启。AOF 文件名通过appendfilename 配置（默认是 appendonly.aof）设置。保存目录同 RDB 持久化方式一致，通过 dir配置指定。
AOF 同步频率
- appendfsync always ：始终同步，每次Redis的写入都会立刻记入日志；性能较差但数据完整性比较好
- appendfsync everysec ：每秒同步，每秒记入日志一次，如果宕机，本秒的数据可能丢失。
- appendfsync no ：redis不主动进行同步，把同步时机交给操作系统。

2.2.3 重写流程

在这里插入图片描述

bgrewriteaof触发重写，判断是否当前有bgsave或bgrewriteaof在运行，如果有，则等待该命令结束后再继续执行。
主进程fork出子进程执行重写操作，保证主进程不会阻塞。
子进程遍历redis内存中数据到临时文件，客户端的写请求同时写入aof_buf缓冲区和aof_rewrite_buf重写缓冲区保证原AOF文件完整以及新AOF文件生成期间的新的数据修改动作不会丢失。
同步处理
- 子进程写完新的AOF文件后，向主进程发信号，父进程更新统计信息。
- 主进程把aof_rewrite_buf中的数据写入到新的AOF文件。
使用新的AOF文件覆盖旧的AOF文件，完成AOF重写。

2.2.4 总结

在这里插入图片描述

2.3 启动恢复流程

在这里插入图片描述

2.4 对比

RDB持久化方式能够在指定的时间间隔能对你的数据进行快照存储
AOF持久化方式记录每次对服务器写的操作,当服务器重启的时候会重新执行这些命令来恢复原始的数据,AOF命令以redis协议追加保存每次写的操作到文件末尾.
Redis还能对AOF文件进行后台重写,使得AOF文件的体积不至于过大
只做缓存：如果你只希望你的数据在服务器运行的时候存在,你也可以不使用任何持久化方式.
同时开启两种持久化方式
在这种情况下,当redis重启的时候会优先载入AOF文件来恢复原始的数据, 因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整.
RDB的数据不实时，同时使用两者时服务器重启也只会找AOF文件。那要不要只使用AOF呢？
- 建议不要，因为RDB更适合用于备份数据库(AOF在不断变化不好备份)，快速重启，而且不会有AOF可能潜在的bug，留着作为一个万一的手段。
性能建议
- 因为RDB文件只用作后备用途，建议只在Slave上持久化RDB文件，而且只要15分钟备份一次就够了，只保留save 900 1这条规则。
- 如果使用AOF，好处是在最恶劣情况下也只会丢失不超过两秒数据，启动脚本较简单只load自己的AOF文件就可以了。
- 代价,一是带来了持续的IO，二是AOF rewrite的最后将rewrite过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的。
- 只要硬盘许可，应该尽量减少AOF rewrite的频率，AOF重写的基础大小默认值64M太小了，可以设到5G以上。默认超过原大小100%大小时重写可以改到适当的数值。