目錄
- 背景
- 一、需求概述
- 二、事件數(shù)據(jù)格式
- 三、存儲設(shè)計
- 1、核心內(nèi)存存儲設(shè)計
- 2、物理存儲的數(shù)據(jù)
- 3、事件數(shù)據(jù)存儲
- 4、事件索引存儲
- 5、命令索引存儲
- 四、框架邏輯設(shè)計
- 1、查詢某個聚合根的最大版本號
- 2、查詢某個聚合根的所有事件
- 3、查詢某個命令對應(yīng)的事件數(shù)據(jù)
- 4、追加一個新事件的處理邏輯
- 5、其他邏輯
背景
ENode是一個CQRS+Event Sourcing架構(gòu)的開發(fā)框架,Event Sourcing需要持久化事件,事件可以持久化在DB,但是DB由于面向的是CRUD場景,是針對數(shù)據(jù)會不斷修改或刪除的場景,所以內(nèi)部實現(xiàn)會比較復(fù)雜,性能也相對比較低。而Event Store實際上對數(shù)據(jù)只有新增和查詢的需求,所以我想為Event Sourcing的場景針對性的實現(xiàn)一個Event Store??戳艘幌聵I(yè)界的一些實現(xiàn),感覺都沒有達到我的期望,所以想自己動手實現(xiàn)一個。下面是我構(gòu)思的一個Event Store的單機版應(yīng)該要具備的能力以及對應(yīng)的設(shè)計方案,分享出來和大家討論。
一、需求概述
•存儲聚合根的事件數(shù)據(jù)
•支持事件的版本并發(fā)控制,新事件的版本號必須是當前版本號+1
•支持命令重復(fù)判斷,即不可以處理重復(fù)命令產(chǎn)生的事件
•支持按聚合根ID查詢該聚合根的所有事件
•支持按聚合根ID+事件版本號查詢指定的事件
•支持按命令I(lǐng)D查詢該命令對應(yīng)的事件數(shù)據(jù)
•高性能,寫入要盡量快,查詢要盡量快
二、事件數(shù)據(jù)格式
{
"aggregateRootId": "", //聚合根ID
"aggregateRootType": "", //聚合根類型
"eventVersion": "", //事件版本號
"eventTime": "", //事件發(fā)生時間
"eventData": "", //事件數(shù)據(jù),JSON格式
"commandId": "", //產(chǎn)生該事件的命令I(lǐng)D
"commandTime": "" //產(chǎn)生該事件的命令產(chǎn)生時間
}
三、存儲設(shè)計
1、核心內(nèi)存存儲設(shè)計
•遵循內(nèi)存只存儲索引數(shù)據(jù)的原則,盡量充分利用內(nèi)存;
•aggregateLatestVersionDict,存儲每個聚合根的最大事件版本號 ◦key:aggregateRootId,聚合根ID
◦value: ◦eventVersion,當前聚合根的最新事件的版本號,也即當前聚合根的版本號
◦eventTime,事件產(chǎn)生時間
◦eventPosition,事件在事件數(shù)據(jù)文件中的位置
•commandIdDict,存儲命令索引 ◦key:commandId,命令I(lǐng)D
◦value: ◦commandTime,命令產(chǎn)生時間
◦eventPosition,命令對應(yīng)的事件在事件數(shù)據(jù)文件中的位置
2、物理存儲的數(shù)據(jù)
•事件數(shù)據(jù):eventData,單條數(shù)據(jù)的結(jié)構(gòu):
{
"aggregateRootId": "", //聚合根ID
"aggregateRootType": "", //聚合根類型
"eventVersion": "", //事件版本號
"eventTime": "", //事件發(fā)生時間
"eventData": "", //事件數(shù)據(jù),JSON格式
"commandId": "", //產(chǎn)生該事件的命令I(lǐng)D
"commandTime": "", //產(chǎn)生該事件的命令產(chǎn)生的事件
"previousEventPosition": ""http://前一個事件在事件文件中的位置
}
•事件索引:eventIndex,單條數(shù)據(jù)的結(jié)構(gòu):
{
"aggregateRootId": "", //聚合根ID
"eventVersion": "", //事件版本號
"eventTime": "", //事件產(chǎn)生時間
"eventPosition": "", //事件在事件數(shù)據(jù)文件中的位置
}
•命令索引:commandIndex,存儲內(nèi)容:存儲所有命令的ID及其對應(yīng)的事件所在文件的位置
{
"commandId": "", //聚合根ID
"commandTime": "", //命令產(chǎn)生時間
"eventPosition": "", //事件在事件數(shù)據(jù)文件中的位置
}
3、事件數(shù)據(jù)存儲
•同步順序?qū)慹ventDataChunk文件,一個文件大小為1GB,寫滿一個文件后寫入下一個文件;
•寫入每個事件時,同時寫入當前事件的前一個事件所在的文件位置,以便將來可以一次性將某個聚合根的所有事件從文件查找出來;
4、事件索引存儲
•異步順序?qū)慹ventIndexChunk文件,一個文件大小為1GB,寫滿一個文件后寫入下一個文件;
•對于已經(jīng)寫滿的不會再變化的文件的內(nèi)容,使用后臺線程進行B+樹索引整理,索引的排序依據(jù)是聚合根ID+事件版本號;B+樹設(shè)計為3層,根節(jié)點包含1000個子節(jié)點,每個子節(jié)點再包含1000個子節(jié)點,這樣葉子節(jié)點共有100W個。每個葉子節(jié)點我們保存20個版本索引,則單個文件共可保存最多2000W個版本索引,10個文件為2億個版本索引;單機存儲2億個事件索引,應(yīng)該可以滿足大部分應(yīng)用場景了;3層,則查找任意一個節(jié)點,只需要3次IO訪問;
•由于是后臺線程對已經(jīng)寫完的文件進行B+樹索引整理,B+樹是在內(nèi)存建立,建立完成后,將最新的內(nèi)容寫入新文件,原子替換老的eventIndexChunk文件;所以,這塊的邏輯處理應(yīng)該不會對服務(wù)的主邏輯產(chǎn)生較大的影響;
•采用BloomFilter優(yōu)化查詢性能,使用BloomFilter來快速判斷某個eventIndexChunk文件中是否包含某個聚合根ID,如果不在,則不用從B+樹去檢索該聚合根的版本號了;如果在,則取檢索;通過這個設(shè)計,當我們要獲取某個聚合根的最大版本號時,不需要對每個eventIndexChunk文件進行B+樹查詢,而是先通過BloomFilter快速判斷當前的eventIndexChunk文件是否包含該聚合根的信息,大大提升檢索效率;BloomFilter的二進制Bit數(shù)據(jù)占用內(nèi)存小,可以在每個eventIndexChunk文件被掃描時,和文件頭的信息一起加載到內(nèi)存;
5、命令索引存儲
•異步順序?qū)慶ommandIndexChunk文件,一個文件大小為1GB,寫滿一個文件后寫入下一個文件;
•同事件索引存儲,進行B+樹索引建立,索引的排序依據(jù)是命令I(lǐng)D;
•同事件索引存儲,采用BloomFilter優(yōu)化查詢性能;
四、框架邏輯設(shè)計
1、查詢某個聚合根的最大版本號
•EventStore啟動時,會加載所有的eventIndexChunk文件的元數(shù)據(jù)到內(nèi)存,比如文件號、文件頭、BloomFilter等信息,但不真實加載文件內(nèi)容,文件數(shù)不會太多,最多也就幾十個;
•根據(jù)聚合根ID+BloomFilter算法,快速確定應(yīng)該到哪個eventIndexChunk文件中去查找該聚合根的最新版本號,eventIndexChunk文件從新到舊遍歷,因為某個聚合根ID的最大版本號一定是在最新的eventIndexChunk文件中的;
•在找到的eventIndexChunk中使用B+樹查找算法,找到對應(yīng)的葉子節(jié)點;
•在找到的葉子節(jié)點,使用二分查找算法(由于單個節(jié)點的聚合根ID不多,順序查找即可),找到指定聚合根的最新版本號;
2、查詢某個聚合根的所有事件
•先通過上面的算法找出該聚合根的最大版本號的事件在事件數(shù)據(jù)文件中的位置;
•然后從該位置獲取事件完整數(shù)據(jù);
•再根據(jù)事件數(shù)據(jù)中記錄的上一個事件在事件數(shù)據(jù)文件中的位置,查找上一個事件的數(shù)據(jù);
•以此類推,直到找到該聚合根的第一個事件的數(shù)據(jù);
3、查詢某個命令對應(yīng)的事件數(shù)據(jù)
•先嘗試從內(nèi)存查詢該命令的索引信息,如果存在,則直接獲取該命令對應(yīng)的事件在事件數(shù)據(jù)文件中的位置,即eventPosition;如果不存在,則嘗試從命令的索引文件中查找,結(jié)合BloomFilter和B+樹查找算法進行查找;
•如果找到了eventPosition,則根據(jù)eventPosition到事件數(shù)據(jù)文件中查找對應(yīng)的事件數(shù)據(jù)即可;如果未找到,則返回空;
4、追加一個新事件的處理邏輯
•根據(jù)aggregateLatestVersionDict判斷事件版本號是否合法,必須是聚合根的當前版本號+1,如果當前版本號不存在,則首先嘗試從eventIndexChunk文件查找當前聚合根的最大版本號,如果還是查找不到,說明當前聚合根確實不存在任何事件,則當前事件版本號必須為1;
•根據(jù)commandIdDict判斷命令I(lǐng)D是否重復(fù),如果commandIdDict中不存在該命令,嘗試從commandIndexChunk文件中查找,也是B+樹的方式;這里需要設(shè)計一個配置項,讓開發(fā)者配置是否需要繼續(xù)從commandIndexChunk文件查找命令I(lǐng)D。有時我們只希望從內(nèi)存查找即可,不希望再從磁盤查找了,因為判斷命令是否重復(fù)我們很多時候只希望檢查最近一段時間內(nèi)的命令,檢查全部命令代價過大,意義也不是很大;
•如果事件的版本號合法、命令I(lǐng)D不重復(fù),則Append的方式寫入事件數(shù)據(jù)到eventDataChunk;
•寫入完成后,更新aggregateLatestVersionDict、commandIdDict,、BloomFilter的Bit數(shù)組,以及將當前的事件放入內(nèi)存的一個雙緩沖隊列;隊列消費者異步批量將事件索引和命令索引寫入對應(yīng)的索引文件;
•返回事件寫入結(jié)果;
5、其他邏輯
•異步線程定時批量持久化事件索引;
•異步線程定時批量持久化命令索引;
•異步線程定時清理不需要放在內(nèi)存的聚合根最新版本號信息(aggregateLatestVersionDict中的key),根據(jù)eventTime判斷,只保留最近1周有過變化(產(chǎn)生過事件)的聚合根;
•異步線程定時清理不需要放在內(nèi)存的命令索引(commandIdDict中的key),根據(jù)commandTime判斷,只保留最近1周的命令I(lǐng)D;
•異步線程定時進行事件索引和命令索引的B+樹索引的建立,即對已經(jīng)寫入完成的eventIndexChunk和commandIndexChunk文件的內(nèi)部重構(gòu);
•eventIndexChunk和commandIndexChunk文件標記為寫入完成前,要把BloomFilter的Bit數(shù)組內(nèi)容寫入文件中;
•其他EventStore的啟動邏輯,比如啟動時加載一定數(shù)量的索引數(shù)據(jù)到內(nèi)存,以及索引數(shù)據(jù)相比事件數(shù)據(jù)是否有漏掉或無效的檢查;
•其他邏輯支持,如支持聚合根的快照存儲,從文件查找數(shù)據(jù)時,如果文件的B+樹索引信息還未建立,則需要進行全文掃碼;
總結(jié)
以上所述是小編給大家介紹的EventStore文件存儲設(shè)計詳解,希望對大家有所幫助,如果大家有任何疑問請給我留言,小編會及時回復(fù)大家的。在此也非常感謝大家對腳本之家網(wǎng)站的支持!
如果你覺得本文對你有幫助,歡迎轉(zhuǎn)載,煩請注明出處,謝謝!
您可能感興趣的文章:- PHP實現(xiàn)抓取百度搜索結(jié)果頁面【相關(guān)搜索詞】并存儲到txt文件示例
- numpy的文件存儲.npy .npz 文件詳解
- 詳解如何在python中讀寫和存儲matlab的數(shù)據(jù)文件(*.mat)
- 詳解MySQL中InnoDB的存儲文件
- Android開發(fā)實現(xiàn)讀取Assets下文件及文件寫入存儲卡的方法
- MySQL數(shù)據(jù)文件存儲位置的查看方法