rsync+inotify仅支持单向实时同步，无法实现真正的双向同步或毫秒级热备；因其本质是单向推送与单向监听组合，缺乏冲突解决、版本控制和循环抑制机制，强行模拟双向易引发覆盖、丢失及同步风暴。
rsync 本身不支持双向同步，也不具备毫秒级实时能力；它本质是单向、触发式、差量传输工具。inotify 只能监听变化并通知，不能自动完成双向逻辑或解决冲突。所谓“毫秒级实时热备双向同步”在 rsync + inotify 组合中无法真正实现——这是常见误解，需先厘清边界。
为什么 rsync+inotify 做不了真正的双向同步
rsync 是单向推送工具，inotify 是单向事件监听器。二者组合只能实现单向实时同步（如：A → B）。若强行模拟双向，会出现以下不可控问题：
- 两个节点同时修改同一文件，无协调机制，必然产生覆盖或丢失
- inotify 不区分操作来源（本地改 vs 远程同步来的内容），容易引发“同步风暴”（A改→同步到B→B的inotify又触发同步回A→循环）
- rsync 没有内置版本控制、冲突标记或合并逻辑，无法判断“谁的修改应保留”
- inotifywait 最小响应延迟通常为 10–50ms（取决于内核调度和事件队列），并非严格毫秒级，且批量事件会合并上报
接近“准双向”的实用折中方案
若业务确实需要两台 Web 服务器间近似实时互备，推荐分角色部署 + 配套防护，而非硬套 rsync+inotify：
- 主从热备（推荐）：一台为主（写入入口），另一台为只读从库；主站 inotify 监控 → rsync 推送至从站；从站禁止直接写入，避免冲突
- 双写+应用层仲裁：由上层 Web 应用（如 Nginx+Lua 或 Node.js 中间件）统一接收写请求，再分发到两个后端，并记录操作日志；同步由专用服务基于日志回放，而非文件系统监听
- 使用 sersync 替代原生 inotify-tools：sersync 可解析具体变更文件名，配合 rsync --files-from 提高效率；但仍为单向，需搭配外部锁或时间戳标记规避循环同步
Web 目录单向实时热备的关键配置要点
若目标是 A（生产 Web 根目录）→ B（备份/容灾 Web 根目录）的高时效同步，可按以下精简步骤落地：
- 在 B 上部署 rsync daemon，开放模块（如
[web]），设置read only = no，允许 A 认证写入 - 在 A 上安装
inotify-tools，用inotifywait -m -e modify,create,delete,move -r /var/www/html持续监听 - 编写轻量脚本：捕获事件后执行
rsync -avz --delete --exclude='*.tmp' /var/www/html/ rsync://user@B/web/（注意末尾斜杠） - 用
systemd或supervisord管理该脚本常驻运行，避免中断；加入简单防抖（如 sleep 0.1s 后再同步）防止高频事件积压
真正支持双向与毫秒级的替代方案
如业务强依赖双向实时一致性，建议跳出 rsync 思路，选用专为协同设计的工具：
- lsyncd：内建 inotify + rsync 封装，支持延迟合并、过滤、多目标，配置简洁，延迟通常
- DRBD：块设备级同步，底层镜像，接近实时，但需同构环境与共享存储认知
- 分布式文件系统：如 CephFS、GlusterFS，天然支持多点挂载与并发写，自带冲突处理策略
- 应用层同步：数据库用主从/集群，静态资源走对象存储（OSS/S3）+ CDN，Web 文件本身不作为状态载体
