上一篇【第32篇】AOF重写——日志文件无限增长怎么办下一篇【第34篇】Redis事件驱动模型——epoll/select/kqueue的多路复用前两篇文章我们分别深入剖析了RDB和AOF两种持久化机制。现在到了最让人纠结的时刻生产环境到底选哪个这个问题就像在方便面和外卖之间做选择——方便面快但不够好外卖好但贵且慢。万一Redis 4.0告诉你还有一种方便面外卖的组合套餐呢这篇文章我们就来一场持久化方案的大横评帮你根据实际业务场景找到最合适的选择。三种方案一图看懂┌──────────────────────────────────────────────────────────┐ │ Redis持久化方案全景图 │ │ │ │ ┌──────────┐ ┌──────────┐ ┌───────────────────┐ │ │ │ RDB │ │ AOF │ │ RDBAOF 混合持久化 │ │ │ │ (快照) │ │ (日志) │ │ (Redis 4.0) │ │ │ └────┬─────┘ └────┬─────┘ └────────┬──────────┘ │ │ │ │ │ │ │ 定时全量 记录所有 AOF文件开头是 │ │ 内存快照 写命令 RDB快照 结尾 │ │ 是增量AOF命令 │ │ │ │ 恢复快 数据安全 兼顾速度和安全 │ │ 丢数据多 文件大 最佳平衡方案 │ └──────────────────────────────────────────────────────────┘RDB方案——快照的利与弊优势1. 文件紧凑、体积小RDB文件是经过压缩的二进制格式存储的是某一时刻的内存数据结构。对于相同数据量RDB文件通常只有AOF文件的几分之一甚至十几分之一。同样的数据 RDB文件大小 50MB AOF文件大小 500MB 压缩比10:12. 恢复速度极快RDB文件直接载入内存不需要逐条解析和执行命令。对于GB级别的数据RDB恢复通常只需要几秒到几十秒。数据恢复速度对比1GB数据 RDB恢复 ────────────────► 5~10秒 AOF恢复 ──────────────────────────────────────────► 30~120秒3. 适合备份和全量传输RDB文件是一个自包含的完整快照非常适合定期备份每天/每周备份一次保留多个版本全量数据同步主从复制、数据迁移灾难恢复拷贝RDB文件到另一台机器即可恢复劣势1. 数据安全性差RDB是定时快照两次快照之间的数据一旦服务器崩溃就丢失了。save 900 1 # 15分钟内有1次修改就保存 save 300 10 # 5分钟内有10次修改就保存 save 60 10000 # 1分钟内有10000次修改就保存最坏情况下配置了save 900 1可能丢失15分钟的数据。2. 大实例fork耗时BGSAVE和BGREWRITEAOF都需要fork子进程。虽然Linux有写时复制COW优化但如果Redis实例使用了数十GB内存fork操作本身仍然需要数百毫秒甚至数秒这段时间内Redis是完全阻塞的。适用场景数据丢失容忍度较高的纯缓存场景需要定期备份进行灾难恢复的场景主从复制中的全量同步数据量不大且重启频率低的场景AOF方案——日志的利与弊优势1. 数据安全性高使用appendfsync everysec最多丢失1秒数据。对于大多数业务来说这已经足够安全了。2. 日志可读性强AOF文件是纯文本格式RESP协议可以直接阅读、分析、甚至手动修改。3. 兼容性好即使不同版本的RedisAOF文件也可以在一定程度上兼容虽然新版本可能使用了新的命令格式。劣势1. 文件体积大AOF记录了所有写命令的完整历史包括大量冗余操作。即使有AOF重写机制文件仍然比RDB大得多。2. 恢复速度慢恢复AOF文件需要逐条读取命令、解析RESP协议、创建伪客户端、逐条执行命令——每一步都有开销。数据量越大恢复越慢。3. 重写有开销AOF重写虽然不阻塞主进程但fork操作和COW仍然会带来延迟抖动和额外内存消耗。适用场景数据安全性要求高的业务最多丢失1秒数据需要审计数据变更历史的场景对恢复速度要求不苛刻的场景RDBAOF混合持久化——鱼和熊掌兼得Redis 4.0引入了混合持久化这是目前推荐的方案。开启后混合持久化的AOF文件结构 ┌────────────────────────────────────────┐ │ RDB格式的全量快照紧凑、体积小 │ ← 载入快 │ ┌──────────────────────────────────┐ │ │ │ REDIS0009 ... (RDB二进制格式) │ │ │ │ 包含所有键值对的最终状态 │ │ │ └──────────────────────────────────┘ │ ├────────────────────────────────────────┤ │ AOF格式的增量命令RESP文本格式 │ ← 数据安全 │ ┌──────────────────────────────────┐ │ │ │ SET key1 new_value │ │ │ │ INCR counter │ │ │ │ LPUSH mylist x y z │ │ │ │ ... (重写后产生的新命令) │ │ │ └──────────────────────────────────┘ │ └────────────────────────────────────────┘配置方式# 开启AOF appendonly yes # 开启混合持久化默认yesRedis 4.0 aof-use-rdb-preamble yes混合持久化的工作原理AOF重写触发 │ ▼ 子进程遍历内存 │ ├── 以RDB格式写入所有键值对紧凑、快速 │ SET k1 v1 → RDB二进制格式 │ LPUSH k2 a b c → RDB二进制格式 │ ... │ ├── RDB部分写入完毕 │ └── 切换为AOF格式 将重写期间的增量命令以RESP格式追加 SET k3 new → *3\r\n$3\r\nSET\r\n... INCR counter → *2\r\n$4\r\nINCR\r\n...混合持久化的优势维度RDBAOFRDBAOF混合数据安全性差丢分钟级好丢1秒好丢1秒恢复速度最快慢快文件体积最小大较小CPU开销低定时保存中每秒fsync重写中内存开销中fork中fork双缓冲区中混合持久化巧妙地利用了RDB的快和AOF的安全取长补短是目前生产环境的最佳选择。四种场景的方案选型建议场景一纯缓存数据可以全量丢失# 完全关闭持久化 appendonly no save # 或者不配置save参数适用用户会话缓存、页面缓存、排行榜等。Redis挂了没关系数据可以从数据库重新加载。场景二少量数据丢失可接受# 只用RDB appendonly no save 900 1 save 300 10 save 60 10000适用消息队列、计数器等。最多丢失几分钟数据业务影响可控。场景三最多丢失1秒数据# 只用AOF appendonly yes appendfsync everysec适用订单数据、配置信息、业务关键数据。场景四数据最安全且恢复要快推荐# RDB AOF混合持久化 appendonly yes aof-use-rdb-preamble yes appendfsync everysec save 900 1 save 300 10 save 60 10000适用大多数生产环境。兼顾数据安全性和恢复速度。生产环境持久化配置最佳实践以下是一份经过生产验证的Redis持久化配置模板# 持久化配置 # 文件保存目录 dir /data/redis # AOF配置 appendonly yes appendfilename appendonly.aof appendfsync everysec # 混合持久化Redis 4.0 aof-use-rdb-preamble yes # AOF重写阈值 auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 128mb # 重写期间是否暂停fsync一般保持no no-appendfsync-on-rewrite no # RDB配置 save 900 1 save 300 10 save 60 10000 # RDB文件名 dbfilename dump.rdb # bgsave失败时是否停止写入 stop-writes-on-bgsave-error yes # 是否压缩RDB rdbcompression yes # RDB文件是否校验 rdbchecksum yes # 安全配置 # 禁用危险命令 rename-command FLUSHALL rename-command FLUSHDB # 文件管理 # 可以通过外部脚本定期备份RDB文件 # 例如每天凌晨2点执行一次 bgsave并将dump.rdb复制到备份目录持久化相关的监控指标通过INFO persistence可以获取丰富的持久化状态信息127.0.0.1:6379INFO persistence# Persistenceloading:0 rdb_changes_since_last_save:152# 距上次RDB保存的修改次数rdb_bgsave_in_progress:0# bgsave是否在进行rdb_last_save_time:1700000000# 上次RDB保存的Unix时间戳rdb_last_bgsave_status:ok# 上次bgsave的状态rdb_last_bgsave_time_sec:2# 上次bgsave耗时秒rdb_current_size:5242880# 当前RDB文件大小rdb_last_cow_size:2097152# 上次bgsave的COW大小aof_enabled:1# AOF是否开启aof_rewrite_in_progress:0# AOF重写是否在进行aof_rewrite_scheduled:0# 是否有计划中的重写aof_last_bgrewrite_status:ok# 上次AOF重写状态aof_last_write_status:ok# 上次AOF写入状态aof_current_size:10485760# 当前AOF文件大小aof_base_size:5242880# 上次重写后AOF文件大小aof_pending_rewrite:0# 是否需要重写aof_buffer_length:0# AOF缓冲区大小aof_rewrite_buffer_length:0# AOF重写缓冲区大小aof_pending_bio_fsync:0# 待执行的fsync数量aof_delayed_fsync:0# 延迟的fsync次数重点关注这些指标指标含义告警阈值rdb_last_bgsave_status上次bgsave结果非okaof_last_bgrewrite_status上次AOF重写结果非okaof_delayed_fsync延迟fsync次数 0说明IO压力大rdb_last_bgsave_time_secbgsave耗时 5秒可能有影响rdb_last_cow_sizeCOW内存大小接近可用内存持久化与Redis集群Sentinel模式在Redis Sentinel哨兵模式下主节点必须开启持久化。原因很简单主节点挂了Sentinel会选举一个从节点提升为主节点。如果主节点没有持久化故障转移后从节点会丢失主节点崩溃前的那部分数据。# Sentinel推荐配置主节点开启混合持久化 appendonly yes aof-use-rdb-preamble yes appendfsync everysecCluster模式在Redis Cluster模式下每个分片Shard的主节点都应该开启持久化。从节点可以不开启因为它是主节点的副本但开启也无妨——故障转移时从节点变主节点时能更快地恢复。Redis Cluster 持久化建议 Master-1 (主) → 开启混合持久化 Slave-1 (从) → 开启混合持久化推荐 Master-2 (主) → 开启混合持久化 Slave-2 (从) → 开启混合持久化推荐 ...数据恢复演练——不要等到灾难来临时才后悔无论你选择了哪种持久化方案定期做数据恢复演练都是必不可少的。# 恢复演练脚本示例#!/bin/bash# 1. 备份当前数据cp/data/redis/dump.rdb /backup/dump_$(date%Y%m%d_%H%M%S).rdbcp/data/redis/appendonly.aof /backup/aof_$(date%Y%m%d_%H%M%S).aof# 2. 停止Redisredis-cli SHUTDOWN NOSAVE# 3. 使用备份文件启动# 方法A用RDB恢复redis-server--dir/data/redis--dbfilenamedump_20240101.rdb--port6380# 方法B用AOF恢复需要确保appendonly yesredis-server--dir/data/redis--appendonlyyes--appendfilenameappendonly_20240101.aof--port6380# 4. 验证数据完整性redis-cli-p6380DBSIZE redis-cli-p6380--scan--patternuser:*|wc-l# 5. 恢复正常服务redis-cli-p6380SHUTDOWN NOSAVE redis-server /etc/redis/redis.conf踩坑提示演练时注意以下几点在测试环境操作不要在生产环境直接搞记录恢复耗时评估是否符合SLA要求验证数据完整性记录数是否一致关键key是否存在记录恢复过程中遇到的问题更新恢复手册三种方案完整对比对比维度纯RDB纯AOFRDBAOF混合数据安全性低丢分钟级高丢1秒高丢1秒恢复速度快秒级慢分钟级快秒级文件大小小压缩后大文本日志较小CPU开销低定时中每秒fsync中内存开销中fork中fork双缓冲区中对性能影响小中fsync重写中配置复杂度简单中等中等文件可读性差二进制好RESP文本部分可读适用版本所有版本所有版本Redis 4.0推荐度缓存场景数据安全要求高大多数生产环境总结选择持久化方案没有银弹关键是理解业务需求纯缓存→ 关闭持久化简单粗暴可接受丢失几分钟→ RDB足够最多丢1秒数据→ AOF everysec既要安全又要快→ RDBAOF混合持久化Redis 4.0不管选哪种方案都要做好监控和恢复演练。毕竟持久化不是目的数据能恢复才是目的。接下来我们暂时告别持久化的话题进入Redis内部的发动机——事件驱动模型。Redis究竟是怎么用单线程处理数万并发连接的下一篇文章《Redis事件驱动模型——epoll/select/kqueue的多路复用》为你揭秘。上一篇【第32篇】AOF重写——日志文件无限增长怎么办下一篇【第34篇】# Redis事件驱动模型——epoll/select/kqueue的多路复用
【Redis从入门到精通】第33篇：RDB vs AOF vs RDB+AOF混合——持久化方案怎么选
上一篇【第32篇】AOF重写——日志文件无限增长怎么办下一篇【第34篇】Redis事件驱动模型——epoll/select/kqueue的多路复用前两篇文章我们分别深入剖析了RDB和AOF两种持久化机制。现在到了最让人纠结的时刻生产环境到底选哪个这个问题就像在方便面和外卖之间做选择——方便面快但不够好外卖好但贵且慢。万一Redis 4.0告诉你还有一种方便面外卖的组合套餐呢这篇文章我们就来一场持久化方案的大横评帮你根据实际业务场景找到最合适的选择。三种方案一图看懂┌──────────────────────────────────────────────────────────┐ │ Redis持久化方案全景图 │ │ │ │ ┌──────────┐ ┌──────────┐ ┌───────────────────┐ │ │ │ RDB │ │ AOF │ │ RDBAOF 混合持久化 │ │ │ │ (快照) │ │ (日志) │ │ (Redis 4.0) │ │ │ └────┬─────┘ └────┬─────┘ └────────┬──────────┘ │ │ │ │ │ │ │ 定时全量 记录所有 AOF文件开头是 │ │ 内存快照 写命令 RDB快照 结尾 │ │ 是增量AOF命令 │ │ │ │ 恢复快 数据安全 兼顾速度和安全 │ │ 丢数据多 文件大 最佳平衡方案 │ └──────────────────────────────────────────────────────────┘RDB方案——快照的利与弊优势1. 文件紧凑、体积小RDB文件是经过压缩的二进制格式存储的是某一时刻的内存数据结构。对于相同数据量RDB文件通常只有AOF文件的几分之一甚至十几分之一。同样的数据 RDB文件大小 50MB AOF文件大小 500MB 压缩比10:12. 恢复速度极快RDB文件直接载入内存不需要逐条解析和执行命令。对于GB级别的数据RDB恢复通常只需要几秒到几十秒。数据恢复速度对比1GB数据 RDB恢复 ────────────────► 5~10秒 AOF恢复 ──────────────────────────────────────────► 30~120秒3. 适合备份和全量传输RDB文件是一个自包含的完整快照非常适合定期备份每天/每周备份一次保留多个版本全量数据同步主从复制、数据迁移灾难恢复拷贝RDB文件到另一台机器即可恢复劣势1. 数据安全性差RDB是定时快照两次快照之间的数据一旦服务器崩溃就丢失了。save 900 1 # 15分钟内有1次修改就保存 save 300 10 # 5分钟内有10次修改就保存 save 60 10000 # 1分钟内有10000次修改就保存最坏情况下配置了save 900 1可能丢失15分钟的数据。2. 大实例fork耗时BGSAVE和BGREWRITEAOF都需要fork子进程。虽然Linux有写时复制COW优化但如果Redis实例使用了数十GB内存fork操作本身仍然需要数百毫秒甚至数秒这段时间内Redis是完全阻塞的。适用场景数据丢失容忍度较高的纯缓存场景需要定期备份进行灾难恢复的场景主从复制中的全量同步数据量不大且重启频率低的场景AOF方案——日志的利与弊优势1. 数据安全性高使用appendfsync everysec最多丢失1秒数据。对于大多数业务来说这已经足够安全了。2. 日志可读性强AOF文件是纯文本格式RESP协议可以直接阅读、分析、甚至手动修改。3. 兼容性好即使不同版本的RedisAOF文件也可以在一定程度上兼容虽然新版本可能使用了新的命令格式。劣势1. 文件体积大AOF记录了所有写命令的完整历史包括大量冗余操作。即使有AOF重写机制文件仍然比RDB大得多。2. 恢复速度慢恢复AOF文件需要逐条读取命令、解析RESP协议、创建伪客户端、逐条执行命令——每一步都有开销。数据量越大恢复越慢。3. 重写有开销AOF重写虽然不阻塞主进程但fork操作和COW仍然会带来延迟抖动和额外内存消耗。适用场景数据安全性要求高的业务最多丢失1秒数据需要审计数据变更历史的场景对恢复速度要求不苛刻的场景RDBAOF混合持久化——鱼和熊掌兼得Redis 4.0引入了混合持久化这是目前推荐的方案。开启后混合持久化的AOF文件结构 ┌────────────────────────────────────────┐ │ RDB格式的全量快照紧凑、体积小 │ ← 载入快 │ ┌──────────────────────────────────┐ │ │ │ REDIS0009 ... (RDB二进制格式) │ │ │ │ 包含所有键值对的最终状态 │ │ │ └──────────────────────────────────┘ │ ├────────────────────────────────────────┤ │ AOF格式的增量命令RESP文本格式 │ ← 数据安全 │ ┌──────────────────────────────────┐ │ │ │ SET key1 new_value │ │ │ │ INCR counter │ │ │ │ LPUSH mylist x y z │ │ │ │ ... (重写后产生的新命令) │ │ │ └──────────────────────────────────┘ │ └────────────────────────────────────────┘配置方式# 开启AOF appendonly yes # 开启混合持久化默认yesRedis 4.0 aof-use-rdb-preamble yes混合持久化的工作原理AOF重写触发 │ ▼ 子进程遍历内存 │ ├── 以RDB格式写入所有键值对紧凑、快速 │ SET k1 v1 → RDB二进制格式 │ LPUSH k2 a b c → RDB二进制格式 │ ... │ ├── RDB部分写入完毕 │ └── 切换为AOF格式 将重写期间的增量命令以RESP格式追加 SET k3 new → *3\r\n$3\r\nSET\r\n... INCR counter → *2\r\n$4\r\nINCR\r\n...混合持久化的优势维度RDBAOFRDBAOF混合数据安全性差丢分钟级好丢1秒好丢1秒恢复速度最快慢快文件体积最小大较小CPU开销低定时保存中每秒fsync重写中内存开销中fork中fork双缓冲区中混合持久化巧妙地利用了RDB的快和AOF的安全取长补短是目前生产环境的最佳选择。四种场景的方案选型建议场景一纯缓存数据可以全量丢失# 完全关闭持久化 appendonly no save # 或者不配置save参数适用用户会话缓存、页面缓存、排行榜等。Redis挂了没关系数据可以从数据库重新加载。场景二少量数据丢失可接受# 只用RDB appendonly no save 900 1 save 300 10 save 60 10000适用消息队列、计数器等。最多丢失几分钟数据业务影响可控。场景三最多丢失1秒数据# 只用AOF appendonly yes appendfsync everysec适用订单数据、配置信息、业务关键数据。场景四数据最安全且恢复要快推荐# RDB AOF混合持久化 appendonly yes aof-use-rdb-preamble yes appendfsync everysec save 900 1 save 300 10 save 60 10000适用大多数生产环境。兼顾数据安全性和恢复速度。生产环境持久化配置最佳实践以下是一份经过生产验证的Redis持久化配置模板# 持久化配置 # 文件保存目录 dir /data/redis # AOF配置 appendonly yes appendfilename appendonly.aof appendfsync everysec # 混合持久化Redis 4.0 aof-use-rdb-preamble yes # AOF重写阈值 auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 128mb # 重写期间是否暂停fsync一般保持no no-appendfsync-on-rewrite no # RDB配置 save 900 1 save 300 10 save 60 10000 # RDB文件名 dbfilename dump.rdb # bgsave失败时是否停止写入 stop-writes-on-bgsave-error yes # 是否压缩RDB rdbcompression yes # RDB文件是否校验 rdbchecksum yes # 安全配置 # 禁用危险命令 rename-command FLUSHALL rename-command FLUSHDB # 文件管理 # 可以通过外部脚本定期备份RDB文件 # 例如每天凌晨2点执行一次 bgsave并将dump.rdb复制到备份目录持久化相关的监控指标通过INFO persistence可以获取丰富的持久化状态信息127.0.0.1:6379INFO persistence# Persistenceloading:0 rdb_changes_since_last_save:152# 距上次RDB保存的修改次数rdb_bgsave_in_progress:0# bgsave是否在进行rdb_last_save_time:1700000000# 上次RDB保存的Unix时间戳rdb_last_bgsave_status:ok# 上次bgsave的状态rdb_last_bgsave_time_sec:2# 上次bgsave耗时秒rdb_current_size:5242880# 当前RDB文件大小rdb_last_cow_size:2097152# 上次bgsave的COW大小aof_enabled:1# AOF是否开启aof_rewrite_in_progress:0# AOF重写是否在进行aof_rewrite_scheduled:0# 是否有计划中的重写aof_last_bgrewrite_status:ok# 上次AOF重写状态aof_last_write_status:ok# 上次AOF写入状态aof_current_size:10485760# 当前AOF文件大小aof_base_size:5242880# 上次重写后AOF文件大小aof_pending_rewrite:0# 是否需要重写aof_buffer_length:0# AOF缓冲区大小aof_rewrite_buffer_length:0# AOF重写缓冲区大小aof_pending_bio_fsync:0# 待执行的fsync数量aof_delayed_fsync:0# 延迟的fsync次数重点关注这些指标指标含义告警阈值rdb_last_bgsave_status上次bgsave结果非okaof_last_bgrewrite_status上次AOF重写结果非okaof_delayed_fsync延迟fsync次数 0说明IO压力大rdb_last_bgsave_time_secbgsave耗时 5秒可能有影响rdb_last_cow_sizeCOW内存大小接近可用内存持久化与Redis集群Sentinel模式在Redis Sentinel哨兵模式下主节点必须开启持久化。原因很简单主节点挂了Sentinel会选举一个从节点提升为主节点。如果主节点没有持久化故障转移后从节点会丢失主节点崩溃前的那部分数据。# Sentinel推荐配置主节点开启混合持久化 appendonly yes aof-use-rdb-preamble yes appendfsync everysecCluster模式在Redis Cluster模式下每个分片Shard的主节点都应该开启持久化。从节点可以不开启因为它是主节点的副本但开启也无妨——故障转移时从节点变主节点时能更快地恢复。Redis Cluster 持久化建议 Master-1 (主) → 开启混合持久化 Slave-1 (从) → 开启混合持久化推荐 Master-2 (主) → 开启混合持久化 Slave-2 (从) → 开启混合持久化推荐 ...数据恢复演练——不要等到灾难来临时才后悔无论你选择了哪种持久化方案定期做数据恢复演练都是必不可少的。# 恢复演练脚本示例#!/bin/bash# 1. 备份当前数据cp/data/redis/dump.rdb /backup/dump_$(date%Y%m%d_%H%M%S).rdbcp/data/redis/appendonly.aof /backup/aof_$(date%Y%m%d_%H%M%S).aof# 2. 停止Redisredis-cli SHUTDOWN NOSAVE# 3. 使用备份文件启动# 方法A用RDB恢复redis-server--dir/data/redis--dbfilenamedump_20240101.rdb--port6380# 方法B用AOF恢复需要确保appendonly yesredis-server--dir/data/redis--appendonlyyes--appendfilenameappendonly_20240101.aof--port6380# 4. 验证数据完整性redis-cli-p6380DBSIZE redis-cli-p6380--scan--patternuser:*|wc-l# 5. 恢复正常服务redis-cli-p6380SHUTDOWN NOSAVE redis-server /etc/redis/redis.conf踩坑提示演练时注意以下几点在测试环境操作不要在生产环境直接搞记录恢复耗时评估是否符合SLA要求验证数据完整性记录数是否一致关键key是否存在记录恢复过程中遇到的问题更新恢复手册三种方案完整对比对比维度纯RDB纯AOFRDBAOF混合数据安全性低丢分钟级高丢1秒高丢1秒恢复速度快秒级慢分钟级快秒级文件大小小压缩后大文本日志较小CPU开销低定时中每秒fsync中内存开销中fork中fork双缓冲区中对性能影响小中fsync重写中配置复杂度简单中等中等文件可读性差二进制好RESP文本部分可读适用版本所有版本所有版本Redis 4.0推荐度缓存场景数据安全要求高大多数生产环境总结选择持久化方案没有银弹关键是理解业务需求纯缓存→ 关闭持久化简单粗暴可接受丢失几分钟→ RDB足够最多丢1秒数据→ AOF everysec既要安全又要快→ RDBAOF混合持久化Redis 4.0不管选哪种方案都要做好监控和恢复演练。毕竟持久化不是目的数据能恢复才是目的。接下来我们暂时告别持久化的话题进入Redis内部的发动机——事件驱动模型。Redis究竟是怎么用单线程处理数万并发连接的下一篇文章《Redis事件驱动模型——epoll/select/kqueue的多路复用》为你揭秘。上一篇【第32篇】AOF重写——日志文件无限增长怎么办下一篇【第34篇】# Redis事件驱动模型——epoll/select/kqueue的多路复用
