宿主机共享目录挂载、同步工具实时监控推送、分布式文件系统自动复制，中小规模场景下，用lsyncd或Syncthing这类工具配合inotify机制，是目前性价比最高、也最常用的方案。
虚拟机文件实时同步，到底卡在哪里
很多人第一次做虚拟机同步时，都会遇到一个很尴尬的情况：虚拟机里改了代码，宿主机上看不到，反过来也一样，原因很简单，虚拟机虽然有独立的文件系统，但底层还是跑在宿主机上，两者之间隔着一层虚拟化层，这个中间层如果不打通，文件就是“各过各的”。
实时同步这个词，重点在“实时”两个字上，传统做法是定时同步，比如crontab里每5分钟跑一次rsync，这类方案的问题在于：5分钟的延迟会让开发调试时反复出问题，改完代码看不到效果，测试脚本跑起来还是旧版本，业内专家指出，研发环境的文件一致性问题,相当一部分都出在同步延迟上。
所以虚拟机文件实时同步的核心诉求是：文件一发生变化，马上就能推送到另一侧,延迟控制在秒级甚至毫秒级。
实验环境下的实时同步方案怎么选
适合自己搭的实验环境，有两个主要方向：一个是宿主机和虚拟机共享目录，另一个是用同步工具做双向或单向实时推送，共享目录适合“文件本来就是同一份”的场景，而同步工具适合“两边各自有文件、需要保持一致”的场景，多数情况下，开发、测试、临时数据备份这三种用途,用同步工具就够了。
lsyncd + rsync，Linux虚拟机的经典组合
lsyncd是专门干“监控目录变化然后触发同步”的工具，它底层用inotify监听文件事件，一有变化就调rsync推过去,这套方案实现起来不复杂：
- 先确认内核支持：
ls /proc/sys/fs/inotify，有输出就说明没问题 - 安装lsyncd和rsync，然后写一个配置文件，指定源路径、目标路径、同步模式
- 用
systemctl start lsyncd启动服务，再看日志确认同步正常
这种方案的实时性取决于inotify的事件触发速度，基本能保持在1秒内，做代码同步、配置文件下发都够用。
Syncthing，跨平台且支持双向同步
如果宿主机的操作系统和虚拟机不一样，比如宿主机是Windows，虚拟机是Linux，Syncthing就比rsync方便得多，它是P2P架构，两端都装客户端，通过设备ID互相识别，不需要配SSH密钥,也不用手动指定远端路径。
Syncthing的ailas机制也适合多虚拟机场景：一台宿主机装一个节点，好几台虚拟机各装一个节点，就可以实现一对多同步，第一次配置时需要交换设备ID，后续运行基本是零维护的，行业共识认为，Syncthing在中小规模节点数（10台以内）的情况下,稳定性要明显优于定时脚本。
云服务器场景下用inotifywait自己写脚本
如果虚拟机跑在云平台上，或者你希望完全掌控同步逻辑，inotifywait配合rsync也是一个常用方案，inotifywait是Linux上专门监控文件事件的命令行工具，可以监听创建、修改、删除、移动等动作,触发后执行自定义脚本。
一个典型的做法是：用inotifywait监控目标目录，一旦检测到close_write事件（文件写完关闭时触发），就执行rsync把文件推到远端，为了避免重复触发，要在脚本里加一个防抖机制，比如事件后sleep 1秒再同步。
这种方法胜在灵活，缺点是需要自己写脚本维护,适合有Linux基础的人。
正式生产环境用的数据同步工具有哪些区别
生产环境的标准和实验环境完全不同，对同步的可靠性、一致性、可回滚性都有更高要求，数据同步工具按工作层级可以分成三类,各管一段。
基于文件级别的同步工具
这类工具就是我们前面说的rsync、Unison、FreeFileSync，它们的共同点是操作对象是“文件”，不关心文件内部内容格式，优点是无侵入、部署快，缺点是如果是超大文件或者大量小文件,性能会受metadata扫描影响。
- rsync：增量同步，配合SSH使用，不支持双向实时
- Unison：支持双向同步，能解决“两边都改了”的冲突问题，但配置较复杂
- FreeFileSync：图形界面友好，适合Windows环境下配合虚拟机共享目录使用，但不适合做后台服务
基于分布式文件系统的自动同步
如果你需要的是“挂载了一个路径，所有节点看到的内容永远一致”，那就应该用分布式文件系统，而不是同步工具，这类方案通常用于多台虚拟机组成集群的场景，写入一个节点,其他节点自动拉取。
典型的开源方案有GlusterFS（适合大文件顺序读写）、Ceph（适合大规模、数据冗余要求高的场景），商业方案有Nutanix等，它们天然支持实时同步,因为文件读写是直接落在分布式存储上的。
这种方案性能损耗要小得多，但架构复杂度高，运维成本也大，如果只有两三台虚拟机,用这种东西属于杀鸡用牛刀。
基于数据库或消息队列的同步
有一种情况要注意：文件”本身只是结果，而数据源在数据库里，那要做的就不是文件同步，而是数据库同步，用binlog或消息队列把变更推送到各节点，再在本地生成文件，这种方案叫做“最终一致”,特别适合多地域部署的虚拟机场景。
数据同步工具怎么选，本质上取决于同步粒度，文件级别的同步工具适合小规模、低延迟、需求明确的场景；分布式文件系统适合节点多、数据量大的业务；数据库同步适合业务逻辑上下游比较复杂的场景。
从工具选型到落地部署的实操路径
很多人选好了工具，但部署时还是会踩坑，下面按场景给三条实操路径,照着走基本不会出太大问题。
宿主机是Windows，虚拟机是Linux
这种情况推荐用FreeFileSync配合实时监控：
- 宿主机上装FreeFileSync，配置好同步方向（建议单向,虚拟机为准）
- 在同步设置的“实时监听”里开启自动同步，监听间隔设到10秒
- 虚拟机上用Samba共享目录出来，FreeFileSync挂载为网络盘
需要注意的问题是权限，Samba共享的写入速度受Windows网络协议影响，对大文件不友好，建议小文件为主,大文件另走rsync。
多台Linux虚拟机间需要实时同步
核心就是lsyncd,但是要区分主从关系：
- 单向同步场景（从一台主节点推到其他节点）：在主节点装lsyncd，多目标配置成数组
- 双向同步场景（节点间互为镜像）：用Syncthing或者Unison
实际操作中，lsyncd配置里要留意delay参数，它控制事件累积时间默认是1秒，这个值设得太小，大量小文件写入会把CPU打满；设得太大，实时性又没了，常规建议是1-2秒。
节点比较多的场景（5台以上），路径命名会变得很关键，建议统一为/data/sync/，配置文件生成用Ansible做模板渲染,而不是手动登到每台机器上去改。
虚拟机跑在云上，需要跟本地同步
本地到云端虚拟机，公网带宽是瓶颈，这种情况下，单纯加同步工具不够，还需要考虑压缩和限速，rsync的--compress可以压缩传输，--bwlimit可以限速，避免同步占满上行带宽,影响其他业务。
另外一个思路是反向代理：在云端虚拟机里装Syncthing，本地节点用中继模式连接到云端，这样两边都能在有防火墙的环境下工作，据统计，采用这种配置的用户里，相当一部分人反馈稳定性和断点续传能力都优于直接跑rsync over SSH。
常见问题解答：虚拟机文件实时同步和数据同步工具
虚拟机上改了文件，宿主机上迟迟不同步，可能是什么原因？
优先排查两个方向，第一，同步工具是否真的在运行，看看进程列表里的进程是否存在，Syncthing的Web控制台能否正常打开，第二，目录是否有事件监听权限，lsyncd和inotifywait对被监听目录有权限要求，普通用户不可写的话，事件根本不会触发，另外注意，部分虚拟机文件系统（如VirtualBox的vboxsf）对inotify支持有缺陷，事件不会正常上报，这时候要么改用轮询模式,要么换NFS挂载。
rsync做实时同步和lsyncd区别在哪里？
rsync本身不支持实时，它每次都需要手动或定时触发，通过对比文件列表和修改时间来确定哪些文件需要同步，lsyncd是在rsync外层包了一层inotify监听，文件一变就立即调用rsync，所以实时性由lsyncd决定，传输能力由rsync决定，可以理解为rsync是发动机,lsyncd是油门。
免费的虚拟机文件同步工具和生产级别的同步方案差距在哪里？
免费的同步工具，比如Syncthing、rsync，能解决80%以上需求，但它们没有统一的元数据管理和冲突仲裁机制，生产环境强调的审计日志、权限收敛、断点续传保证、数据完整性校验，这些需要额外自行组合多种工具或脚本实现，以Syncthing为例，它自带的版本管理功能只能做到有限的历史回溯，达不到企业审计的最低标准,后者通常需要对象存储或分布式文件系统来支撑。