分布式文件系统的 S3 与 EFS 传播延迟？
S3 vs EFS propagation delay for distributed file system?
我正在开发一个使用多个 docker 容器的项目
为了比较目的，它们都需要访问相同的文件。重要的是，如果一个文件对一个容器可见，那么它对其他容器可见的间隔时间最短。
举个例子，这是我试图避免的情况：
假设我们有两个文件 A 和 B，以及两个容器 1 和 2。文件 A 几乎同时上传到文件系统并提交进行比较。紧接着，文件 B 也发生了同样的情况。在文件 A 对容器 1 可见并且文件 B 对容器 2 可见之后不久。由于文件在分布式文件系统上传播的方式，文件 B 对容器 1 不可见，并且文件 A 对容器 2 不可见。容器 1 现在被告知将文件 A 与所有其他文件进行比较，容器 2 被告知将文件 B 与所有其他文件进行比较。由于传播延迟，A 和 B 从未相互比较过。
我正在尝试在 EFS 和 S3 之间做出决定，以用作存储所有这些文件的位置。我想知道哪个更符合我的需求（或者是否还有我不知道的第三种选择）。
files/containers的特点是：
- 所有文件都是小文本文件，平均大小为 2kb（尽管很少有 10kb）
- 目前总共有 20mb 的文件，但我预计到今年年底会有 1gb
- 这些容器不成群
- 每个比较的输出已经上传到 S3
- 确保每个文件都与其他文件进行比较非常重要，因此传播延迟绝对是最重要的因素
（最后一点：如果我最终使用 S3，我可能会使用同步来提取放入存储桶中的所有新文件）
编辑：为了回答 Kannaiyan 的问题，我想要实现的是将每个文件与其他每个文件至少进行一次比较。我不能确切地说出我在比较什么，但是比较是通过执行一个封闭源代码 linux 二进制文件来进行的，该二进制文件包含您要比较的文件和您要与之比较的文件（分布式文件系统持有我想要比较的所有文件）。它们需要放在容器中，原因有二：
- 二进制文件严重依赖于特定的文件系统设置，将其容器化可确保文件系统始终正确（我知道它很笨，但二进制文件又是封闭源代码，没有办法绕过它）
- 二进制文件仅在 linux 上运行，将其容器化使得在本地机器上进行测试方面的开发更加容易。
最后，随着我们收到越来越多的提交，文件只会随着时间的推移而积累。每个文件加入系统后只读不修改
最后，我认为我原来采用的方法太复杂了。相反，我最终使用 S3 来存储所有文件，并使用 DynamoDB 作为最近存储文件的密钥的缓存。只有在成功上传到 S3 后，密钥才会添加到 DynamoDB table。每当比较操作运行时，容器都会同步所需的 S3 目录，然后检查 DynamoDB 以查看是否缺少任何文件。由于 S3 的先写后读一致性，如果丢失任何文件，可以从 S3 中提取它们，而无需等待传播到所有 S3 缓存。这允许一个几乎即时传播的分布式文件系统。
我正在开发一个使用多个 docker 容器的项目 为了比较目的，它们都需要访问相同的文件。重要的是，如果一个文件对一个容器可见，那么它对其他容器可见的间隔时间最短。
举个例子，这是我试图避免的情况： 假设我们有两个文件 A 和 B，以及两个容器 1 和 2。文件 A 几乎同时上传到文件系统并提交进行比较。紧接着，文件 B 也发生了同样的情况。在文件 A 对容器 1 可见并且文件 B 对容器 2 可见之后不久。由于文件在分布式文件系统上传播的方式，文件 B 对容器 1 不可见，并且文件 A 对容器 2 不可见。容器 1 现在被告知将文件 A 与所有其他文件进行比较，容器 2 被告知将文件 B 与所有其他文件进行比较。由于传播延迟，A 和 B 从未相互比较过。
我正在尝试在 EFS 和 S3 之间做出决定，以用作存储所有这些文件的位置。我想知道哪个更符合我的需求（或者是否还有我不知道的第三种选择）。
files/containers的特点是： - 所有文件都是小文本文件，平均大小为 2kb（尽管很少有 10kb） - 目前总共有 20mb 的文件，但我预计到今年年底会有 1gb - 这些容器不成群 - 每个比较的输出已经上传到 S3 - 确保每个文件都与其他文件进行比较非常重要，因此传播延迟绝对是最重要的因素
（最后一点：如果我最终使用 S3，我可能会使用同步来提取放入存储桶中的所有新文件）
编辑：为了回答 Kannaiyan 的问题，我想要实现的是将每个文件与其他每个文件至少进行一次比较。我不能确切地说出我在比较什么，但是比较是通过执行一个封闭源代码 linux 二进制文件来进行的，该二进制文件包含您要比较的文件和您要与之比较的文件（分布式文件系统持有我想要比较的所有文件）。它们需要放在容器中，原因有二：
- 二进制文件严重依赖于特定的文件系统设置，将其容器化可确保文件系统始终正确（我知道它很笨，但二进制文件又是封闭源代码，没有办法绕过它）
- 二进制文件仅在 linux 上运行，将其容器化使得在本地机器上进行测试方面的开发更加容易。
最后，随着我们收到越来越多的提交，文件只会随着时间的推移而积累。每个文件加入系统后只读不修改
最后，我认为我原来采用的方法太复杂了。相反，我最终使用 S3 来存储所有文件，并使用 DynamoDB 作为最近存储文件的密钥的缓存。只有在成功上传到 S3 后，密钥才会添加到 DynamoDB table。每当比较操作运行时，容器都会同步所需的 S3 目录，然后检查 DynamoDB 以查看是否缺少任何文件。由于 S3 的先写后读一致性，如果丢失任何文件，可以从 S3 中提取它们，而无需等待传播到所有 S3 缓存。这允许一个几乎即时传播的分布式文件系统。