EventStore文件存储设计

背景

ENode是一个CQRS+Event Sourcing架构的开发框架，Event Sourcing须要持久化事件，事件能够持久化在DB，可是DB因为面向的是CRUD场景，是针对数据会不断修改或删除的场景，因此内部实现会比较复杂，性能也相对比较低。而Event Store实际上对数据只有新增和查询的需求，因此我想为Event Sourcing的场景针对性的实现一个Event Store。看了一下业界的一些实现，感受都没有达到个人指望，因此想本身动手实现一个。下面是我构思的一个Event Store的单机版应该要具有的能力以及对应的设计方案，分享出来和你们讨论。

1、需求概述

• 存储聚合根的事件数据
• 支持事件的版本并发控制，新事件的版本号必须是当前版本号+1
• 支持命令重复判断，即不能够处理重复命令产生的事件
• 支持按聚合根ID查询该聚合根的全部事件
• 支持按聚合根ID+事件版本号查询指定的事件
• 支持按命令ID查询该命令对应的事件数据
• 高性能，写入要尽可能快，查询要尽可能快

2、事件数据格式

{
  "aggregateRootId": "",     //聚合根ID
  "aggregateRootType": "",   //聚合根类型
  "eventVersion": "",        //事件版本号
  "eventTime": "",           //事件发生时间
  "eventData": "",           //事件数据，JSON格式
  "commandId": "",           //产生该事件的命令ID
  "commandTime": ""          //产生该事件的命令产生时间
}

3、存储设计

一、核心内存存储设计

• 遵循内存只存储索引数据的原则，尽可能充分利用内存；
• aggregateLatestVersionDict，存储每一个聚合根的最大事件版本号
  • key：aggregateRootId，聚合根ID
  • value：
    • eventVersion，当前聚合根的最新事件的版本号，也即当前聚合根的版本号
    • eventTime，事件产生时间
    • eventPosition，事件在事件数据文件中的位置
• commandIdDict，存储命令索引
  • key：commandId，命令ID
  • value：
    • commandTime，命令产生时间
    • eventPosition，命令对应的事件在事件数据文件中的位置

二、物理存储的数据

• 事件数据：eventData，单条数据的结构：

{
  "aggregateRootId": "",     //聚合根ID
  "aggregateRootType": "",   //聚合根类型
  "eventVersion": "",        //事件版本号
  "eventTime": "",           //事件发生时间
  "eventData": "",           //事件数据，JSON格式
  "commandId": "",           //产生该事件的命令ID
  "commandTime": "",         //产生该事件的命令产生的事件
  "previousEventPosition": ""//前一个事件在事件文件中的位置
}

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

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

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

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

三、事件数据存储

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

四、事件索引存储

• 异步顺序写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文件被扫描时，和文件头的信息一块儿加载到内存；

五、命令索引存储

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

4、框架逻辑设计

一、查询某个聚合根的最大版本号

• EventStore启动时，会加载全部的eventIndexChunk文件的元数据到内存，好比文件号、文件头、BloomFilter等信息，但不真实加载文件内容，文件数不会太多，最多也就几十个；
• 根据聚合根ID+BloomFilter算法，快速肯定应该到哪一个eventIndexChunk文件中去查找该聚合根的最新版本号，eventIndexChunk文件重新到旧遍历，由于某个聚合根ID的最大版本号必定是在最新的eventIndexChunk文件中的；
• 在找到的eventIndexChunk中使用B+树查找算法，找到对应的叶子节点；
• 在找到的叶子节点，使用二分查找算法（因为单个节点的聚合根ID很少，顺序查找便可），找到指定聚合根的最新版本号；

二、查询某个聚合根的全部事件

• 先经过上面的算法找出该聚合根的最大版本号的事件在事件数据文件中的位置；
• 而后从该位置获取事件完整数据；
• 再根据事件数据中记录的上一个事件在事件数据文件中的位置，查找上一个事件的数据；
• 以此类推，直到找到该聚合根的第一个事件的数据；

三、查询某个命令对应的事件数据

• 先尝试从内存查询该命令的索引信息，若是存在，则直接获取该命令对应的事件在事件数据文件中的位置，即eventPosition；若是不存在，则尝试从命令的索引文件中查找，结合BloomFilter和B+树查找算法进行查找；
• 若是找到了eventPosition，则根据eventPosition到事件数据文件中查找对应的事件数据便可；若是未找到，则返回空；

四、追加一个新事件的处理逻辑

• 根据aggregateLatestVersionDict判断事件版本号是否合法，必须是聚合根的当前版本号+1，若是当前版本号不存在，则首先尝试从eventIndexChunk文件查找当前聚合根的最大版本号，若是仍是查找不到，说明当前聚合根确实不存在任何事件，则当前事件版本号必须为1；
• 根据commandIdDict判断命令ID是否重复，若是commandIdDict中不存在该命令，尝试从commandIndexChunk文件中查找，也是B+树的方式；这里须要设计一个配置项，让开发者配置是否须要继续从commandIndexChunk文件查找命令ID。有时咱们只但愿从内存查找便可，不但愿再从磁盘查找了，由于判断命令是否重复咱们不少时候只但愿检查最近一段时间内的命令，检查所有命令代价过大，意义也不是很大；
• 若是事件的版本号合法、命令ID不重复，则Append的方式写入事件数据到eventDataChunk；
• 写入完成后，更新aggregateLatestVersionDict、commandIdDict，、BloomFilter的Bit数组，以及将当前的事件放入内存的一个双缓冲队列；队列消费者异步批量将事件索引和命令索引写入对应的索引文件；
• 返回事件写入结果；

五、其余逻辑

• 异步线程定时批量持久化事件索引；
• 异步线程定时批量持久化命令索引；
• 异步线程定时清理不须要放在内存的聚合根最新版本号信息（aggregateLatestVersionDict中的key），根据eventTime判断，只保留最近1周有过变化（产生过事件）的聚合根；
• 异步线程定时清理不须要放在内存的命令索引（commandIdDict中的key），根据commandTime判断，只保留最近1周的命令ID；
• 异步线程定时进行事件索引和命令索引的B+树索引的创建，即对已经写入完成的eventIndexChunk和commandIndexChunk文件的内部重构；
• eventIndexChunk和commandIndexChunk文件标记为写入完成前，要把BloomFilter的Bit数组内容写入文件中；
• 其余EventStore的启动逻辑，好比启动时加载必定数量的索引数据到内存，以及索引数据相比事件数据是否有漏掉或无效的检查；
• 其余逻辑支持，如支持聚合根的快照存储，从文件查找数据时，若是文件的B+树索引信息还未创建，则须要进行全文扫码；