有什么建议可以让我如何将数百万个文件从 1 台服务器分发到 X 台其他服务器？我正在研究一种算法，用于决定将文件发送到哪台服务器。
要求：
- 没有数据库
- 基于 perl/python/shell
- 能够从任何机器运行并最终到达同一目标服务器
答案1
也许可以考虑使用 GlusterFS 之类的分布式文件系统。听起来它可以满足您的所有要求，而且可能比您自己破解的东西更可靠。
答案2
尽管你的要求不可能实现，但根据我在 Github 上做这件事的经验，我还是会为未来其他没有这么困难的人写下我的想法。
根据哈希值将数据分布在多个位置（无论是分区、机器还是数据中心）是一项危险的工作，原因有二：
- 您永远无法根据哈希获得均衡的数据分布——不一定是因为哈希不均衡（尽管这也是一个因素），而是因为您存储的项目大小不相等。因此，您存储了两个项目，一个大小为 1kB，另一个大小为 1GB。您已经严重不平衡了。尝试几次，突然间您就会遇到很大的不平衡。
- 一旦哈希到服务器算法到位，您就无法更改用于存储数据的“存储桶”（机器、分区等）的数量，除非您付出巨大的努力。这是因为哈希算法既用于决定将数据存储在何处，也用于决定将数据存储在何处。在哪里可以再次找到它。如果您更改服务器数量，那么“数据在哪里”的规则就会发生变化，因此一些现有数据预计会位于其他地方。您最终要么进行冗长的离线“重新平衡”操作（每台服务器搜索在新方案中应该位于其他地方的数据，并将其移动到那里），要么必须在所有文件服务器上搜索数据（嗯，效率低下）。
另一方面，如果为所有文件创建一个查找表，这些问题就会消失。当您说“没有数据库”时，我敢打赌您在“数据库”之前插入了一个隐式的“SQL”。但是，还有一大堆与 SQL 无关的数据库，它们非常适合这种情况。它们被称为“键值存储”，如果您非常热衷于自己构建这个无用的东西，那么我强烈建议您使用一个（我有使用 Redis 的经验，但它们似乎都很合理）。
但最终，如果您继续使用“所有哈希，所有时间”系统，然后解决其中固有的问题（有解决方案，但不是真正出色的解决方案），最终您得到的只是一个半吊子、拙劣、功能不完整的 GlusterFS 版本。如果您需要大量存储，可随时间增长，分布在多个物理机器上，在单个命名空间中，我真的会推荐它，而不是您自己可以构建的任何系统。
答案3
如果您仍然想破解它，请对每个文件执行 md5sum，然后将输出散列到您的 X 盒中。
如果你有两个盒子：
0*-7* 转到框一 8*-f* 转到框二...
或者如果您有 256 个盒子：00*-0f* 转到盒子一 10*-1f* 转到盒子二.. 等等..
这最适合于 2 的幂的盒子计数。(2、4、8、16、..)
请记住，重新整理事物是件好事，但如果您还需要检索此信息，则需要在某处保留一个索引。
（我把 foo.txt 放哪儿了？？）
平面文件 pickle（在 python 中）可以工作，但是对于大量数据来说，它的扩展性不如 DB。
答案4
其他服务器也能发送文件吗？你们处在“安全”环境中吗？
Rocks 集群安装过程必须填充一机架又一机架的计算节点，每个节点都是从初始映像动态安装的。以线性方式或通过单个服务器执行此操作会造成瓶颈。Rocks 使用的是一个名为 Avalanche 的小系统，其中安装映像通过 p2p 提供；随着节点的出现，它们也成为将用于安装新节点的服务器。结果是服务器树，安装映像非常快速地通过机架级联。总延迟是节点数的对数乘以安装一个节点的时间（对数的底数取决于可以从已安装的节点中服务多少个其他节点，以 20 为底的对数并不奇怪……）。
您可以想象一种类似的复制文件的策略，但前提是目标服务器愿意信任其他服务器来复制文件。