EventStore文件存储设计详解(2)

•事件索引：eventIndex，单条数据的结构：

{
 "aggregateRootId": "",   //聚合根ID
 "eventVersion": "",    //事件版本号
 "eventTime": "",      //事件产生时间
 "eventPosition": "",    //事件在事件数据文件中的位置
}

•命令索引：commandIndex，存储内容：存储所有命令的ID及其对应的事件所在文件的位置

{
 "commandId": "",    //聚合根ID
 "commandTime": "",   //命令产生时间
 "eventPosition": "",  //事件在事件数据文件中的位置
}

3、事件数据存储

•同步顺序写eventDataChunk文件，一个文件大小为1GB，写满一个文件后写入下一个文件；
•写入每个事件时，同时写入当前事件的前一个事件所在的文件位置，以便将来可以一次性将某个聚合根的所有事件从文件查找出来；

4、事件索引存储

•异步顺序写eventIndexChunk文件，一个文件大小为1GB，写满一个文件后写入下一个文件；
•对于已经写满的不会再变化的文件的内容，使用后台线程进行B+树索引整理，索引的排序依据是聚合根ID+事件版本号；B+树设计为3层，根节点包含1000个子节点，每个子节点再包含1000个子节点，这样叶子节点共有100W个。每个叶子节点我们保存20个版本索引，则单个文件共可保存最多2000W个版本索引，10个文件为2亿个版本索引；单机存储2亿个事件索引，应该可以满足大部分应用场景了；3层，则查找任意一个节点，只需要3次IO访问；
•由于是后台线程对已经写完的文件进行B+树索引整理，B+树是在内存建立，建立完成后，将最新的内容写入新文件，原子替换老的eventIndexChunk文件；所以，这块的逻辑处理应该不会对服务的主逻辑产生较大的影响；
•采用BloomFilter优化查询性能，使用BloomFilter来快速判断某个eventIndexChunk文件中是否包含某个聚合根ID，如果不在，则不用从B+树去检索该聚合根的版本号了；如果在，则取检索；通过这个设计，当我们要获取某个聚合根的最大版本号时，不需要对每个eventIndexChunk文件进行B+树查询，而是先通过BloomFilter快速判断当前的eventIndexChunk文件是否包含该聚合根的信息，大大提升检索效率；BloomFilter的二进制Bit数据占用内存小，可以在每个eventIndexChunk文件被扫描时，和文件头的信息一起加载到内存；

5、命令索引存储

•异步顺序写commandIndexChunk文件，一个文件大小为1GB，写满一个文件后写入下一个文件；
•同事件索引存储，进行B+树索引建立，索引的排序依据是命令ID；
•同事件索引存储，采用BloomFilter优化查询性能；