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）
示例：
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只作用于文件，目录锁需用子目录下统一锁文件
