chocotan

油甜辣都不要吃。
去专业皮肤科看看

v2raya
用很久了，没啥问题

对我来说是学习成本太高了，任何配置调整我都要去谷歌一下才知道怎么弄，而且记不住。比如我想改个启动参数，居然要去改配置文件......

不会
我之前看 spring boot 官方的视频教程就是 controller 直接调用 repository

报备两个月，连公司全称的签名都经常被拦截（提示没实名制报备），本来就是残废还继续折腾

我申请水星的时候被要求提供公司的地址证明，而中介不提供这个。
后来用申请 EIN 的文件（上面有地址）才通过了。（美国人效率是真的低，等 EIN 花了将近四个月）

来晚了，不行了已经

* 坑主要与 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

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