不会阻塞。rdb持久化由fork()子进程执行，主线程继续处理请求；依赖linux内核写时复制（cow）机制，fork后父子进程共享物理内存页，仅在修改时才复制对应页，保证子进程读取fork时刻快照，但高写入会加剧cow开销。
Redis RDB生成时，主线程写操作会不会阻塞？
不会阻塞。RDB持久化触发后，Redis会 fork() 出一个子进程专门负责把内存数据写入磁盘文件，而主线程继续处理客户端请求。关键在于：fork() 后父子进程共享同一份物理内存页，靠操作系统内核的写时复制（COW）机制隔离后续修改。
什么是写时复制（COW）？它在RDB中怎么起作用？
COW不是Redis实现的，是Linux内核对 fork() 的优化策略。子进程创建瞬间不拷贝内存，只复制页表项，并将所有内存页标记为“只读”。一旦父进程或子进程尝试修改某一页，CPU触发缺页中断，内核才真正复制该页内容，再让修改方写入副本。
这意味着：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- RDB子进程看到的是
fork()那一时刻的内存快照，哪怕主线程后续疯狂写入，也不影响子进程读取原始页 - 主线程每次写键、删键、过期key清理等操作，只要涉及修改已有内存页，就会触发该页的复制——这会带来额外内存开销和轻微性能抖动
- 如果
fork()后主线程写得越少，COW复制页越少，RDB过程越轻量；反之，高写入场景下内存占用可能临时翻倍（尤其大value场景）
哪些操作会显著加剧COW开销？
不是所有写都平等。以下行为会让COW更频繁、更重：
-
SET或APPEND覆盖已存在 key 的大字符串（比如 1MB value），直接修改原内存页 → 触发复制 -
HSET更新哈希表中某个 field，若哈希桶已满或触发 rehash，可能引起底层 dict 结构重分配 → 修改多页 - 大量 key 过期集中发生（如设置了相同 TTL），Redis 在
activeExpireCycle中批量删除，连续修改内存结构 - 开启
lazyfree-lazy-expire yes可缓解部分压力，但只是把删除延迟到后台线程，fork()时仍需保留待删对象的引用，不能减少初始COW页数
如何观察和验证COW的实际影响？
别猜，看指标：
- 监控
INFO memory中的mem_fork_dirty字段：表示fork()后被修改过的内存页数量（单位：KB），数值越大说明COW越剧烈 - 对比
used_memory和mem_fork_bytes：后者是子进程实际使用的物理内存，明显高于前者就说明COW已大量发生 - 系统层用
cat /proc/<pid>/status | grep -i cow</pid>查看进程的写时复制页统计（需 root 权限） - 注意：
mem_fork_dirty值在RDB结束、子进程退出后清零，所以必须在RDB执行中实时抓取
COW本身不可绕过，但它的代价取决于你写什么、怎么写。高频小写入影响有限，而一次覆盖几MB的value，可能瞬间拉高内存并拖慢RDB完成时间——这点容易被忽略，直到OOM Killer开始杀进程。
