背景

ENode是一個CQRS+Event Sourcing架構的開發框架，Event Sourcing需要持久化事件，事件可以持久化在DB，但是DB由于面向的是CRUD場景，是針對數據會不斷修改或刪除的場景，所以內部實現會比較復雜，性能也相對比較低。而Event Store實際上對數據只有新增和查詢的需求，所以我想為Event Sourcing的場景針對性的實現一個Event Store。看了一下業界的一些實現，感覺都沒有達到我的期望，所以想自己動手實現一個。下面是我構思的一個Event Store的單機版應該要具備的能力以及對應的設計方案，分享出來和大家討論。

一、需求概述

• 存儲聚合根的事件數據

• 支持事件的版本并發控制，新事件的版本號必須是當前版本號+1

• 支持命令重復判斷，即不可以處理重復命令產生的事件

• 支持按聚合根ID查詢該聚合根的所有事件

• 支持按聚合根ID+事件版本號查詢指定的事件

• 支持按命令ID查詢該命令對應的事件數據

• 高性能，寫入要盡量快，查詢要盡量快

二、事件數據格式

{
"aggregateRootId": "", //聚合根ID
"aggregateRootType": "", //聚合根類型
"eventVersion": "", //事件版本號
"eventTime": "", //事件發生時間
"eventData": "", //事件數據，JSON格式
"commandId": "", //產生該事件的命令ID
"commandTime": "" //產生該事件的命令產生時間
}

三、存儲設計

1、核心內存存儲設計

• 遵循內存只存儲索引數據的原則，盡量充分利用內存；

• aggregateLatestVersionDict，存儲每個聚合根的最大事件版本號

  • eventVersion，當前聚合根的最新事件的版本號，也即當前聚合根的版本號

  • eventTime，事件產生時間

  • eventPosition，事件在事件數據文件中的位置

  • key：aggregateRootId，聚合根ID

  • value：

• commandIdDict，存儲命令索引

  • commandTime，命令產生時間

  • eventPosition，命令對應的事件在事件數據文件中的位置

  • key：commandId，命令ID

  • value：

2、物理存儲的數據

• 事件數據：eventData，單條數據的結構：

{
"aggregateRootId": "", //聚合根ID
"aggregateRootType": "", //聚合根類型
"eventVersion": "", //事件版本號
"eventTime": "", //事件發生時間
"eventData": "", //事件數據，JSON格式
"commandId": "", //產生該事件的命令ID
"commandTime": "", //產生該事件的命令產生的事件
"previousEventPosition": ""//前一個事件在事件文件中的位置
}

• 事件索引：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優化查詢性能；

四、框架邏輯設計

1、查詢某個聚合根的最大版本號

• EventStore啟動時，會加載所有的eventIndexChunk文件的元數據到內存，比如文件號、文件頭、BloomFilter等信息，但不真實加載文件內容，文件數不會太多，最多也就幾十個；

• 根據聚合根ID+BloomFilter算法，快速確定應該到哪個eventIndexChunk文件中去查找該聚合根的最新版本號，eventIndexChunk文件從新到舊遍歷，因為某個聚合根ID的最大版本號一定是在最新的eventIndexChunk文件中的；

• 在找到的eventIndexChunk中使用B+樹查找算法，找到對應的葉子節點；

• 在找到的葉子節點，使用二分查找算法（由于單個節點的聚合根ID不多，順序查找即可），找到指定聚合根的最新版本號；

2、查詢某個聚合根的所有事件

• 先通過上面的算法找出該聚合根的最大版本號的事件在事件數據文件中的位置；

• 然后從該位置獲取事件完整數據；

• 再根據事件數據中記錄的上一個事件在事件數據文件中的位置，查找上一個事件的數據；

• 以此類推，直到找到該聚合根的第一個事件的數據；

3、查詢某個命令對應的事件數據

• 先嘗試從內存查詢該命令的索引信息，如果存在，則直接獲取該命令對應的事件在事件數據文件中的位置，即eventPosition；如果不存在，則嘗試從命令的索引文件中查找，結合BloomFilter和B+樹查找算法進行查找；

• 如果找到了eventPosition，則根據eventPosition到事件數據文件中查找對應的事件數據即可；如果未找到，則返回空；

4、追加一個新事件的處理邏輯

• 根據aggregateLatestVersionDict判斷事件版本號是否合法，必須是聚合根的當前版本號+1，如果當前版本號不存在，則首先嘗試從eventIndexChunk文件查找當前聚合根的最大版本號，如果還是查找不到，說明當前聚合根確實不存在任何事件，則當前事件版本號必須為1；

• 根據commandIdDict判斷命令ID是否重復，如果commandIdDict中不存在該命令，嘗試從commandIndexChunk文件中查找，也是B+樹的方式；這里需要設計一個配置項，讓開發者配置是否需要繼續從commandIndexChunk文件查找命令ID。有時我們只希望從內存查找即可，不希望再從磁盤查找了，因為判斷命令是否重復我們很多時候只希望檢查最近一段時間內的命令，檢查全部命令代價過大，意義也不是很大；

• 如果事件的版本號合法、命令ID不重復，則Append的方式寫入事件數據到eventDataChunk；

• 寫入完成后，更新aggregateLatestVersionDict、commandIdDict，、BloomFilter的Bit數組，以及將當前的事件放入內存的一個雙緩沖隊列；隊列消費者異步批量將事件索引和命令索引寫入對應的索引文件；

• 返回事件寫入結果；

5、其他邏輯

• 異步線程定時批量持久化事件索引；

• 異步線程定時批量持久化命令索引；

• 異步線程定時清理不需要放在內存的聚合根最新版本號信息（aggregateLatestVersionDict中的key），根據eventTime判斷，只保留最近1周有過變化（產生過事件）的聚合根；

• 異步線程定時清理不需要放在內存的命令索引（commandIdDict中的key），根據commandTime判斷，只保留最近1周的命令ID；

• 異步線程定時進行事件索引和命令索引的B+樹索引的建立，即對已經寫入完成的eventIndexChunk和commandIndexChunk文件的內部重構；

• eventIndexChunk和commandIndexChunk文件標記為寫入完成前，要把BloomFilter的Bit數組內容寫入文件中；

• 其他EventStore的啟動邏輯，比如啟動時加載一定數量的索引數據到內存，以及索引數據相比事件數據是否有漏掉或無效的檢查；

• 其他邏輯支持，如支持聚合根的快照存儲，從文件查找數據時，如果文件的B+樹索引信息還未建立，則需要進行全文掃碼；

原文地址：https://www.cnblogs.com/netfocus/p/10861152.html

.NET社區新聞，深度好文，歡迎訪問公眾號文章匯總?http://www.csharpkit.com?
\

總結

以上是生活随笔為你收集整理的EventStore文件存储设计的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。