登录
首页 >  Golang >  Go问答

处理图像和视频上传到存储服务器的方法

来源:stackoverflow

时间:2024-03-06 20:54:26 415浏览 收藏

golang学习网今天将给大家带来《处理图像和视频上传到存储服务器的方法》,感兴趣的朋友请继续看下去吧!以下内容将会涉及到等等知识点,如果你是正在学习Golang或者已经是大佬级别了,都非常欢迎也希望大家都能给我建议评论哈~希望能帮助到大家!

问题内容

我正在开发一个应用程序(用 Go 或可能用 PHP),用户需要上传照片和图像。

我已经在不同位置设置了几个 ZFS(镜像)存储服务器,但我对如何让用户最好地上传文件有疑问。 ZFS 处理配额和预留。

我在所有服务器上运行复制的 Galera 数据库,这既是为了安全,也是为了方便地从每台服务器访问用户帐户。换句话说,每台服务器始终都有数据库的本地副本。所有用户都是虚拟用户。

到目前为止,我已经测试了以下设置选项:

解决方案1

在具有虚拟用户的存储服务器上运行 SFTP(带模块的 ProFTPD)或 FTPS(带 TLS 的纯 FTP)。

这使人们可以使用 Filezilla 等客户端直接访问存储服务器。同时,用户还可以使用我们的 Web GUI 从我们的主 Web 服务器上传。

此设置的一个优点是 FTP 服务器可以处理虚拟用户。我们的网络应用程序还将通过 SFTP 或 FTPS 发送文件。

一个缺点是 FTP 很糟糕,对防火墙来说很烦人。另外,我更喜欢 FTP over SSH (SFTP),而不是 FTP over TLS (FTPS)。然而,只有 ProFTPD 具有 SSH 模块,但与 PureFTPd 相比,它的使用确实很痛苦(许多非工作配置选项和文件权限错误的问题),但 PureFTPd 只支持 TLS。

使用真正的 SSH/SCP 帐户运行并使用 PAM 不是一个选项。

解决方案2

使用 NFS 或 CIFS 将存储服务器本地安装在 Web 服务器上(Samba 非常擅长在设备出现故障时自动恢复)。

在此设置中,用户只能通过我们的主网络服务器上传。 Web 服务器应用程序以及在存储服务器上运行的应用程序需要支持可断点续传上传。我一直在研究使用 tus 协议。

上述两种设置的缺点是需要以某种方式管理存储容量。当存储服务器 1 达到其最大用户数时,应用程序需要知道这一点,然后仅为存储服务器 2、3 等创建虚拟用户。

我计算了每个存储服务器可以容纳多少用户,然后让 Web 应用程序检查虚拟用户的数据库,看看何时需要将新创建的用户移动到下一个存储服务器。

这是相当老派的方法,但它确实有效。

解决方案3

与解决方案 2 相同(无 FTP),但克隆我们的 Web 应用程序,将内容上传到每个存储服务器,然后重定向用户(或为他们提供指向存储服务器、s1.example.com、s2.example.com 的物理链接)。 com 等)

此设置的可能优点是用户可以直接上传到他们分配到的存储服务器,而不是通过我们的主 Web 服务器(防止它成为可能的瓶颈)。

解决方案4

在存储服务器上使用GlusterFS,构建一个易于扩展的集群。我已经测试了 GlusterFS,它非常适合此目的。

此设置的优点是,我实际上不需要关心文件在哪些存储服务器上的物理位置,并且我可以通过向集群添加更多服务器来轻松扩展存储。

但是,这里的缺点是我们的主 Web 服务器可能会成为瓶颈。

我还考虑过添加负载均衡器,然后使用多个 Web 服务器,以防我们的主 Web 服务器成为上传文件的瓶颈。

无论如何,我更喜欢保持简单!我不喜欢添加东西。从长远来看,我希望它易于维护。

任何想法、建议和忠告都将不胜感激。

你是怎么做到的?


解决方案


如果我们谈论文件存储,web 应用程序应该不知道底层存储;关注点分离。

另一方面,(s)ftp(s) 不是一种存储方法。它是一种通信协议。它并不妨碍您拥有共享存储。见上文。

zfs 不具备共享存储功能,因此您基本上可以进行以下选择:

  1. 哪个底层文件系统?
  2. 我想通过 (s)ftp(s) 提供额外的访问模式吗?
  3. 如何使我的文件系统在多个服务器上可用? glusterfs、cifs 还是 nfs?

那么,让我们来看看这个问题。

文件系统

我知道 zfs 很有趣,但事情是这样的:例如,xfs 的最大文件系统大小已经是 8 exbibytes 减去 1 个字节。对此的专业术语是“a s...load”。给你一个关系:国会图书馆拥有大约 20tb 的数字媒体 - 可以容纳大约 40 万次。即使是好的 ext4 也可以容纳 50k loc。如果你持有那么多数据,那么你的 fs 就是你最不关心的问题。建造接下来的几个发电厂来让你的东西继续运转大概是这样。

要点 很高兴想到,但使用任何你觉得舒服的东西。我个人几乎所有事情都使用 xfs(在 lvm 上)。

其他访问方法

当然可以,为什么不呢?除了安全噩梦(权限升级,有人吗?)。 proftpd 及其内置咖啡机和厨房水槽是我用于任何用途的最后 ftp 服务器。它有一个巨大的代码库,相当于 accidentally introducing vulnerabilities

基本上可以归结为项目中存在的技能。你们能否正确强化系统和 ftp 服务器并监控安全事件?除非你的回答是自信的“是的,ofc,有丰富的经验!”您应该最大限度地减少所呈现的攻击面。

要点不要这样做,除非你真的知道自己在做什么。如果你必须问,你可能不会。无意冒犯,只是陈述事实。

共享文件系统

就我个人而言,我使用 glusterfs 获得了……不太完美的体验。当涉及到网络延迟等时,复制有相当多的要求。简而言之:如果我们谈论多个可用区,例如 emea、apac 和 ncsa,那几乎是不可能的。您将不得不使用 georeplication,这对于您描述的用例来说不太理想。

另一方面,nfs 和 cifs 存在根本没有复制的问题,并且所有客户端都需要访问同一服务器实例才能访问数据 - 如果您认为需要底层 zfs,那么这并不是一个好主意相处。

要点全球范围内的共享文件系统,其复制延迟和访问时间都还算不错,非常很难做到,并且可以 非常昂贵。

哈哈,smartypants,那么你有什么建议?

规模。慢慢地。一开始,您应该能够使用基于 fs 的简单文件存储库。然后检查大规模共享存储的各种其他方法并迁移到它。

转向实现,我什至会更进一步,你应该让你的存储成为一个接口:

// storer takes the source and stores its contents under path for further reading via
// retriever.
type storer interface {
    streamto(path string, source io.reader) (err error)
}

// retriever takes a path and streams the file it has stored under path to w.
type retriever interface {
    streamfrom(path string, w io.writer) (err error)
}

// repository is a composite interface. it requires a
// repository to accept andf provide streams of files
type repository interface {
    storer
    retriever
    close() error
}

现在,您可以非常轻松地实现各种存储方法:

// FileStore represents a filesystem based file Repository.
type FileStore struct {
    basepath string
}

// StreamFrom statisfies the Retriever interface.
func (s *FileStore) StreamFrom(path string, w io.Writer) (err error) {

    f, err := os.OpenFile(filepath.Join(s.basepath, path), os.O_RDONLY|os.O_EXCL, 0640)
    if err != nil {
        return handleErr(path, err)
    }
    defer f.Close()
    _, err = io.Copy(w, f)
    return err
}

就我个人而言,我认为这对于 GridFS 来说是一个很好的用例,尽管它的名字不是文件系统,而是 mongodb 的一个功能。至于原因:

  1. mongodb 提出了一个称为副本集的概念,通过服务器之间透明的自动故障转移来确保可用性
  2. 它配备了一种相当简单的自动数据分区机制,称为分片集群
  3. 它配备了无限数量的名为 mongos 查询路由器的访问网关,用于访问您的分片数据。
  4. 对于客户端来说,除了连接 u​​rl 之外,所有这些都是透明的。因此,无论存储后端是由单个服务器还是由 600 个节点的全局复制分片集群组成,都没有什么区别(几乎除了 read preferencewrite concern 之外)。
  5. 如果操作正确,就不会出现单点故障,您可以跨可用区进行复制,同时保持“热”数据靠近各个用户。

我创建了一个 repository on GitHub,其中包含接口建议的示例,并实现了基于文件系统的存储库以及 mongodb 存储库。您可能想看一下。目前它缺乏缓存。如果您希望看到该实施,请在那里提出问题。

终于介绍完啦!小伙伴们,这篇关于《处理图像和视频上传到存储服务器的方法》的介绍应该让你收获多多了吧!欢迎大家收藏或分享给更多需要学习的朋友吧~golang学习网公众号也会发布Golang相关知识,快来关注吧!

声明:本文转载于:stackoverflow 如有侵犯,请联系study_golang@163.com删除
相关阅读
更多>
最新阅读
更多>
课程推荐
更多>