我正在寻找构建后端来接受 user-uploaded 图像，重命名它们并将它们存储在文件系统中(不，它不是 Instagram)
我想简单地重命名图像并存储在用户文件夹中：
图片/{。 2}/{。 3} _ {md5(timestamp)} .jpg
这些关联也将包含在数据库中。
这是一个 good/sufficient 型号吗？
基本上你的方法很好，但这是我给你的建议：
不要使用文件名中的时间戳，因为您已经将文件名存储在数据库中，只需为时间戳<->文件关系创建额外的列。这样，它更容易管理诸如原始创建，上次修改甚至到期日期之类的事情。
确保您存储的文件名列是唯一的。你不想意外地存储重复的文件名
对接受文件进行交叉检查。如果文件已成功保存到服务器但查询失败，请确保在失败时删除该文件。或者，如果您的操作顺序相反，如果文件无法保存到服务器，请删除数据库中的条目。
如果不允许公开访问图像，则可以拒绝正常查看图像，而是将用户链接到文件名为 GET 变量的链接(PHP 文件)。然后，您可以检查 SESSIONS and/or COOKIES 以确定他们是否有权查看它。如果是，您可以将输出的标题设置为 jpeg 的标题或他们正在查看的任何类型的文件。
为什么不使用数据库中的唯一 ID，这样可以更容易地找到文件。
它也不限制你的文件结构，也许你不会总是想用用户名保存，如果每个文件都有一个绑定到数据库的 ID，这可能会简单得多。
user/{database_id}.jpg
有点取决于：
每个用户有多少张图片？
每张图片的大小范围？
有多少用户？
你期望什么样的并发？
如果上面的大部分数字都很小，那么你的方法可能会很长，足以让你有一个很长的路要走，并且至少会让你开始。
我知道使用 MySQL blob 存储获取坏新闻，但这也是一种简单的入门方式，你可以对数据库进行分片以获得一些 scale-out 而无需进行任何聪明的编码。
那说......
如果在您的系统中，您希望用户上传大量文件，则可能会遇到文件系统的限制或性能问题。
如果您在 Windows 上托管，请注意8.3 filename 问题(当目录变大时非常慢)，因为您的文件名肯定会长于 8.3 :)
如果很多人同时- 比如在高峰使用期 - 你将不得不注意 I/O 争用。如果您使用的是 RAID 10 卷，那么您将获得更多，并且更好地使用 SSD(但之后您可能会遇到 storage-capacity 问题)。
如果有可能由不同的人上传相同的图像(在多个文件夹中复制)，那么您建议的方法将不是最节省空间的，在这种情况下，您最好通过数据函数进行键控(e.g .md5sum)并且只存储一个副本(是的，然后存在删除的管理问题)。
如果您期望来自许多人的大量图像，您最终将不得不考虑扩展底层存储。您可以通过{的某些功能对数据进行分区。 9}和不同卷或机器上的碎片。这也会为您带来更好的并发吞吐量。
另一个问题：你是否总是只提供原始图像，或者你有时会发回 re-scaled 份？您可能希望缩放一次并始终返回 pre-scaled 版本，在这种情况下，您还需要考虑这些缩放副本的存储。
3 回答
基本上你的方法很好，但这是我给你的建议：
不要使用文件名中的时间戳，因为您已经将文件名存储在数据库中，只需为时间戳<->文件关系创建额外的列。这样，它更容易管理诸如原始创建，上次修改甚至到期日期之类的事情。
确保您存储的文件名列是唯一的。你不想意外地存储重复的文件名
对接受文件进行交叉检查。如果文件已成功保存到服务器但查询失败，请确保在失败时删除该文件。或者，如果您的操作顺序相反，如果文件无法保存到服务器，请删除数据库中的条目。
如果不允许公开访问图像，则可以拒绝正常查看图像，而是将用户链接到文件名为 GET 变量的链接(PHP 文件)。然后，您可以检查 SESSIONS and/or COOKIES 以确定他们是否有权查看它。如果是，您可以将输出的标题设置为 jpeg 的标题或他们正在查看的任何类型的文件。
为什么不使用数据库中的唯一 ID，这样可以更容易地找到文件。
它也不限制你的文件结构，也许你不会总是想用用户名保存，如果每个文件都有一个绑定到数据库的 ID，这可能会简单得多。
有点取决于：
每个用户有多少张图片？
每张图片的大小范围？
有多少用户？
你期望什么样的并发？
如果上面的大部分数字都很小，那么你的方法可能会很长，足以让你有一个很长的路要走，并且至少会让你开始。
我知道使用 MySQL blob 存储获取坏新闻，但这也是一种简单的入门方式，你可以对数据库进行分片以获得一些 scale-out 而无需进行任何聪明的编码。
那说......
如果在您的系统中，您希望用户上传大量文件，则可能会遇到文件系统的限制或性能问题。
如果您在 Windows 上托管，请注意8.3 filename 问题(当目录变大时非常慢)，因为您的文件名肯定会长于 8.3 :)
如果很多人同时- 比如在高峰使用期 - 你将不得不注意 I/O 争用。如果您使用的是 RAID 10 卷，那么您将获得更多，并且更好地使用 SSD(但之后您可能会遇到 storage-capacity 问题)。
如果有可能由不同的人上传相同的图像(在多个文件夹中复制)，那么您建议的方法将不是最节省空间的，在这种情况下，您最好通过数据函数进行键控(e.g .md5sum)并且只存储一个副本(是的，然后存在删除的管理问题)。
如果您期望来自许多人的大量图像，您最终将不得不考虑扩展底层存储。您可以通过{的某些功能对数据进行分区。 9}和不同卷或机器上的碎片。这也会为您带来更好的并发吞吐量。
另一个问题：你是否总是只提供原始图像，或者你有时会发回 re-scaled 份？您可能希望缩放一次并始终返回 pre-scaled 版本，在这种情况下，您还需要考虑这些缩放副本的存储。