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