一、为什么网站架构里会需要实时同步¶

原始笔记先把问题背景说得很清楚：

• 之前已经通过 rsync + 定时任务 实现了定时备份或定时同步
• 但对于 NFS 这类共享存储场景，往往需要更实时的数据同步

也就是说，定时同步适合“按小时或按天收集数据”，但如果业务要求文件变化后尽快同步出去，单靠定时任务就不够了。

二、实时同步场景里常见的几种选择¶

原始笔记给出了三类典型方向：

• 分布式存储
• 实时同步服务 + NFS
• 公有云对象存储，例如阿里云 OSS、七牛存储、腾讯 COS

在课程当前这个阶段，实际选择的是：

• NFS + 实时同步工具

这个组合的优点是：

• 思路直观
• 组件清晰
• 适合实验环境和共享存储场景

三、实时同步工具有哪些¶

原始笔记列出了三种常见方案。

3.1 inotify¶

特点：

• 本质上是一个监控文件变化的机制或命令
• 可以监控指定目录是否发生变化
• 但如果要真正落地，通常还需要自己写脚本配合

原始笔记对它的评价是：

• 有一些使用上的坑
• 需要自己写脚本
• 不太推荐直接作为课程里的一线方案

3.2 Sersync¶

特点：

• 国产开源工具
• 内置 inotify + rsync
• 基本上是“一个命令 + 一个配置文件”的思路

这也是本篇笔记的主角，因为它大大降低了实时同步落地的复杂度。

3.3 Lsyncd¶

特点：

• 一些公司确实在使用
• 更适合作为课后延伸研究方向

从课程节奏来看，当前阶段重点仍然是先把 Sersync 这条链路跑通。

四、Sersync 的核心原理怎么理解¶

原始笔记中专门给出了“Sersync 原理图”。虽然图示没有展开成大段文字，但结合上下文，可以先抓住它的核心逻辑：

1、本地共享目录发生变化 2、Sersync 基于 inotify 监听到文件事件 3、再调用 rsync 把变化内容同步到远端备份节点

换句话说，Sersync 并不是替代 rsync，而是：

• 负责“监听变化”
• 再自动触发 rsync 执行同步

这就是为什么它特别适合做“目录变化后自动同步”的场景。

五、Sersync 同步架构如何理解¶

原始笔记还给出了“Sersync 同步架构图”。结合后面的部署流程，可以把这个架构理解成三层：

• gitlab-01：NFS 客户端，业务侧写入文件
• nfs01：NFS 服务端，同时也是 Rsync 客户端，并运行 Sersync
• harbor01：Rsync 服务端，负责接收同步数据

这条链路的本质是：

业务写入文件 -> 文件落到 NFS -> Sersync 监听 NFS 目录变化 -> 通过 rsync 实时推送到备份节点

六、为什么实时同步常和 NFS 放在一起讲¶

在网站架构里，NFS 常常承担共享存储角色。多个业务节点都可能把上传文件写到 NFS 服务端的共享目录中。

这时如果还希望：

• 远端备份节点也尽快拿到这些变更
• 不想再靠手工或低频定时任务同步

那么 Sersync + Rsync 就是非常自然的组合。

它把：

• 存储
• 实时监听
• 远端同步

这三件事串成了一条完整链路。

七、从架构角度看，实时同步解决了什么问题¶

实时同步最核心解决的是“文件变化和备份侧感知之间的时间差”。

如果没有实时同步，通常只能靠：

• 人工执行
• 定时任务轮询

这样就会有明显延迟。尤其在共享存储场景中，文件变化往往比较频繁，实时同步可以显著缩短从“文件发生变化”到“远端备份节点拿到变更”的时间。

八、实时同步并不等于高可用¶

虽然实时同步很有价值，但它本身并不等于彻底解决所有存储问题。结合课程上下文，至少要分清下面几层概念：

• NFS：解决共享存储问题
• Sersync + Rsync：解决文件变化后快速同步问题
• 分布式存储 / 对象存储：解决更大规模、更高可用或更云化的存储问题

也就是说，实时同步是一种增强能力，不是所有存储问题的终极答案。

九、小结¶

学习实时同步这部分内容，建议先抓住下面几个重点：

• 为什么定时同步在某些场景里不够用
• 课程当前选择的是 NFS + 实时同步工具
• inotify、Sersync、Lsyncd 是三类典型方案
• Sersync 的核心逻辑是“监听变化 + 调用 rsync”
• 它特别适合 NFS 共享目录发生变化后立即同步到远端备份节点

把这几个概念先理顺，后面再进入 Rsync、NFS 和 Sersync 的联动部署，会更容易理解整条实时同步链路。