对象存储选型， SeaweedFS 和 CubeFS 选哪个？或者还有其他推荐的？

最省事的就是上云，阿里 oss 腾讯 tos 这些。自建和维护麻烦的很，用过 minio

我用 ceph 还可以，用成熟版本配置成熟硬件，维护量不大

七牛云、阿里 OSS 、自建 minio
别搞那些，一个人维护，集群 minio 就行

必须是 minio ，没别的选择

minio 最近开源功能收紧，需注意

minio 老版本的？

SeaweedFS 主要还是图片或其他非经常修改的对象，如果经常更改，可能并不如 minio 功能完善。

生产环境，存储这种底层的东西，最好用公有云，如果不行就采用多服务器集群部署，千万别弄容器化、k8s 部署，到时死都不知道咋死的

各位的建议已收到，感谢。目前基于数据安全的考虑，不会使用公有云 oss 这种的服务。所以更倾向于自建多服务器集群部署。

minio 最开始就看过了，软件协议商用不友好、许可证又太贵了（年费估计七十万）。另据说前几天 minio 删减了 WebUI 的相关功能。

所以目光才转向 SeaweedFS 。刚才看了同程旅行对象存储使用 SeaweedFS 的案例，感觉还不错。

https://mp.weixin.qq.com/s?src=11&timestamp=1749694141&ver=6047&signature=ZKsRdZox-D96YFSr3Frsk5mdgStIKdJYSIR2sN95uLxgseB1CnAx8ZlGzjjI3SHGOv5FUkgtMzuF1INJn48vNVQGFEaZOOpOSWGfhBV-tZEZlFl*Vv-BJdJoE4j6*5GG&new=1

seaweedfs 适合大量小文件，性能是 minio 的几十倍。
minio 适合大文件。它是个黑盒，一旦量大了就懵逼，没任何流量的情况下都能给你磁盘 io 打满。

OpenStack Swift 对象存储用了挺久一段时间, 种种原因最终迁移到 AWS S3

seaweedfs 唯一的缺点是不支持版本管理

如果需要使用 swaweedfs 纠删码功能，建议先仔细测试一轮。几年前做过一轮测试，功能不是太稳定，容易产生冗余的脏数据，需要做额外的监视和维护工作。不过这个模块最近已经被大改了一轮，看日志应该是比之前好些了。

下午又写了个简单的测试页面，用来测试 seaweedfs 。

https://github.com/luminecs/seaweedfs-uppy-manager
https://github.com/luminecs/seaweedfs-script

@knives 是的，需要仔细测试一下

@wjx0912 只能手动更新、重新部署吧

@chocotan 感谢分享

@linuxsir2020 云服务暂不考虑了

@niz
我们用 seaweedfs 的一些坑：
1. seaweedfs 的 EC 坑很多——比如不支持 ttl （提了 pr 现在支持了），并且如果用机械盘的话，EC 速度是赶不上文件上传的速度的。我们后来参考 go 源码另外开发了 java 的 ec 任务。还有诸如 EC 后文件删除无法释放空间等问题。
2. 内部大量用到了锁，有几个地方有性能问题，还有并发读写 map 导致 panic 崩溃的问题。
3. 在大量文件写入的情况下，master 节点会突然触发选举，且其选举非常慢——超过 30 秒，且保证可用性的话需要准备两个集群
4. 有大量文件写入、新 volume 生成频繁的时候，创建 volume 的速度赶不上文件写入的速度。

@chocotan 感谢分享这些有价值的经验，接下来可以带着这些问题看文档+实践了。另外有几个问题需要咨询下：

1. 这些坑大概是在 seaweedfs 哪些版本上出现的？不知道最新版本是否已经解决其中某些问题。
2. 针对 EC 速度是赶不上文件上传的速度，你们开发了 java 的 ec 任务，把 seaweedfs 默认的 ec 接管了？这部分 java 代码有开源吗？
3. 针对 EC 后文件删除无法释放空间，请问你们是如何处理的？
4. 既然 EC 有这么多潜在问题，是否可以用副本复制代替 EC ？你们有测试过副本复制吗？
5. 锁的问题估计需要作者来处理了，短期内很难了解源码
6. master 选举慢的问题，需要准备两个集群指的是两个 master 集群？这两个 master 集群后面还是使用相同的 volume server 、filer server 、s3 server?
7. 针对创建 volume 的速度赶不上文件写入的速度，不知道 weed 有没有预创建 volume 的配置。

目前文档还没有看一遍，理解比较浅，还请不吝赐教啊。

* 坑主要与 EC 有关，其中一部分功能提交 pr 给官方了。我们是从去年这个时候 fork 出来做的二次开发，期间经历了多次集群突然崩溃、突然选举导致服务中断等问题，直到现在才勉强稳定运行。后来我们试图合并官方的代码，发现创建新 volume 的功能疑似被其他人负优化了，就没继续合并了。

* EC 后文件被删除了空间无法释放的问题，我们目前是简单的做了判断——判断 volume 里所有文件都被删除后再删除该 volume 的文件

* Java 版的 EC 我们目前暂时没有精力单独开源出来，等集群稳定后再考虑。

* 一个集群的 master 节点数量设置成 3 个，5 个会增加超时概率，超时了就会触发选举。我们是搭建了两个完全独立的集群，一个无法提供服务的时候会自动切换到另一个

* weed 有预创建 volume 的，但是当 collection 数量过多+高并发的时候，由于它创建 volume 是串行处理、且每创建一个 volume 耗时在百毫秒左右，会导致一部分请求超时（ 10 秒超时）。业务应用需要做重试。

* 副本复制可以，如果空间足够的话建议不要做 EC 。

=========
就在刚刚，我们又发现了一个极端情况下返回上传成功实际文件上传失败的 BUG （与 EC 有关），造成一集群近几个月约 10%共上百 TB 的文件丢失了，这个 BUG 仍然存在于官方的最新版里。

@niz

我都是 webdav

@chocotan 十分感谢，这么看来 EC 问题真不少