php - 处理用户图片上传的推荐架构

Question

过去，我以两种不同的方式处理用户图片上传：

• 将图像数据保存在数据库表中，并通过 PHP 脚本加载
• 上传图片，转成jpeg，放到目录下，通过HTML标签加载

第一个选项效果很好，但我必须对上传的图像保持相当严格的尺寸限制。第二种选择有效，除了 PHP 的图像库经常会破坏文件转换（但是我认为可以通过使用 ImageMagick 来解决）。

我现在面临第三次这样做，可能是更大规模的用户。我已经计划在上传后使用 ImageMagick 对图像进行一些后期处理。我希望尽量减少对图片上传的限制，甚至可能保留某人上传的每张照片。

有时，数百张用户上传的照片会同时以缩略图的形式显示在屏幕上。将这些存储在数据库中并为每一个提取它们并通过 PHP 显示似乎不是一个好方法，但是将所有图像放入一个目录也不是。

在这种情况下，您有什么建议？您选择上述选项之一还是有不同的解决方案？

Answer 1

将这些存储在数据库中并为每一个提取它们并通过 PHP 显示似乎不是一个好方法，但是将所有图像放入一个目录也不是。

您可以采用混合方法。

将图像存储在文件夹的层次结构中（根据您确定适合您的应用程序的任何方案）。将每个图像的完整路径存储在数据库中。

在后台作业中，生成图像的缩略图（例如使用 ImageMagick），其文件名与图像本身略有不同（例如：在前面添加“thumb-”）但与真实图像一起存储。您可以在数据库中为每个图像设置一个字段，这意味着“我的缩略图已准备好，所以请将我包含在画廊中”。

当您收到画廊请求时，使用数据库字段对图像组进行切片和切块，然后生成一段 HTML，它引用适当的缩略图和图像路径。

---

编辑： 当您需要处理大量请求时，Aaron F 所说的很重要。对图像/sql 数据进行分区是实现可扩展性的好方法。您需要查看应用程序中的访问模式以确定分区点的位置。您可以更快地做的事情是为画廊缓存生成的 HTML，以减少 SQL 负载。

Answer 2

您引用的两个示例并未阐明最重要的部分：分区。

例如，如果存储在数据库中，图像是否完全驻留在一个表中，在一个数据库服务器上？或者表是否跨多个服务器/集群分区？

例如，如果存储在一个目录中，所有图像是否都驻留在一个硬盘上？或者图像是否根据用户登录名中的第一个字母映射到单独的 [RAID] 驱动器？

可扩展性需要良好的分区方案。

至于批量显示缩略图，您可能需要在这里进行一些预计算。即创建缩略图（可能通过异步作业，在图像上传后立即开始）并将它们放在专用服务器上。这就是 Youtube 对上传视频进行图像快照的方式。

Answer 3

几年前，我编写了一个 Intranet 图像存档，旨在最终存储大约 340,000 张扫描和相关缩略图。谷歌搜索我发现，只要您不要求底层操作系统进行文件夹列表，就没有理由不将它们全部转储到单个目录中。换句话说，调用 ls/dir 会挂起机器，但仅通过文件名（从数据库）检索单个图像文件不会意味着性能损失。

该存档已经运行了几年，我可以确认它适用于实际存储在文件夹中的超过 60k 图像。

我从来没有遇到过使用 GD 将内容转换为 jpeg 的任何问题，但是对于那项特殊的工作，我使用了 ImageMagick 方式，使用MagicWand作为辅助扩展（主要是因为有体面的文档）。

Answer 4

恕我直言，大卫的解决方案在大多数情况下是最好的，但我会修改两个细节：

将每个图像的完整路径存储在数据库中。

我认为您不需要存储完整路径，因为如果由于某种原因图像目录发生更改，那会使您的生活变得有点复杂。只存储文件名就足够了。您始终可以直接在 html 中包含完整路径。

具有生成的图像的缩略图（例如使用 ImageMagick），其文件名与图像本身略有不同，但与真实图像一起存储。

我更喜欢将缩略图放在不同的目录中，您创建的每个缩略图都有一个目录，并且文件名完全相同。我曾经在一个拥有数千个用户图像的网站上工作，但我犯了将它们都放在同一个目录中的错误。该目录增长得如此之快，以至于几乎不可能在不等待几分钟的情况下打开该目录。

PHP 的图像库经常会搞砸文件转换

我建议在您创建拇指的脚本中增加内存限制，特别是如果您允许上传大 (2mb+) 文件。

您可以使用ini_set('memory_limit', '30M');. 当然，实际数量取决于您。30M 在缩略图密集的网站中为我工作过。

Answer 5

这个问题是 11 年前提出的，它仍然非常相关并指导开发人员设计图像管理策略。我今天想加我的 2 美分，并指出可以使用的新技术。

我会根据我将获得的流量规模来设计我的策略。让我用以下案例来解释。

案例 1：本地或区域交通
主要交通来源：公司内部，特定省/国家
可预测系数： 6-7/10。上线后改善
金钱因素：免费或负担得起的定价

在这种情况下，混合解决方案可能是最佳解决方案。在这里你有以下选择

• 1. 您可以创建自己的解决方案并管理服务器上的图像，并将它们的位置或文件名存储在数据库中。
• 2. 第二种选择是使用图片托管网站，如postimage、cubeupload、dropbox、google photos、imgbox、cubeupload。它们为您提供访问图像的链接和/或您可以将代码嵌入您的网络应用程序或博客中。大部分是免费的，存储空间有限。付费选项也非常实惠。
• 3. 他们唯一需要注意的是带宽。当您遇到非常高的点击率时，您需要考虑到这一点。
• 4. 您还可以使用选项 1 和 2 使用混合方法 。back2dos、David-SkyMesh、djn、Alejandro Zuleta 和 Aaron Fi的回答很好。

案例2：全球流量
主要流量来源：全球。
可预测性因素： 0/10。上线后学习
金钱因素：昂贵

这是一个严肃的用例，您必须注意两个最重要的因素，可扩展性和安全性。Aaron Fi指出关于分区，我将建议以下方法。

• 1. 使用图像 CDN。这些是专门的 CDN，您可以管理、调整大小、转换和保护图像。可扩展性由服务提供商提供，因此您不必担心太多。一些服务提供商是cloudimage、imgix、imagekit。
• 2. 您还可以使用云服务来管理您的图片，例如 Amazon S3。服务提供商也在后端使用此类云服务。
• 3. 此选项并不便宜，请检查每月流量数据并计算您的每月使用量。这是图像重网站的最佳选择。

希望这会有所帮助。

Answer 6

嗯，用于创建缩略图，使用phpthumb ......它绝对是完美的......并且有一些额外的东西，但你可能不需要那些......它会自动在你的文件系统上创建一个本地缓存，所以它是非常节省资源...

我认为，混合方法可能是最具可扩展性的，即将文件存储在文件系统上并将文件位置存储在数据库中......这样，您可以将一些元数据与文件一起存储（如创建者、标题、标签等），并保持您的数据库很小......另外，您可以将图像存储在任意位置（甚至在其他机器上等），因此您可以轻松分发所有有效负载......

问候

back2dos

Answer 7

如果你问我，我会使用Thumbnailer类。