AppBoxFuture: 基于Raft协议实现分散式小档案储存
本来本篇是想介绍前端元件化开发使用者界面，发现框架还未实现档案储存，原本计划是后续设计开发的，索性把计划提前，所以本篇将介绍基于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)，如下图所示：
