两台CentOS服务器要实现实时同步，最靠谱的免费方案是rsync配合inotify实时触发，做好免密登录与排除规则，秒级完成单向同步；如果追求更省心，用lsyncd封装底层逻辑，半小时内能搭好生产级环境。
先想清楚：你说的是同步还是备份
很多人把“同步”和“备份”混为一谈，备份是把数据复制一份放起来，同步是让两台机器上的数据时刻保持一致，实时同步的核心诉求是：主服务器上文件一变,备服务器立刻跟上。
场景不同，方案完全不同，比如两台Nginx负载均衡的服务器，静态资源要同步；两台数据库服务器，不能用文件同步方案去搞；两台应用服务器随便玩玩，rsync就够；要做高可用切换，那就得上DRBD，下面说的都是针对文件级别的同步，数据库请走主从复制,这不是一回事。
centos文件实时同步：为什么cron加rsync不够用
网上大量教程告诉你用crontab定时跑rsync，这方案能用但谈不上“实时”，cron最小粒度是每分钟执行一次，意味着最多有60秒的延迟窗口，文件在这60秒内变了两次，二次rsync基于增量比对也能追平,但生产环境里60秒能发生很多事。
行业共识认为,真正的实时同步必须满足两个条件：
- 事件触发：文件变动立刻感知，而不是等定时器
- 增量传输：只传变化的部分，不整个目录重扫
rsync本身解决不了“实时”这个感知问题，它只是个搬运工，感知文件变化需要另一个工具，也就是inotify，inotify是Linux内核提供的文件系统事件通知机制，文件被写入、改名、删除时,内核会主动告诉你。
rsync和inotify什么区别：各司其职的组合
rsync是传输层，inotify是感知层，两者不是替代关系,是协作关系。
- rsync负责把A机器的文件推到B机器，支持增量、支持压缩、支持断点续传
- inotify负责盯住指定目录，一旦有变化就喊rsync开工
常见的操作路径分四步走。
第一步：配置免密登录
ssh-keygen生成密钥，把公钥放到目标机的authorized_keys里，这个步骤不用多解释,两台机器之间不可能每次同步都输密码。
第二步：写同步脚本
#!/bin/bash
src=/data/www/
dest=backup@192.168.1.20:/data/www/
/usr/bin/inotifywait -mrq -e modify,create,move,delete /data/www/ | while read file
do
rsync -avz --delete --exclude='.log' $src $dest
done这里有个关键点：rsync必须加--delete参数，否则源端删了文件，目标端还留着，同步就不完整，排除日志文件之类的高频变动目录,能大幅降低传输负载。
第三步：用inotify-tools监听
运行上面的脚本，inotifywait会持续监听/data/www目录，每次有变动,rsync全量增量推一次。
第四步：设置开机自启
把脚本写进/etc/rc.local或做成systemd服务。
这套方案的优缺点非常明显，优点是纯命令行、无额外依赖、CentOS自带的rsync就能干活，缺点是脚本逻辑太简单，如果文件变动特别频繁，rsync进程还没跑完，下一个触发又来了，会出现进程堆积，生产环境建议加个锁,或者直接换lsyncd。
两台Linux服务器数据同步方案：lsyncd更省心
既然手动写脚本有坑，不如用现成工具，lsyncd就是把inotify和rsync做了封装，支持进程池、失败重试、延迟汇总,稳定性和并发控制比手写脚本靠谱得多。
安装lsyncd在CentOS上非常简单：
yum install epel-release
yum install lsyncd配置文件位于/etc/lsyncd.conf,核心配置如下：
settings {
logfile = "/var/log/lsyncd/lsyncd.log",
statusFile = "/var/log/lsyncd/lsyncd.status",
inotifyMode = "CloseWrite",
maxProcesses = 8
}
sync {
default.rsync,
source = "/data/www",
target = "backup@192.168.1.20:/data/www",
exclude = { ".log", ".git" },
rsync = {
binary = "/usr/bin/rsync",
archive = true,
compress = true,
delete = true
}
}启动后，lsyncd会自动拉起inotify，把文件事件排队处理，相比手动脚本,lsyncd的优势在于：
- 事件聚合：一秒内多次改动合并成一次传输
- 失败重试：网络抖动导致同步失败会自动重来
- 进度可查：日志和状态文件看得见同步到哪了
多数情况下，lsyncd是这个需求的最佳平衡点，配置简单，行为可预测,故障恢复不用人盯。
双向同步怎么搞：syncthing的适用场景
上面说的都是单向同步，主从架构，实际场景里经常遇到两台服务器都要写数据，比如有两个Web节点，各自产生用户上传文件，这种双向同步用rsync和lsyncd都吃力，因为两边都在变,同步方向无法简单定义。
Syncthing就是干这个的，它基于P2P协议，不依赖中心服务器，两台CentOS之间直接建立加密通道做双向实时同步，CentOS上装Syncthing稍微繁琐一点，需要下载二进制或者用官方仓库,但走完一遍也就十几分钟。
配置思路是：
- 两台机器都安装Syncthing
- 各自指定要共享的目录
- 互相添加设备ID
- 选择“发送和接收”模式
Syncthing对文件变动的感知同样是秒级的，支持版本冲突处理，理论上不存在“最后写入覆盖”的恶性丢数据问题。
不过要泼一盆冷水：双向同步解决的是数据一致性问题，解决不了数据正确性问题，如果A机器上的文件被误删，同步会把B机器上的同款文件也删掉，误操作是双向同步的最大风险，生产环境更稳妥的做法是：双向同步加定时快照，备份是备份,同步是同步。
简米云和酷番云的centos服务器怎么同步
两台云服务器之间做同步，和物理机房内网没有本质区别,但有几个云环境特有的坑。
云服务器通常有安全组和防火墙两层访问控制，rsync默认走873端口，云服务商的安全策略默认封掉这个端口，你需要在安全组入方向放行873端口，或者干脆用ssh通道的方式跑rsync，走22端口更省事，和lsyncd配合时，推荐用ssh模式而非rsync daemon模式,少开一个端口少一分暴露面。
另一个问题是跨区域的内网不通，比如一台在华北，一台在华南，公网传输的延迟和丢包率都比较明显，建议加个带宽限制,避免同步任务把业务带宽占满：
rsync {
bwlimit = 5000
}这里的5000单位是KB/s，就是限速5MB/s,根据文件的平均大小和日增量调这个参数。
云服务器同步慢怎么排查,建议按这个顺序查：
- ping一下对端IP，看基础延迟
- 看rsync有没有走压缩，图片视频文件压缩意义不大还多吃CPU
- 检查目标端磁盘是否写满
- 看两端系统时间是否一致，时间偏移会导致免密登录失败
备选方案：单机双盘与DRBD高可用
如果两台服务器做的是高可用集群，文件同步只是表象，底层要求是数据不丢、切换无损，这种情况下文件级同步是不够的，推荐用DRBD（分布式块设备复制）。
DRBD工作在内核层，把整个块设备的内容实时镜像到对端，应用层完全无感，读写的是本机磁盘，底层自动复制到另一台，Oracle RAC、MySQL高可用这类场景经常见到DRBD。
优点：
- 数据实时性最高，块级别复制无文件系统损耗
- 切换时数据一致性有保证
- 不需要额外通知机制
缺点同样明显：
- 要求主备两边磁盘大小一致或备端不小于主端
- 对网络质量依赖高，延迟大时性能下降明显
- 不支持跨地域远距离部署，一般要求同机房或内网延迟低于10ms
如果同时满足“数据极其重要”和“两台机器距离近”这两个条件，DRBD比任何文件级同步都靠谱，但反过来，只是同步个静态资源,用DRBD就是杀鸡用牛刀。
性能调优与常见坑
实时同步方案落地后，有四个问题是高频故障点,提前处理能省去后面大量麻烦。
避免回环同步
两边如果互相同步同一个目录，A收到B推过来的文件，会认为这是本地变化，再次推回给B，处理方式是配置排除规则，或者在同步标志上做文章，lsyncd默认防回环做得比较好,但手动脚本容易踩这个坑。
inotify监控句柄上限
服务器上被监听的文件数超过系统上限时，inotify会报告no space left on device,检查方法：
cat /proc/sys/fs/inotify/max_user_watches小文件特别多的目录建议把这个值调大到524288：
sysctl -w fs.inotify.max_user_watches=524288rsync进程堆积
文件变动瞬间数量极大时，上一次同步还没跑完，下一次又触发，手动脚本尤其容易出现这个问题，lsyncd的maxProcesses参数控制并发数，默认8个子进程，不够可以加到16，但注意瓶颈一般在对端磁盘I/O。
权限和属主错乱
同步过去的文件属主和本机不一致，导致服务启动失败，rsync加-a参数会保留属主和权限，但前提是源端和目标端的uid/gid一致，跨机器保持同一套用户体系,或者在rsync参数中把owner和group固定映射。
两台centos服务器怎么做实时同步：问题速查
Q: 两台centos服务器实时同步，选rsync还是syncthing？
A: 主从架构、单向复制选rsync配合inotify或lsyncd，逻辑清晰且资源占用小，两台服务器都要产生文件修改，选Syncthing,它天然支持双向同步和版本冲突处理。
Q: 实时同步断了之后，等到网络恢复会自动补传吗？
A: 手动inotify脚本不会，lsyncd配置了失败重试会自动补传，Syncthing具备持续重连机制，网络中断期间文件持续变化，恢复后lsyncd传最新的状态即可,Syncthing则同步完整的版本历史。
Q: rsync同步慢怎么排查，考虑换传输方式吗？
A: 先看是对小文件海量处理慢，还是大文件带宽受限，前者建议加--inplace参数避免每次创建新文件，后者调整bwlimit限速并检查云服务器带宽是否跑满,慢的问题一般出在策略而非工具本身。
两台CentOS服务器实时同步的落地方案，本质上是看清楚业务写入方向和延迟容忍度，再决定用哪套工具链，单向容灾用lsyncd，双向共享用Syncthing，强一致高可用用DRBD，按这个思路选型,不会跑偏。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/720023.html
