rsync 可以支持一对多同步吗？

Question

我可以使用rsync 跨数百个站点在同一服务器上同步我工作的“模型”站点的更改吗？
我将更新常见的模板文件和 JS 脚本。如果可能，我将如何设置？
（我在 Hostgator 专用服务器上，运行 Apache）

Answer 1

阅读我对以下已编辑问题的扩展答案。

最简单和最天真的方法可能是设置一个脚本，只为您要同步的每个服务器运行 rsync。

这在大多数情况下都很好，但我认为这不是你要找的，因为你自己会想出来的......

这种方法也有以下缺点：

• 一个服务器发送所有流量，没有级联。所以它是单点故障和瓶颈

• 效率非常低。 rsync 是一个很棒的工具，但是如果你想同步数百台服务器，解析文件列表和检查差异并不是很快

但是你能做什么呢？

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

例如，您可以通过使用正确的文件系统来加速它。 XFS 可能会比 Ext3 快 50 倍。

您还可以使用功能更强大的工具 unison，并在缓存中保留文件列表。

您还可以设置级联（服务器 A 同步到服务器 B 同步到服务器 C）。

您还可以设置拉动而不是由您的客户推动。您可以有一个子域作为负载均衡器的入口点，在其中您有 1 个或多个服务器，您可以通过从源服务器推送来同步这些服务器。

我之所以告诉你这一切，是因为没有完美的方法，你必须根据自己的需要去想办法。

不过，我绝对建议您研究 GIT。

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

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

它运行良好且高效，灵活且可扩展，因此您可以在此结构上构建几乎任何东西，包括分布式文件系统、级联、负载平衡等。

希望我在您可以研究的正确方向上为您提供了一些要点。

编辑：

所以看起来您想在同一台服务器上同步更改 - 甚至是同一个硬盘（我不知道，但对于您拥有的可能性非常重要）。

嗯，基本上都是一样的。插入-覆盖-删除... Rsync 也是一个非常棒的工具，因为它以增量方式传输更改。不仅“恢复中断的传输”。

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

如果你有很多小文件，比如你说的模板、javascript等，rsync可能会很慢。完全删除源文件夹并再次将文件复制到那里可能会更快。因此 rsync（或任何其他工具）不必检查所有文件的更改等。

您也可以使用 -rf 开关复制所有内容，这样所有内容都将被覆盖，但您可能会在那里删除旧文件。

我也知道很多这样的事情是使用颠覆来完成的，因为人们觉得有更多的控制权或者我不知道的东西。它也更灵活。

但是，您应该考虑一件事：

有共享数据的概念。

有符号链接和硬链接。

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

如果您将符号链接 A 放在目标 B 上，则文件看起来像符号链接一样被定位和命名，但后面的资源完全不同。 但应用程序可以区分。例如，Apache 必须配置为遵循符号链接（否则将成为安全问题）。

因此，如果您的更改都在一个文件夹中，您只需放置一个名为该文件夹的符号链接，指向您的文件夹，您就不必担心再次同步，因为它们共享相同的资源。

但是有一些你不想这样做的原因：

• 它们看起来不同。 - 这听起来很荒谬，但实际上，这是人们不喜欢符号链接的最常见原因。人们抱怨是因为他们“在他们的程序中看起来很奇怪”或其他什么。

• 符号链接在某些功能上受到限制，但因此具有其他巨大优势。像跨文件系统指向等。但是。几乎每一个缺点都可以在您的应用程序中得到很好的处理和解决。可怜的事实是，符号链接是 linux ose 和文件系统的基本特征，但在开发应用程序时有时会忘记它们的存在。就像开发火车，却忘了还有人腿长什么的……

另一方面，硬链接看起来确实像文件，因为它们是文件。

每个指向一个文件的硬链接就是那个文件。

这听起来令人困惑，但可以这样想：

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

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

因此它们共享相同的读锁，一起被修改/删除/等等。

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

链接有一些很大的优势。它们非常明显：

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

然而，这有时更重要。

例如，如果您运行多个网站并且所有网站都使用 Zend 框架。

这是一个巨大的框架，它的操作码缓存将填满你的 50 兆内存或其他东西。

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