跨机房 rsync 同步需限速、保活、校时、断点续传及状态标记。应设 --bwlimit、ssh 心跳、chronyd 校时，禁用 -z 和 --delete，用 --partial --progress 与轮询补漏，避免依赖 inotify 和 --update。
rsync 跨机房同步时带宽打满导致丢包
跨机房网络链路质量差，rsync 默认不控速，容易把出口带宽占满，引发 TCP 重传甚至连接中断。这不是 rsync 本身的问题，而是它默认用尽可用带宽的策略在弱网下失效了。
- 强制限速：加
--bwlimit=2000（单位 KB/s），数值按实际出口带宽的 60%–70% 设，比如千兆专线实测稳定吞吐 80MB/s，就设--bwlimit=60000 - 避免重传风暴：加上
--partial --progress，断点续传；别用-z（压缩），跨机房 CPU 比带宽便宜，压缩反而拖慢整体进度 - 慎用
--delete：跨机房延迟高，rsync列目录时可能因超时漏判文件，误删远端数据
inotify + rsync 实时同步在跨机房场景下不可靠
inotifywait 只监听本地文件系统事件，一旦网络抖动、rsync 失败或目标机负载高，事件就丢了——它不保证投递，也不重试，不是消息队列。
- 不要依赖单次 inotify 触发：改用轮询 + 时间戳比对（如
find /path -mmin -1）补漏，虽然低效但可靠 - 加状态标记：每次同步前 touch 一个
.syncing文件，成功后改名成.synced，失败则留痕，便于后续人工或脚本识别断点 - 跨机房延迟会导致 mtime 精度失真，别用
--update依赖时间判断，优先用--checksum（但代价是 IO 增加）
SSH 连接不稳定引发 rsync 中断
rsync 底层走 SSH，而跨机房 SSH 默认超时短、无心跳，一次路由抖动或防火墙会话老化就会断连，且 rsync 不自动重连。
PinPHP购物分享系统
下载
PinPHP是一套基于LAMP技术架构(Linux+Apache/Nginx+MySQL+PHP)的、免费的、开源的社会化分享系统！同时PinPHP分享系统V3.0正式版在V2.2正式版的基础上，对“网站架构”、“负载性能”等几大方面，进行了全面升级。注意事项：1、V3.0采用全新的代码结构与数据库结构，不可以进行版本
- SSH 层加固：在
~/.ssh/config里配ServerAliveInterval 30和ServerAliveCountMax 3，让连接保活 - 避免密码登录：必须用密钥，且私钥不设密码（否则无法非交互重试）；同时配置
StrictHostKeyChecking no配合KnownHostsFile /dev/null（仅限内网可信环境） - rsync 加重试逻辑：用 while 循环包裹，检测退出码
$?是否为 10/12/23（常见网络中断码），失败后 sleep 5 秒再试，最多 3 次
时区与时间不同步导致同步逻辑错乱
跨机房机器若未统一 NTP 时间，rsync --update 或基于 mtime 的增量逻辑会直接失效——比如 A 机房时间快 2 分钟，B 机房刚写入的文件，在 A 看就是“未来文件”，被跳过。
- 必须跑
chronyd或ntpd，且指向同一个上级 NTP 源（如内网 ntp.example.com），不能各自连公网 pool.ntp.org - 检查偏差：用
chronyc tracking或ntpq -p看 offset，超过 100ms 就算风险值 - 同步脚本开头加校验：
if [ $(abs $(($(date -u +%s) - $(ssh user@remote 'date -u +%s'))) ) -gt 30 ]; then echo "time skew too large"; exit 1; fi
跨机房同步最麻烦的从来不是工具怎么用，而是每个环节都在悄悄假设“网络可靠、时间一致、连接持久”——而这些恰恰是跨机房最先崩掉的几条线。
