3 回答
TA贡献1796条经验 获得超7个赞
选项1
原因:
您没有保留文件,因此保留到磁盘的用途有限
数据量很小,所以下载失败的可能性很小,如果发生,重新创建输出的处理时间最短(我假设这是一个快速的 SQL 查询?)
将文件保存在存储中为文件复制创造了机会,您将来可能设置的增量备份或 rsync 可以在敏感文件被删除之前复制它们......
从文件系统中删除文件并不一定会使数据不可恢复
如果您正在处理数十/数百 MB 的文件,我的想法会有所不同......
TA贡献1995条经验 获得超2个赞
让我们考虑所有选项,
选项 1是一个很好的解决方案,因为您没有存储文件。它会比其他人更安全。但是在高流量时超时可能是一个问题。
选项 2也是删除的好解决方案。但是您需要创建具有唯一名称的文件,以便您可以使用并行下载。
选项 3类似于选项 2,但如果您使用的是 laravel,请不要使用它。(想想2个人同时下载)
在此解释之后,如果您使用的是一台服务器,您需要处理选项 1 以使其更安全。但是,如果您使用的是微服务,则需要处理选项 2。
我可以再建议一件事来确保它的安全。创建一个唯一的散列 URL。例如,使用时间戳并将其与 laravel 哈希并在 URL 之前检查它们。所以人们不能从下载历史中再次下载。
https://example.com/download?hash={crypt(timestamp+1min)}
如果 1 分钟内未下载,则 URL 将过期。
TA贡献1828条经验 获得超4个赞
我认为回复取决于当前架构和要下载的文件大小
(1) 第一种方法适用于以下情况:
如果文件很小(小于 10 Mb)谢谢@tanerkay
你有简单的架构(例如1台服务器)
原因:
没有下载失败——无需重试
把事情简单化
没有文件 = 没有备份,没有 rsync,也没有其他地方可以窃取它
. . .
(2) 第二种方法适用于以下情况:
如果您的文件很大 (10+ Mb)
如果您已经拥有具有多个平衡加载器的微服务架构 - 保持相似性
如果您有数百万用户尝试下载 - 如果没有平衡加载器和并行下载,您将无法为他们提供服务
原因:
第二种方法肯定更具可扩展性,因此在高负载下更稳定,因此更安全。对于繁重的负载,微服务更耗时且更具可扩展性。
使用单独的文件存储允许您在将来拥有单独的文件服务器和负载平衡以及队列管理器和单独的专用访问控制。
如果内容很重要,通常意味着获取它对用户来说非常重要。但是带有标头的直接输出可能会挂起或出现超时错误等。我认为将文件保存到下载之前是更可靠的交付方法。
尽管如此,我还是会考虑到期时间而不是下载事实——下载过程可能会失败,或者文件丢失(确保 1 小时以上的可用性),反之亦然,用户将仅在 1 年后尝试下载它,或者永远不会—— - 为什么要保存这个文件超过 N 天?
- 3 回答
- 0 关注
- 257 浏览
添加回答
举报
