复制!什么和怎么做。

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

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

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

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

事件驱动的复制

这似乎是很自然的方式，不是吗?一旦发生了什么事情，您只需将事件发送到另一个服务器，瞧，两台服务器都出现了是最新的几乎是实时的，你总是转移最少的:只改变了什么。但这里有一些限制:

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

有一大堆问题要解决。你可以这样做，或者看看另一种类型的复制——预定的复制。

计划复制

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

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

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

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

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

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

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

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

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

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

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

您可能会问，复制时间呢?一旦完成了基本复制的繁重工作，在其之上添加事件触发器就不是问题了。我们现在正在努力。基于校验和的存储使它(再次)变得简单。

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

享受你的构建吧!