Rsync + Sersync 企业级同步备份全解（下）：Sersync 实时同步落地#

在上一篇文章中，我们详细探讨了 Rsync 的原理与企业级守护进程部署方案，并实现了定时数据备份。然而，随着业务对数据一致性要求的提高，传统“定时备份”带来的时间窗口数据丢失风险变得难以接受。

本文将带领大家进入企业级数据同步的深水区，详细解析如何利用 Sersync（基于 inotify + rsync）实现秒级实时同步，彻底消除数据丢失的时间窗口，并最终完成从增量备份到实时容灾的架构升级。

七、Sersync 进阶：从定时同步到实时同步的升级#

7.1 Rsync 的天然短板#

单独使用 Rsync 结合 Crontab 虽然稳定，但在严苛的生产环境中存在两个致命短板：

时间窗口延迟：如果定时任务是每小时执行一次，那么在这 1 小时内发生宕机，期间产生的新数据将全部丢失。
全量遍历的性能开销：当目录内包含数百万个小文件时，Rsync 每次同步都需要遍历比对所有文件属性，这个过程会消耗大量的 CPU 和磁盘 I/O，甚至比对时间比传输时间还要长。

7.2 Sersync 是什么？#

Sersync 是一款由国内开源爱好者基于 C++ 编写的事件驱动实时同步工具。它的底层逻辑非常清晰：inotify + rsync 封装。它利用 Linux 内核的 inotify 机制实时监控文件系统事件（如增、删、改、属性变化），一旦捕获到事件，立即调用内置的 rsync 命令，仅将发生变化的那一个文件同步到远端。

7.3 Sersync 与 Rsync 的核心差异对比#

维度	Rsync (配合 Crontab)	Sersync
触发方式	定时触发（分钟/小时/天级别）	事件触发（毫秒/秒级别）
资源消耗	每次比对整个目录，高 I/O、高 CPU	仅传输变动文件，极低 I/O
功能定位	增量比对与数据传输通道	监听事件、过滤规则、任务调度
部署方式	源端与目标端均需安装	源端安装 Sersync，目标端复用 Rsync 守护进程

7.4 Sersync 核心工作原理与完整流程#

Sersync 的工作流程宛如一条精密的流水线：

事件监听：调用 inotify API 注册对指定目录的监听。
规则过滤：事件触发后，先经过内部的过滤规则（如排除 .tmp 文件或正则匹配）。
调用传输：过滤放行的事件，被拼接成标准的 rsync 命令推送到远端守护进程。
失败重试：如果网络抖动导致推送失败，Sersync 会将任务放入内部队列，并按照设定的策略进行重试，确保数据不丢。

7.5 Sersync 专属企业应用场景#

用户上传资源实时同步：用户头像、附件上传后立即同步至备份服务器。
配置文件实时分发：配置中心修改文件后，瞬间下发到几十台业务节点。
上传数据实时容灾：配合主备双活架构，保持两端存储高度一致。
日志实时收集：支撑实时日志分析系统，日志一产生即被推送到归档节点。

八、Sersync 部署与配置：基于 Rsync 的能力复用#

8.1 部署架构说明#

Sersync 的部署极具“复用精神”：

目标端（接收方）：完全不需要安装 Sersync，只需要按照上一篇的方法，跑一个标准的 Rsync 守护进程即可。
源端（发送方）：部署 Sersync 服务，负责监听本地目录并向目标端主动推送（Push 模式）。

8.2 前置依赖检查#

在源端部署 Sersync 前，需要确保内核支持 inotify 以及安装了 rsync 客户端。

1
# 检查内核是否支持 inotify
2
ls -l /proc/sys/fs/inotify/
3
# 应输出 max_queued_events, max_user_instances, max_user_watches
4

5
# 安装 rsync 客户端
6
yum install -y rsync   # CentOS
7
apt install -y rsync   # Ubuntu

8.3 核心配置文件 `confxml.xml` 全解#

Sersync 下载解压后，核心配置文件是 confxml.xml。我们来看一个生产级的配置模板：

1
<?xml version="1.0" encoding="ISO-8859-1"?>
2
<head version="2.5">
3
    <!-- 全局调试与文件系统设置 -->
4
    <host hostip="localhost" port="8008"></host>
5
    <debug start="false"/>
6
    <!-- fileSystem：配置对特定文件系统事件的支持 -->
7
    <fileSystem xfs="false"/>
8

9
    <!-- 过滤规则：正则排除，不监听也不推送 -->
10
    <filter start="true">
11
        <exclude expression="(.*)\.svn"></exclude>
12
        <exclude expression="(.*)\.gz"></exclude>
13
        <exclude expression="^info/*"></exclude>
14
    </filter>
15

16
    <!-- inotify 事件监听控制 -->
17
    <inotify>
18
        <delete start="true"/>
19
        <createFolder start="true"/>
20
        <createFile start="true"/>
21
        <closeWrite start="true"/> <!-- 文件写入关闭时触发 -->
22
        <moveFrom start="true"/>
23
        <moveTo start="true"/>
24
        <attrib start="true"/> <!-- 权限修改时触发 -->
25
        <modify start="false"/> <!-- 通常用 closeWrite 代替 modify，避免频繁触发 -->
26
    </inotify>
27

28
    <sersync>
29
        <!-- 监听的本地目录 -->
30
        <localpath watch="/data/www">
31
            <!-- 目标端IP与模块名 -->
32
            <remote ip="192.168.1.100" name="backup_module"/>
33
            <!-- 支持向多个目标端同时推送 -->
34
            <!-- <remote ip="192.168.1.101" name="backup_module"/> -->
35
        </localpath>
36

37
        <!-- rsync 推送配置：完全复用 rsync 参数 -->
38
        <rsync>
39
            <commonParams params="-artuz"/>
40
            <auth start="true" users="rsync_backup" passwordfile="/etc/rsync.client.pass"/>
41
            <userDefinedPort start="false" port="874"/>
42
            <timeout start="true" time="100"/>
43
            <ssh start="false"/>
44
        </rsync>
45

46
        <!-- 失败重试机制 -->
47
        <failLog path="/var/log/sersync_fail.log" timeToExecute="60" count="3"/>
48

49
        <!-- 定时全量兜底同步 -->
50
        <crontab start="true" schedule="600"><!-- 600分钟全量比对一次 -->
51
            <crontabfilter start="false">
52
                <exclude expression="*.php"></exclude>
53
            </crontabfilter>
54
        </crontab>
55
    </sersync>
56
</head>

inotify 事件优化建议
在配置文件中，建议将 <modify start="false"/> 设为 false，并开启 <closeWrite start="true"/>。因为大文件在写入过程中会不断触发 modify 事件导致频繁同步，而 closeWrite 只会在文件写入完成关闭句柄时触发一次。

8.4 启动服务与功能验证#

启动 Sersync 时，需要指定一些关键参数：

1
# -d: 以后台守护进程模式运行
2
# -r: 启动前先自动执行一次全量 rsync 同步（确保初始状态一致）
3
# -o: 指定配置文件路径
4
/usr/local/sersync/sersync2 -d -r -o /usr/local/sersync/confxml.xml
5

6
# 验证进程是否存活
7
ps -ef | grep sersync

效果验证：在源端 /data/www 目录下执行 touch test.txt，立刻去目标端 192.168.1.100 的模块目录下查看，文件应在一秒内出现。

8.5 补充特性#

多实例部署：如果源端有多个互不相干的目录需要同步到不同地方，可以复制出多个 confxml.xml（如 confxml_app1.xml），分别启动不同的 sersync 进程即可。
安全控制：Sersync 本质上依然通过 rsync 协议通信，因此目标端的 hosts allow、secrets file 等安全机制完美适用。

九、Sersync 企业实战：4 个实时同步场景#

案例1：用户上传文件实时备份容灾#

场景背景：社交 APP 用户上传的图片存储在业务机 /opt/uploads，必须做到秒级备份到容灾机。

落地要点：

容灾机部署 Rsync 守护进程，配置 [uploads] 模块。
业务机部署 Sersync，配置 localpath watch="/opt/uploads"。
业务机启动参数带上 -r，确保旧历史图片也能全量过去。

案例2：Web 集群静态资源实时分发#

场景背景：运营人员在发布机更新了前端活动页的静态资源，需要立即在 5 台 Web 节点生效。

解决方案：在发布机的 confxml.xml 中，配置多个 <remote> 节点。

1
<sersync>
2
    <localpath watch="/data/static">
3
        <!-- 并发推送到多个 Web 节点 -->
4
        <remote ip="10.0.0.11" name="web_static"/>
5
        <remote ip="10.0.0.12" name="web_static"/>
6
        <remote ip="10.0.0.13" name="web_static"/>
7
        <remote ip="10.0.0.14" name="web_static"/>
8
        <remote ip="10.0.0.15" name="web_static"/>
9
    </localpath>
10
</sersync>

案例3：配置文件实时同步 + 全量兜底校验#

场景背景：同步 Nginx 配置目录，既要秒级生效，又怕遇到偶发网络断开导致 inotify 事件丢失。

解决方案：开启 Sersync 的 crontab 兜底功能。除了实时监听外，每隔一段时间强行做一次 rsync 全量比对，作为最后一道防线。

1
<!-- schedule="120" 表示每 120 分钟执行一次全量比对 -->
2
<crontab start="true" schedule="120">
3
    <crontabfilter start="false"/>
4
</crontab>

案例4：日志目录实时归档#

场景背景：要求业务日志秒级到达 ELK/Fluentd 收集端，但临时产生的 .swp 文件不需要过去。

解决方案：使用 Sersync 自带的正则过滤。

1
<filter start="true">
2
    <exclude expression="(.*)\.swp$"></exclude>
3
    <exclude expression="(.*)\.tmp$"></exclude>
4
</filter>

十、选型对比与常见问题排错指南#

10.1 技术选型：Rsync vs Sersync 怎么选？#

不要盲目追求“实时”，适合业务的才是最好的。

业务场景	推荐选型	核心理由
数据库冷备、全量归档、低频数据	Rsync + Crontab	配置极简，定时执行不占用日常业务 I/O。
TB级大目录迁移	Rsync	Sersync 无法应对海量文件的初始同步。
用户附件、前端静态页分发	Sersync	低延迟要求，文件变更相对低频。
高频变更的小文件（如 Session 缓存）	Redis / 共享存储	inotify 队列容易被打满，不适合用文件级同步。

10.2 高频报错与排错思路#

在使用过程中，80% 的报错都集中在权限和连接上：

1. 权限类报错（Auth failed）

排查点：服务端 /etc/rsync.password 和客户端 /etc/rsync.client.pass 权限是否严格等于 600。
排查点：服务端密码文件格式是 user:pass，客户端只写密码。

2. 目录权限报错（Permission denied）

排查点：服务端真实的物理目录（如 /data/backup）的属主是否是 rsyncd.conf 中配置的 uid/gid。

3. Sersync 专属问题：inotify 队列溢出

现象：当文件突发大批量生成时，部分文件未被同步。

解决：修改内核参数，放大 inotify 监听队列。

1
echo "fs.inotify.max_queued_events = 99999999" >> /etc/sysctl.conf
2
echo "fs.inotify.max_user_watches = 99999999" >> /etc/sysctl.conf
3
sysctl -p

十一、总结与拓展方向#

11.1 全文核心要点回顾#

通过上下两篇的系统学习，我们构建了完整的数据同步知识体系：

从 Rsync 的本地、远程模式，深入到了 企业级守护进程模式，掌握了服务端与客户端的免密交互架构。
掌握了核心参数 -avz 及高危参数 --delete 的预演法则。
通过引入 Sersync（inotify + rsync），弥补了 Rsync 的时间窗口短板，实现了秒级、低 I/O 开销的实时同步。

11.2 进阶拓展方向#

inotifywait 原生用法：如果你不想用 Sersync，也可以自己用 Shell 脚本写一个 inotifywait -mrq ... | while read ... do rsync ... done 的轮子。
lsyncd 对比：除了 Sersync，国外同样流行的还有 lsyncd（基于 Lua 脚本），其在复杂规则支持上更为强大，可作为替代品研究。
分布式同步方案：当同步节点上升到几十上百台时，Rsync 的星型推送会造成单点网络瓶颈，此时应考虑引入 BitTorrent Sync (Resilio Sync) 或 Syncthing 等 P2P 架构的同步工具。

11.3 生产环境落地的通用建议#

生产经验总结
无论使用何种工具，同步绝不等于容灾！实时同步会把“误删”操作也实时同步过去。因此，完美的备份架构 = 异地实时同步（防物理损坏） + 本地定时快照（防人为误删），两者缺一不可。

Rsync + Sersync 企业级同步备份全解（下）：Sersync 实时同步落地#

七、Sersync 进阶：从定时同步到实时同步的升级#

7.1 Rsync 的天然短板#

7.2 Sersync 是什么？#

7.3 Sersync 与 Rsync 的核心差异对比#

7.4 Sersync 核心工作原理与完整流程#

7.5 Sersync 专属企业应用场景#

八、Sersync 部署与配置：基于 Rsync 的能力复用#

8.1 部署架构说明#

8.2 前置依赖检查#

8.3 核心配置文件 confxml.xml 全解#

8.4 启动服务与功能验证#

8.5 补充特性#

九、Sersync 企业实战：4 个实时同步场景#

案例1：用户上传文件实时备份容灾#

案例2：Web 集群静态资源实时分发#

案例3：配置文件实时同步 + 全量兜底校验#

案例4：日志目录实时归档#

十、选型对比与常见问题排错指南#

10.1 技术选型：Rsync vs Sersync 怎么选？#

10.2 高频报错与排错思路#

十一、总结与拓展方向#

11.1 全文核心要点回顾#

11.2 进阶拓展方向#

11.3 生产环境落地的通用建议#

8.3 核心配置文件 `confxml.xml` 全解#