我们有一个 Web 服务，它需要一个与 POSIX 兼容的应用程序服务器共享文件系统(多个冗余系统在冗余负载均衡器后面并行运行(。我们目前正在运行 GlusterFS 作为应用程序服务器的共享文件系统，但我对系统的性能不满意。与运行 GlusterFS 的存储服务器的实际原始性能相比，运行 DRBD 和单个 NFS 服务器而所有其他 GlusterFS 服务器(当前为 3 台服务器(以热备用角色等待开始看起来更明智。
我们的工作负载是高度面向读取的，通常处理小文件，只要客户端可以在需要时请求同步单个文件(即客户端准备等到文件成功存储在后端存储中(，我很乐意使用"最终一致"系统。我什至会接受一个系统，其中这种"同步"需要通过 POSIXfdatasync()以外的其他方式查询文件的状态。修改时间等文件元数据并不重要，重要的是文件名和内容。
我目前知道可能的候选人以及每个人目前遇到的问题：
- GlusterFS：在实践中整体性能相当差，添加新服务器/砖块时性能下降。
- Ceph：配置/管理非常复杂，据我所知，POSIX 兼容性牺牲了很多性能。
- MooseFS：部分混淆的开源(大量内部编写的代码很少发布，故意丢失补丁历史记录(，文档还有很多不足之处。
- SeaweedFS：非常简单的设计和所谓的高性能，这个项目的未来尚不清楚，因为几乎所有代码都是由 Chris Lu 编写和维护的——如果他不再编写任何代码会发生什么？不清楚"文件管理器"组件是否不支持单点故障。
我知道CAP定理阻止了真正一致且始终可用的系统。对于分布式文件系统，是否有任何好的系统，其中写入必须持久，但读取性能确实很好并且系统没有单点故障？
我是Chris Lu，在SeaweedFS工作。有计划将其商业化。(通过添加更多高级功能。
文件管理器没有简单的故障点，您可以有多个文件管理器实例。文件管理器存储可以是任何键值存储。如果你不需要SPOF，你可以使用Cassandra，Redis集群，CockroachDB，TiDB或Etcd。或者您可以添加自己的键值存储选项，这非常简单。