漫谈分布式文件存储系统的好与坏

        今天跟同事讨论分布式文件存储系统，说到如何评价一个系统的好与坏，一时还真觉得不太好评判。当然了系统本身的伸缩性、可用性肯定要好，否则无法长期投入稳定运营的，毕竟业务，特别是互联网业务经常会有快速增长或者快速萎缩的现象以及7*24小时不间断服务的需求。那么除了这两个以外，如何评判好与坏呢？实际上很多系统都有自己适用的场景，即使再通用的系统，也总有一些场景表现不如人意。系统支持的功能，以及每种功能接口所表现出来的性能应该是一个比较好的评判标准。那么其实我们可以拿posix文件系统接口作为标准参照物。假想一种场景，所有这些分布式文件存储系统都尽可能实现posix文件系统接口的一个子集，那么我们就可以根据每个系统实现的子集接口的数量，以及每个接口的调用性能来综合确定系统的好与坏。比如目录文件遍历，比如大文件读写，比如大量小文件读写，比如文件查找，比如删除文件，比如拷贝文件，比如访问控制等等操作，在这个标准面前，其实很多所谓的高性能的分布式文件存储系统都将现出原形，因为它们在实现的时候往往忽略了甚至是摒弃了这些考虑。

        在一些传统的文件系统（比如ext3/4，reiserfs等）里面，是需要考虑到一些极端情况的，比如单个文件很大很大，达到TB量级，比如文件很小很小，小到只有几十个字节，又或者一个目录下有很多很多文件，达到百万数量级，再者目录层次比较深，达到了数十层等等，这些极端情况都是文件系统应该考虑的问题，至少需要在一个合理的响应时间内完成操作。而大部分分布式文件存储系统往往达不到这些极端条件的要求，只要出现其中一个，也许就会出现意外情况，甚至严重得几乎不可服务。另外，大部分的分布式文件存储系统都没有实现分布式事务，因为分布式事务会造成整体吞吐量下降，所以这样也会导致数据一致性更容易遭到破坏，多个并发的请求有可能互相影响，导致数据最终状态难以确定。大部分这类系统还会采用信令与数据相分离的架构，一方面减轻了中心服务器的负担（只处理元数据），另一方面也缩短了数据传输的路径（客户端直连存储服务器）。但是由于网络的不稳定性和存储服务器的不可靠性（基本上都是采用廉价的PC服务器做存储），那么其实是会增加系统总的交互次数，从而某些情况下效率下降。另外很多系统在多副本机制下，往往一个副本会比较脆弱，且损坏的时候得通过其他远程副本来缓慢恢复，副本自身的保护与恢复能力也是比较差的。虽然在分布式环境下少数副本节点的故障不会影响全局，但是对于被故障节点所处理的请求将会是确定性的受影响，甚至出现数据丢失风险（特别是在异步复制副本的情况下）。

        如何实现较完善的机制去克服以上这些困难，也许才是作为综合评判系统到底是好还是坏。如果只是在特定场景下表现良好而已，那么只能说它与业务已经有较大的耦合。只要换一个业务，也许就表现没那么好了。当然，我们可以通过定制的方法构建多个不同的系统，以应对不同种类的业务，但是这又绕回到开头的问题，很难比较系统的好与坏。。。