0

好的，我正在开发各种共享系统/服务。人们可以在那里将自己的媒体上传到服务器。我在大部分构建中使用 PHP 和 mySQL，目前使用的是单一服务器环境。但是我需要它是可扩展的，因为我打算在接下来的 6 个月内将媒体移动到服务器集群，将站点/服务留在自己的服务器上。无论如何，这是一个静音点。

我的目标或希望是提出一个风险极低的命名约定，在上传时重命名文件时几乎不可能与另一个文件发生冲突。迄今为止，我已经阅读了许多概念，发现 UUID (GUID) 是满足我所有需求的最佳选择，因为它有很多可能性，我认为我永远无法达到这么多共享图像。

我的问题是提出了一个生成 UUID 更可取的 v3 或 v5 的函数（我知道它们是相同的，但 v5 目前并未 100% 符合 UUID 的标准）。对 UUID 及其约束知之甚少，这使得它们在以后尝试对它们进行正则表达式时或如果需要时是独一无二的和/或有效的，我似乎无法提出可行的解决方案。我也不知道我应该真正使用 v3 还是 v5。或v4。因此，我正在寻找有关将返回所需版本 UUID 类型的函数的建议和帮助。

省着气我还没有尝试过任何事情，因为我现在不知道从哪里开始。有了这个，我打算将这些文件保存在许多文件夹中，以抵消由大型目录列表引起的负载。所以我也在降低我在那里发生碰撞的风险。我还将这些名称存储在数据库中，其中关联的文件夹和其他信息与每个图像相关联，所以我看到的另一个问题是，当我为要重命名的文件随机生成 UUID 时，我不想查询多个数据库在发生冲突的情况下，我实际上可能希望每个函数调用返回 5 个 UUID，并查看我的查询中是否有匹配项，而我的查询中将使用第一个没有匹配项的匹配项。

无论如何，我知道这是很多阅读，我知道它没有代码，希望你们中的很多人最终不会因为阅读太多而投反对票，并假设这是一个糟糕的问题/讨论。因为我很想知道如何从一开始就解决这个问题，这样我就可以尽可能少地根据需要扩大规模。

4

2 回答 2

1

我的目标或希望是提出一个风险极低的命名约定，在上传时重命名文件时几乎不可能与另一个文件发生冲突。迄今为止，我已经阅读了许多概念，并发现 UUID (GUID) 是满足我所有需求的最佳选择，因为它具有如此多的可能性，以至于我认为我永远无法达到这么多共享图像。

您可以构建一个由以下组成的数字（然后您将其实现为 UUID）：

  • 日期 (YYYYMMDD)
  • 服务器 (NNN)
  • 当天上传到该服务器的图像计数器

这个数字永远不会产生任何冲突，因为它总是递增，并且可以扩展到一千台服务器。假设您每天在每台服务器上最多获得一百万张图像，这大约是 43 位信息。添加其他 32 个随机数，以便无法猜测 UUID（平均少于 2^31 次尝试）。您还剩下大约 50 多位以允许进一步扩展。

或者您可以将一些数字存储在 BCD 中以使它们易于阅读：

20120917-0172-4123-8456-7890d0b931b9

可能是图像 1234567890，随机 d0b931b9，于 2012 年 9 月 17 日上传到服务器 0172。

该方案甚至可以兼作“目录传播”方案：一旦图像具有映射到 20120917-125-00001827-d0b931b9 的 UUID，这意味着服务器 125，您可以将其存储在名为 d0/b9 的目录结构中/31/b9/20120917-125-00001827.jpg。

命名约定确保唯一性，随机位确保目录结构是“扁平的”（填充均匀，没有目录比其他目录更满），优化检索时间。

于 2012-09-17T22:36:04.607 回答
1

如果您要在数据库中存储对每个文件的引用.. 为什么不使用 MySQL auto_incrementid 来命名您的文件？如果将数据库扩展到集群，ID 仍然是唯一的（作为 PK，它必须是唯一的！），那么为什么要在 UUID 生成和其他东西上浪费宝贵的 CPU 时间呢？这不是 UUID 的用途。

我会选择最简单的方法（不过，我已经在许多其他系统中看到过）：

  1. 上传文件
  2. 上传成功后，插入数据库引用（路径由 确定3.）；获取auto_increment_$ID
  3. 将文件重命名为${YEAR}/{$MONTH}/${DAY}/{$ID}
    （如果您需要更细化的路径，当每天上传的文件过多时进行调整）
  4. 重命名失败时，删除数据库引用并显示错误消息
  5. 使用文件系统中的实际路径更新数据库引用
于 2012-09-17T22:36:35.190 回答