京公网安备11010502063487号Redis 重启之后多久能服务?答案取决于两件事:要加载多少数据,以及数据是以什么格式落在磁盘上。这篇在 10 万到 200 万个 key 上,实测三种持久化配置的重启耗时,再看 AOF 增量没重写时会拖多久。
key 数 | RDB | AOF(RDB base) | AOF(纯命令) 100000 | 0.07 s | 0.08 s | 0.12 s 500000 | 0.24 s | 0.25 s | 0.41 s 1000000 | 0.47 s | 0.46 s | 0.85 s 2000000 | 0.95 s | 0.95 s | 1.74 s
加载耗时随 key 数近似线性:RDB 200 万个 key 0.95 s,约每百万 0.48 s。AOF 用 RDB 作 base 时和 RDB 几乎一样;纯命令的 AOF 每百万 key 约 0.87 s,慢约 82%——它要解析并执行每一条命令。本机的 SSD、CPU 与 key/value 大小决定了这些绝对值,只有「线性」和「相对比例」可以迁移到别的机器。
key 数 | RDB | AOF(RDB base) | AOF(纯命令) 100000 | 7.8 | 7.8 | 10.1 500000 | 39.4 | 39.4 | 50.9 1000000 | 78.9 | 78.9 | 101.9 2000000 | 158.9 | 158.9 | 204.9
RDB 与 AOF(RDB base)的文件大小完全一样(同一份 RDB);纯命令 AOF 大约多 29%。(value 是随机字符串,几乎不可压缩;value 重复度高时 RDB 会小得多。)
追加命令数 incr 大小 MB 重启总耗时
0 0.0 0.47 s
200000 13.2 0.66 s
1000000 66.8 1.39 s
3000000 202.8 3.31 sbase 固定是 100 万个 key(重启 0.47 s),之后追加的命令不重写,重启时要逐条回放:20 万条(13 MB incr)多 0.18 s,100 万条多 0.91 s,300 万条(203 MB)多 2.84 s,每百万条约 0.93 s。这里的增量都是简单的 SET;对同一批 key 的反复修改,回放的条数远多于最终的 key 数。所以自动重写(第 59 篇)不只是省磁盘,也是在控制重启时间。
重启耗时只是「Redis 能服务」的一部分。真实的恢复时间还要加上:进程被外部拉起的延迟、从库场景下的复制追赶(第 54–58 篇)、客户端重连。同时,本机数据集最大只有 200 万个 key(约 160 MB),更大的数据集、更慢的磁盘、更大的 value 都会改变绝对值。