bgsave不阻塞redis主线程，因其fork后由子进程独立完成rdb生成，主线程立即恢复服务；卡顿仅发生在fork阶段，大内存实例页表复制开销显著。
RDB持久化不会阻塞主线程，但fork阶段会短暂卡顿；真正耗时的是子进程写磁盘，而它和主线程完全无关。
为什么bgsave不阻塞Redis主线程
根本原因是bgsave调用fork创建子进程后，所有RDB文件生成工作都由子进程独立完成。主线程（父进程）在fork返回后立刻恢复处理客户端请求。
常见错误现象：监控看到bgsave执行期间延迟突增，误以为是RDB写盘拖慢了服务——其实更可能是fork本身耗时过长，尤其当Redis内存占用大（比如>10GB）时，内核复制页表项开销显著。
-
fork不是复制数据，而是复制虚拟内存映射，但页表项数量与Redis实际内存使用量正相关 - Linux内核对大内存进程的
fork优化有限，20GB实例的fork可能卡住几十毫秒 - 若
stop-writes-on-bgsave-error yes且fork失败（如OOM Killer干掉进程），Redis会拒绝写入
写时复制（COW）如何保证快照一致性
子进程启动后，父子进程共享同一份物理内存页。只有当某页被修改时，内核才为修改方分配新页并复制内容——这就是COW机制。RDB快照读取的始终是fork那一刻的内存状态。
使用场景：高写入负载下仍能生成一致快照。但要注意，COW会带来额外内存开销：
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 若主线程在子进程保存期间大量改写key，可能触发大量页复制，导致内存用量翻倍
-
rdbcompression yes会让子进程CPU占用升高，但减少磁盘IO和文件体积；关闭它可降低CPU压力，但.rdb文件更大 -
rdbchecksum yes会在写入末尾加CRC64校验，重启加载时校验失败直接报错退出，避免静默损坏
save和bgsave到底差在哪
二者都调用底层rdbSave函数，但执行上下文完全不同：
-
save在主线程同步执行，全程阻塞，期间所有命令排队等待，INFO commandstats里cmdstat_save:calls会飙升 -
bgsave只在fork瞬间阻塞主线程，之后由子进程异步完成；若此时已有bgsave在跑，新请求会被拒绝，redis-cli info | grep bgsave可见rdb_bgsave_in_progress:1 - 自动触发的
save 60 10000规则，底层走的全是bgsave，不是save
RDB文件损坏了还能救吗
能，但必须用配套工具。Redis源码编译后，在安装目录的src/下有redis-check-rdb，它不依赖Redis服务运行：
例如修复损坏的/var/lib/redis/dump.rdb：
src/redis-check-rdb --fix /var/lib/redis/dump.rdb
注意：该工具只能修复格式错误（如截断、非法字节），无法恢复逻辑错误（比如本该存在的key被意外清空）。如果rdbchecksum yes开启，加载时校验失败会直接报Wrong RDB checksum，这时redis-check-rdb就派上用场了。
真正容易被忽略的是：RDB文件权限问题。若dir配置路径的父目录没有Redis用户（如redis）的写权限，bgsave会静默失败，日志里只有一行Can't save in background: fork: Cannot allocate memory——但内存明明够，其实是权限或ulimit限制导致的fork失败。
