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+樹索引信息還未創建，則須要進行全文掃碼；