您当然可以在实例之间共享同一个 S3 存储桶 - 事实上,这通常与来自 author->publisher(s) 的无二进制复制一起使用,并且是一种经过验证的真实配置。
甚至可以在完全不同的环境(例如 DEV/STAGE 或 BLUE/GREEN 在您的情况下)之间共享同一个存储桶。要注意的主要“问题”是关于 DataStore 垃圾收集 (DSGC),因为很可能会有一些仅由共享存储桶的一些实例引用的 blob,因此在清除未使用的 blob 时,这需要考虑到。
虽然这都是设计的一部分,并且有一个专门为此目的设计的标志,它告诉 DSGC 只执行 GC 的第一阶段(“标记”阶段),并跳过第二个“扫描”阶段,直到所有实例已标记他们希望保留/丢弃的 blob。一旦所有实例都完成了,那么可以运行扫描阶段以清除任何使用存储桶的实例不需要的 blob。
有关更详细的说明,请参阅 Oak 文档:
https ://jackrabbit.apache.org/oak/docs/plugins/blobstore.html#Shared_DataStore_Blob_Garbage_Collection_Since_1.2.0
我发现它有助于理解几乎所有的数据存储实现都是根据它们的校验和存储 blob,因此添加两次上传的同一个文件只会在数据存储中存储一个副本,并且会有两个段存储引用同一 blob 的记录。同样,共享同一个存储桶的多个 AEM 实例将能够找到给定的 blob,而不管哪个实例首先将它放在那里。
FileDataStore
您可以通过找到一个 blob 并'ing 它轻松地观察到这sha256
一点 - 例如(此示例在 OS X 上,Linux/Windows 上的校验和命令会略有不同):
$ shasum -a256 crx-quickstart/repository/datastore/0c/9e/40/0c9e405fc8d0f0405930cd0044611cfbf014938a1837ae0cfaa266d7732d1002
0c9e405fc8d0f0405930cd0044611cfbf014938a1837ae0cfaa266d7732d1002 crx-quickstart/repository/datastore/0c/9e/40/0c9e405fc8d0f0405930cd0044611cfbf014938a1837ae0cfaa266d7732d1002
在那里您可以看到 a) 文件名是校验和,b) 它使用该校验和中的前 3 对字符嵌套,因此您可以通过仅知道哈希值以及存储相同的二进制文件来定位文件,即使如果名称或 JCR 元数据不同,则引用的 blob 将是磁盘上的相同文字文件。
从内存 S3 数据存储使用前缀而不是目录嵌套,因为这样性能更好,但原理是一样的。
最后,需要考虑的几点是:
1) S3 存储相对便宜(实际上是无限的),因此有一个论点是,除非您真的想省钱,否则没有必要执行常规 DSGC。
2) 如果您确实运行 DSGC,则需要考虑这将如何与您用于 AEM 实例的任何备份策略一起工作。例如,如果您在运行 DSGC 后不久回滚段存储,您可能必须恢复其中一些已清除的 blob。您可以使用版本控制和/或生命周期规则来帮助解决此问题,但它可能会显着增加恢复过程的复杂性和时间。
如果您选择简单地跳过 DSGC 并将 blob 无限期留在那里,最好确保 AEM 使用的访问密钥或 IAM 角色没有DeleteObject
存储桶的权限,以确保流氓 GC 进程不能删除任何东西。
希望这可以帮助。
编辑
在我忘记实际回答您的问题的所有内容中 - 是的,在大多数情况下它会节省一些克隆时间。您仍然需要同步段存储(显然),并且有多种方法可以做到这一点。crx2oak
肯定是一个 - 您将在文档中看到使用 S3 的特定选项,您可以在其中提供配置文件(基本上是.config
与 Felix/OSGi 一起使用的序列化文件)。
您还可以使用类似rsync
的方法简单地复制 TAR 文件(至少目标 AEM 已停止。Oak 通常是原子的,因此理论上可以从源进行热复制,但 YMMV)。
最后,您显然可以使用 Mongo 并以这种方式对分段存储进行集群,但所有常见的成本/复杂性/性能问题都适用)。
蓝/绿字体即将出现的另一个有趣的发展是CompositeNodeStore
- 2017 年的 adaptTo() 会议上有一个很好的讨论,讨论了这个:
https://adapt.to/2017/en/schedule/zero-downtime-deployments-for-the-sling-based-apps-using-docker.html