本来本篇是想介绍前端组件化开发用户界面，发现框架还未实现文件存储，原本计划是后续设计开发的，索性把计划提前，所以本篇将介绍基于Raft实现分布式的文件存储引擎。

一. 实现思路

既然是分布式存储，就需要解决以下几个关键问题：

• 如何将文件以多副本的形式存储在集群的节点上，且保证副本间的一致性？这个问题可基于Raft协议实现相应的状态机来解决；
• 如何将大量的文件分组，即如何划分多个Raft组？这个问题可通过在目录元数据内保存多个Raft组信息，每个组存储限制在64M（暂定）来解决；
• 如何存储与管理目录及文件的元数据？这个问题可通过实现元数据状态机来管理，利用已实现的KV存储引擎来存储元数据；
• 如何保证元数据与文件数据的一致性？这个问题开始时想用已实现的EntityStore的事务引擎来解决，虽能保证强一致性但逻辑复杂，性能损失大。因此放弃了强一致性改为保证最终一致性，元数据状态机及文件状态机内都有定时器来检查不一致的状态。

1. 元数据存储-BlobMetaStateMachine

  开始时想设计为一个集群对应一个BlobMetaRaftGroup，后来考虑到单个RaftGroup可能会压力较大，所以改为每个Application对应一个BlobMetaRaftGroup。每个元数据状态机主要存储以下各项信息：

• 目录元数据：包括目录名称及标识，该目录下分配了多少个Chunk，每个Chunk占用了多少空间，隶属于哪个RaftGroup等；
• 文件元数据：包括文件名称及标识，该文件隶属的目录标识及隶属的ChunkRaftGroup标识等；
• Chunk元数据： 包括Chunk的RaftGroup内的各个RaftNode分配在集群的哪个节点上；
• 写锁数据：用于并发写时加锁。

2. 文件存储-BlobChunkStateMachine

  根据上述设计，每个目录下的文件分成了多个存储（BlobChunkRaftGroup），本来想用MemoryMapFile来实现底层Chunk存储，但考虑到有更重要的功能要实现所以暂偷懒直接利用Linux文件系统来存储文件，状态机Apply文件写命令时，将文件直接写入节点运行时blob/ChunkRaftGroupId/目录下。

3. 读写流程

• 读流程较简单: 发送读元数据命令至BlobMetaRaftGroup获取文件元数据（缓存），然后再分小块发读命令至目标ChunkRaftGroup获取文件小块数据；
• 写流程要考虑元数据与文件数据的一致性，还要考虑在目录下无可用ChunkRaftGroup时创建新的组，具体参考以下设计草图：

二. 实现效果

  根据以上设计在经历了1个月的编码后已初步实现（其中约一半时间在更改架构，抛弃了Mono依赖，改为Hosting CoreCLR，性能提升1倍），在框架IDE内每个Application内有个"BlobStore"节点，如下图所示可测试上传文件，然后通过浏览器访问上传至/pub目录内的文件（http://{地址:端口}/blob/{app名称}/{文件路径} eg:

http://xx.xx.xx.xx:5000/blob/sys/imgs/aa.jpg）

  作者简单测试了一下通过框架WebHost下载文件(约60K大小)的性能(测试时尚未实现缓存元数据, 虚拟机I74C8G)，如下图所示：

三. 本篇小结

  本实现适用于存储大量小文件，如业务单证的附件，或者用于OA系统作为文档库。目前只是实现了基本的上传下载功能，删除、重命名、Chunk合并等功能尚未实现，另待将来框架实现反向索引后再实现全文搜索功能。如果您有问题或Bug报告，请留言或在Github提交Issue。