最琐碎和天真的方法可能是设置一个脚本,只为每个要同步的服务器运行rsync.

在大多数情况下这很好,但我认为这不是你想要的,因为你会想到这一点……

这种方法也有以下缺点：

>一台服务器发送所有流量,没有级联.所以它的单点故障和瓶颈
>这是非常低效的. Rsync是一个很棒的工具,但如果要同步数百台服务器,解析文件列表并检查差异的速度并不快

但你能做什么呢？

为多个服务器配置rsync显然是最简单的方法.所以你应该从那开始并优化问题所在.

例如,您可以使用正确的文件系统加快速度. XFS可能比Ext3快50倍.

您还可以使用unison这是一个更强大的工具,并在缓存中保留文件列表.

您还可以设置级联(服务器A同步到服务器B同步到服务器C).

你也可以设置拉动而不是推动你的客户.您可以拥有一个子域,该子域是负载均衡器的入口点,您可以通过从源服务器推送来同步一个或多个服务器.

我告诉你这一切的原因是因为没有完美的方法,你必须根据你的需要弄明白.

不过我肯定会建议考虑GIT.

Git是一个非常强大和高效的版本控制系统.

您可以创建一个git存储库并推送到您的客户端计算机.

它工作得非常好,效率高,灵活且可扩展,因此您可以在此结构上构建几乎任何内容,包括分布式文件系统,级联,负载均衡等.

希望我能给你一些正确指导你的观点.

编辑：

所以看起来你想在同一台服务器上同步更改 – 甚至是同一个硬盘(我不知道,但对你所拥有的可能性非常重要).

基本上它完全一样.插入 – 覆盖 – 删除…
Rsync也是一个非常好的工具,因为它会逐渐传递变化.不仅“恢复破损转移”.

但我会说这完全取决于内容.

如果你有很多小文件,比如说模板,javascript等,rsync可能会很慢.完全删除源文件夹并再次复制文件可能会更快.所以rsync(或任何其他工具)不必检查所有文件的更改等.

您也可以使用-rf开关复制所有内容,这样一切都将被覆盖,但随后您可能会将旧文件删除.

我也知道很多情况下使用颠覆来完成这样的事情,因为人们觉得有更多的控制权或我不知道的事情.它也更灵活.

但是你应该想到一件事：

有共享数据的概念.

有符号链接和硬链接.

你可以把它们放在文件和文件夹上(硬链接只在文件上.我不知道为什么).

如果你把一个符号链接A放在一个目标B上,那么文件看起来就像是符号链接一样被定位和命名,但后面的资源完全不同.
但应用程序可以区分.例如,Apache必须配置为遵循符号链接(否则会出现安全问题).

因此,如果您更改都在一个文件夹中,您可以放置​​一个名为该文件夹的符号链接,指向您的文件夹,您再也不用担心同步,因为它们共享相同的资源.

但是,您有理由不这样做：

>他们看起来不一样. – 这听起来很荒谬,但实际上,这是人们不喜欢符号链接的最常见原因.人们抱怨是因为他们“在他们的计划中看起来很奇怪”或者其他什么.
>符号链接在某些功能上受到限制,但因此具有其他巨大优势.像跨文件系统指向等.但是.几乎所有的缺点都可以很好地处理并在您的应用程序中解决.可怜的事实是,符号链接是linux ose和文件系统的基本特征,但在开发应用程序时它们的存在有时会被遗忘.它就像开发一列火车但忘记了还有长腿或者其他东西的人……

另一方面,硬链接看起来像文件,因为它们是文件.

每个指向一个文件的硬链接都是那个文件.

这听起来令人困惑,但想到如下：

每个文件都是光盘上的一些数据.然后有一些inode指针,它在某个目录中有一些名称指向该资源.

硬链接就是这样.该文件只有多个“列表”.

因此,它们共享相同的读锁定,一起修改/删除/等.

然而,这当然只能在一个文件系统/设备上完成,而不是跨设备.

链接有一些很大的优势.他们很明显：

您没有重复的数据.这消除了不一致的可能性,您不必更新并且需要更少的磁盘空间.

然而,这有时更重要.

例如,如果您运行多个网站,并且所有网站都使用Zend Framework.

这是一个shitload庞大的框架,它的操作码缓存将填满你公羊的50兆左右.

如果您的网站具有相同的zend库文件夹,则只需要一次.