复制!什么和怎么做。

特性/存储库类型	任何公共回购	其他团队的回购
访问频率	低(仅在添加新库或更新库时)	高(项目内部快照)
不必要的工件	许多	几乎没有

因此，每次按需带来一个工件，对于公共存储库来说是好的，但对于项目间依赖项来说是错误的。治疗方法是什么?复制。

其思想是在实际需要之前从远程存储库中获取构件，假设提前下载所节省的时间要大于引入一些不需要的构件所带来的损失。现在每个团队都有自己的本地内容副本。看，这感觉就像备份(从另一台服务器恢复)和高可用性(如果一台服务器坏了，使用另一台)!一旦你做了复制，你就得到备份和HA免费!

有两种方法可以做到这一点:当存储库内容发生更改(通过事件)时，将构件推送到远程服务器，或者将所有最近的更改作为数据传输到远程服务器一次批量处理时间。让我们更深入地了解这两种方法。

事件驱动的复制

这似乎是自然的方式，不是吗?一旦发生了什么，您只需将事件发送到另一个服务器，瞧，两个服务器是几乎是实时更新的，你总是只转移最少量的东西:只转移那些被改变的东西。但我们有局限性:

• 如果您有一个现有的服务器，您该怎么做?哪些事件将把所有现有数据从服务器同步到新实例?
• 如果在没有反馈的情况下事件传递失败了，那么怎么办?你知道，网络不可靠。你怎么能确定你没有错过事件呢?
• 当网络分裂时会发生什么?事件需要排队多长时间，直到另一方重新出现?许多快照工件此时可能不再有效。
• 事件驱动的复制总是需要将数据推送到另一台服务器。而且，正如你所知道的，推送和防火墙并不能很好地相处。

有很多问题需要解决。您可以这样做，也可以查看另一种类型的复制——计划复制。

计划复制

这个很简单。只是设置周期和一个服务器将数据推送到另一个服务器。不能推?没有问题。拉。这种简单的设置消除了事件驱动复制的问题。方法如下:

• 添加新服务器—手动触发复制。
• 传输失败，没有反馈-请重试复制。
• 推送和防火墙的关系并不是很好——因为复制可以在任何一端启动，所以要从服务器拉出数据，而不是推送数据。

您可以将拉式复制视为常规的远程复制代理仓库，在类固醇。您的服务器不再耐心地等待用户请求工件，然后才去远程服务器查找它，而是采取行动并提前获取工件以预填充缓存。一旦从表格以上都是正确的，是有道理的。

总的来说，计划复制看起来令人印象深刻。陷阱在哪里?它有两个主要缺陷:

• 首先是时机。当使用事件驱动的复制时，服务器几乎在更改后立即同步。
• 第二个(也是更大的)问题是决定转移什么。我们是否应该保留一些日志来确定三角洲？我们应该在复制过程中计算增量吗?如何?通过改变日志吗?按文件内容?按文件名?所有这些方法都有明显的缺点。日志可能与其他服务器上的更改不兼容，按内容进行增量处理无法处理大型二进制文件，按文件名进行增量处理无法考虑副本。但这里有一个很好的技巧:一旦你知道文件的校验和，增量计算不再是个问题。您可以决定是否需要将文件传输到另一个服务器在任何时间!

综上所述:事件驱动复制(几乎)立即复制的内容是显而易见的。计划复制同时支持推和拉模式，独立于事件并且对防火墙友好，但是内容计算可能是一个问题(除非您有校验和)。

正在进行的复制
（如何我们在Artifactory中就是这么做的)

幸运的是，JFrog从一开始就选择了正确的二进制存储类型。Artifactory特性校验和存储。这意味着我们在任何时候都知道所有文件的校验和，并以多种方式使用这些数据，例如防止本地文件重复。对我们来说，使用预定的复制是很自然的，享受它的所有好处，而不会遭受它的主要缺陷。

事实上，Artifactory现在提供了强大的复制支持，包括以下特性:

• 基于校验和的内容传输。只有校验和不匹配的文件才会在网络上传递。它节省时间和金钱。
• 支持推拉两种模式。要提供防火墙友好的连接，请使用pull。要在另一台服务器上强制执行工件，请使用push。
• 复制元数据，而不仅仅是工件。它包括各种元数据(例如maven、用户创建的属性等)，它还使用校验和逻辑。
• 流传输的卓越性能。

您今天就可以开始使用复制。在这里是一个简单直观的用户指南。

您可能会问，那么复制定时呢?好吧，一旦完成了基本复制的繁重工作，在其上添加事件触发器就不成问题了。我们正在做这件事。基于校验和的存储使得这很容易(再次)。

正如您所看到的，基于校验和的存储可以让您享受计划复制和事件驱动复制的世界，而不会牺牲带宽、延迟、存储空间和计算能力。想亲眼看看吗?下载Artifactory Pro的试用版(实际上，复制需要两个版本)，然后试一试。

享受你的身材!