rsync不自带文件锁机制,其配置中的lock file仅用于防止多实例启动,无法保护同步时的目标文件;真正避免并发写冲突需用flock在调用rsync前对统一锁文件加排他锁,并通过文件描述符绑定确保锁生命周期与进程一致。

直接用 flock 配合文件描述符是最稳妥、最轻量的方案,不依赖外部服务,锁生命周期与进程绑定,出错也不留死锁。
为什么不用 rsync 自带的 lock file 机制
rsync 本身不提供内置文件锁;rsyncd.conf 中的 lock file = /var/run/rsync.lock 只是守护进程(rsync --daemon)自己用的内部锁,用于防止多个 rsyncd 实例同时启动,和「同步过程中保护目标文件」完全无关。实际同步时,如果多个 rsync 客户端并发写同一个目标路径,依然会覆盖或截断文件。
-
rsync是无状态工具,它不检查目标文件是否正被其他进程读写 - 即使加了
--delay-updates或--partial,也只是影响临时文件行为,不解决并发写冲突 - 真正要保护的是「写入目标文件」这个动作,必须在调用
rsync前加锁
用 flock 包裹 rsync 命令的正确姿势
关键不是锁 rsync 本身,而是锁住目标目录或一个专用锁文件,让所有参与同步的进程协商同一把锁。推荐用独立锁文件(如 /var/lock/myapp-sync.lock),避免对业务文件加锁引发权限或语义混淆。
- 必须用
exec绑定文件描述符,否则flock退出后锁立即释放 - 锁文件只需存在即可,不需要可写权限,甚至可以是空文件或软链接
- 务必使用
-w或-n,避免无限等待;生产环境建议设超时(如-w 30)
示例:
Linux 性能分析与调优专家,覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景:系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。
flock -w 30 /var/lock/myapp-sync.lock -c 'rsync -av --delete /src/ user@host:/dst/'
如果命令需更精细控制(比如失败时不阻塞后续调度),改用 fd 方式:
exec 200>/var/lock/myapp-sync.lock if flock -n 200; then rsync -av --delete /src/ user@host:/dst/ else echo "Sync locked by another process" >&2 exit 1 fi # fd 200 关闭时自动解锁(通常在脚本退出时发生)
共享锁 vs 排他锁:读多写少场景怎么选
多数同步任务是「写入目标」,必须用排他锁(-x,默认),哪怕只是单向同步。共享锁(-s)只适用于多个进程**只读不写**目标文件的极少数情况——比如多个监控脚本同时读取一份只读的同步状态报告。
-
flock -s允许多个进程同时持有,但一旦有人申请-x,所有-s会被阻塞 - 不要误以为「rsync 拉取(pull)」就是读操作:它会在本地覆写文件,仍是写行为
- 混合读写场景(如一边 rsync 写,一边 tail -f 读日志)需额外协调,
flock无法保证读进程看到一致快照
容易被忽略的三个细节
锁文件路径必须全局一致且可访问;flock 是建议性锁,所有参与者必须主动调用;锁粒度选错会导致看似正常实则失效。
- 不同脚本用不同锁路径(如
/tmp/sync1.lock和/tmp/sync2.lock)等于没锁 - 某个 rsync 调用漏掉
flock,整个同步链就失去保护 - 锁整个目录(
flock /path/to/dir)无效 ——flock只作用于文件,目录锁需用子目录下统一锁文件










