EventStore文件存儲設(shè)計(jì)詳解

背景

ENode是一個(gè)CQRS+Event Sourcing架構(gòu)的開發(fā)框架，Event Sourcing需要持久化事件，事件可以持久化在DB，但是DB由于面向的是CRUD場景，是針對數(shù)據(jù)會不斷修改或刪除的場景，所以內(nèi)部實(shí)現(xiàn)會比較復(fù)雜，性能也相對比較低。而Event Store實(shí)際上對數(shù)據(jù)只有新增和查詢的需求，所以我想為Event Sourcing的場景針對性的實(shí)現(xiàn)一個(gè)Event Store?？戳艘幌聵I(yè)界的一些實(shí)現(xiàn)，感覺都沒有達(dá)到我的期望，所以想自己動(dòng)手實(shí)現(xiàn)一個(gè)。下面是我構(gòu)思的一個(gè)Event Store的單機(jī)版應(yīng)該要具備的能力以及對應(yīng)的設(shè)計(jì)方案，分享出來和大家討論。

一、需求概述

•存儲聚合根的事件數(shù)據(jù)
•支持事件的版本并發(fā)控制，新事件的版本號必須是當(dāng)前版本號+1
•支持命令重復(fù)判斷，即不可以處理重復(fù)命令產(chǎn)生的事件
•支持按聚合根ID查詢該聚合根的所有事件
•支持按聚合根ID+事件版本號查詢指定的事件
•支持按命令I(lǐng)D查詢該命令對應(yīng)的事件數(shù)據(jù)
•高性能，寫入要盡量快，查詢要盡量快

二、事件數(shù)據(jù)格式

{
 "aggregateRootId": "",   //聚合根ID
 "aggregateRootType": "",  //聚合根類型
 "eventVersion": "",    //事件版本號
 "eventTime": "",      //事件發(fā)生時(shí)間
 "eventData": "",      //事件數(shù)據(jù)，JSON格式
 "commandId": "",      //產(chǎn)生該事件的命令I(lǐng)D
 "commandTime": ""     //產(chǎn)生該事件的命令產(chǎn)生時(shí)間
}

三、存儲設(shè)計(jì)

1、核心內(nèi)存存儲設(shè)計(jì)

•遵循內(nèi)存只存儲索引數(shù)據(jù)的原則，盡量充分利用內(nèi)存；
•aggregateLatestVersionDict，存儲每個(gè)聚合根的最大事件版本號 ◦key：aggregateRootId，聚合根ID
◦value： ◦eventVersion，當(dāng)前聚合根的最新事件的版本號，也即當(dāng)前聚合根的版本號
◦eventTime，事件產(chǎn)生時(shí)間
◦eventPosition，事件在事件數(shù)據(jù)文件中的位置

•commandIdDict，存儲命令索引 ◦key：commandId，命令I(lǐng)D
◦value： ◦commandTime，命令產(chǎn)生時(shí)間
◦eventPosition，命令對應(yīng)的事件在事件數(shù)據(jù)文件中的位置

2、物理存儲的數(shù)據(jù)

•事件數(shù)據(jù)：eventData，單條數(shù)據(jù)的結(jié)構(gòu)：

{
 "aggregateRootId": "",   //聚合根ID
 "aggregateRootType": "",  //聚合根類型
 "eventVersion": "",    //事件版本號
 "eventTime": "",      //事件發(fā)生時(shí)間
 "eventData": "",      //事件數(shù)據(jù)，JSON格式
 "commandId": "",      //產(chǎn)生該事件的命令I(lǐng)D
 "commandTime": "",     //產(chǎn)生該事件的命令產(chǎn)生的事件
 "previousEventPosition": ""http://前一個(gè)事件在事件文件中的位置
}

•事件索引：eventIndex，單條數(shù)據(jù)的結(jié)構(gòu)：

{
 "aggregateRootId": "",   //聚合根ID
 "eventVersion": "",    //事件版本號
 "eventTime": "",      //事件產(chǎn)生時(shí)間
 "eventPosition": "",    //事件在事件數(shù)據(jù)文件中的位置
}

•命令索引：commandIndex，存儲內(nèi)容：存儲所有命令的ID及其對應(yīng)的事件所在文件的位置

{
 "commandId": "",    //聚合根ID
 "commandTime": "",   //命令產(chǎn)生時(shí)間
 "eventPosition": "",  //事件在事件數(shù)據(jù)文件中的位置
}

3、事件數(shù)據(jù)存儲

•同步順序?qū)慹ventDataChunk文件，一個(gè)文件大小為1GB，寫滿一個(gè)文件后寫入下一個(gè)文件；
•寫入每個(gè)事件時(shí)，同時(shí)寫入當(dāng)前事件的前一個(gè)事件所在的文件位置，以便將來可以一次性將某個(gè)聚合根的所有事件從文件查找出來；

4、事件索引存儲

•異步順序?qū)慹ventIndexChunk文件，一個(gè)文件大小為1GB，寫滿一個(gè)文件后寫入下一個(gè)文件；
•對于已經(jīng)寫滿的不會再變化的文件的內(nèi)容，使用后臺線程進(jìn)行B+樹索引整理，索引的排序依據(jù)是聚合根ID+事件版本號；B+樹設(shè)計(jì)為3層，根節(jié)點(diǎn)包含1000個(gè)子節(jié)點(diǎn)，每個(gè)子節(jié)點(diǎn)再包含1000個(gè)子節(jié)點(diǎn)，這樣葉子節(jié)點(diǎn)共有100W個(gè)。每個(gè)葉子節(jié)點(diǎn)我們保存20個(gè)版本索引，則單個(gè)文件共可保存最多2000W個(gè)版本索引，10個(gè)文件為2億個(gè)版本索引；單機(jī)存儲2億個(gè)事件索引，應(yīng)該可以滿足大部分應(yīng)用場景了；3層，則查找任意一個(gè)節(jié)點(diǎn)，只需要3次IO訪問；
•由于是后臺線程對已經(jīng)寫完的文件進(jìn)行B+樹索引整理，B+樹是在內(nèi)存建立，建立完成后，將最新的內(nèi)容寫入新文件，原子替換老的eventIndexChunk文件；所以，這塊的邏輯處理應(yīng)該不會對服務(wù)的主邏輯產(chǎn)生較大的影響；
•采用BloomFilter優(yōu)化查詢性能，使用BloomFilter來快速判斷某個(gè)eventIndexChunk文件中是否包含某個(gè)聚合根ID，如果不在，則不用從B+樹去檢索該聚合根的版本號了；如果在，則取檢索；通過這個(gè)設(shè)計(jì)，當(dāng)我們要獲取某個(gè)聚合根的最大版本號時(shí)，不需要對每個(gè)eventIndexChunk文件進(jìn)行B+樹查詢，而是先通過BloomFilter快速判斷當(dāng)前的eventIndexChunk文件是否包含該聚合根的信息，大大提升檢索效率；BloomFilter的二進(jìn)制Bit數(shù)據(jù)占用內(nèi)存小，可以在每個(gè)eventIndexChunk文件被掃描時(shí)，和文件頭的信息一起加載到內(nèi)存；

5、命令索引存儲

•異步順序?qū)慶ommandIndexChunk文件，一個(gè)文件大小為1GB，寫滿一個(gè)文件后寫入下一個(gè)文件；
•同事件索引存儲，進(jìn)行B+樹索引建立，索引的排序依據(jù)是命令I(lǐng)D；
•同事件索引存儲，采用BloomFilter優(yōu)化查詢性能；

四、框架邏輯設(shè)計(jì)

1、查詢某個(gè)聚合根的最大版本號

•EventStore啟動(dòng)時(shí)，會加載所有的eventIndexChunk文件的元數(shù)據(jù)到內(nèi)存，比如文件號、文件頭、BloomFilter等信息，但不真實(shí)加載文件內(nèi)容，文件數(shù)不會太多，最多也就幾十個(gè)；
•根據(jù)聚合根ID+BloomFilter算法，快速確定應(yīng)該到哪個(gè)eventIndexChunk文件中去查找該聚合根的最新版本號，eventIndexChunk文件從新到舊遍歷，因?yàn)槟硞€(gè)聚合根ID的最大版本號一定是在最新的eventIndexChunk文件中的；
•在找到的eventIndexChunk中使用B+樹查找算法，找到對應(yīng)的葉子節(jié)點(diǎn)；
•在找到的葉子節(jié)點(diǎn)，使用二分查找算法（由于單個(gè)節(jié)點(diǎn)的聚合根ID不多，順序查找即可），找到指定聚合根的最新版本號；

2、查詢某個(gè)聚合根的所有事件

•先通過上面的算法找出該聚合根的最大版本號的事件在事件數(shù)據(jù)文件中的位置；
•然后從該位置獲取事件完整數(shù)據(jù)；
•再根據(jù)事件數(shù)據(jù)中記錄的上一個(gè)事件在事件數(shù)據(jù)文件中的位置，查找上一個(gè)事件的數(shù)據(jù)；
•以此類推，直到找到該聚合根的第一個(gè)事件的數(shù)據(jù)；

3、查詢某個(gè)命令對應(yīng)的事件數(shù)據(jù)

•先嘗試從內(nèi)存查詢該命令的索引信息，如果存在，則直接獲取該命令對應(yīng)的事件在事件數(shù)據(jù)文件中的位置，即eventPosition；如果不存在，則嘗試從命令的索引文件中查找，結(jié)合BloomFilter和B+樹查找算法進(jìn)行查找；
•如果找到了eventPosition，則根據(jù)eventPosition到事件數(shù)據(jù)文件中查找對應(yīng)的事件數(shù)據(jù)即可；如果未找到，則返回空；

4、追加一個(gè)新事件的處理邏輯

•根據(jù)aggregateLatestVersionDict判斷事件版本號是否合法，必須是聚合根的當(dāng)前版本號+1，如果當(dāng)前版本號不存在，則首先嘗試從eventIndexChunk文件查找當(dāng)前聚合根的最大版本號，如果還是查找不到，說明當(dāng)前聚合根確實(shí)不存在任何事件，則當(dāng)前事件版本號必須為1；
•根據(jù)commandIdDict判斷命令I(lǐng)D是否重復(fù)，如果commandIdDict中不存在該命令，嘗試從commandIndexChunk文件中查找，也是B+樹的方式；這里需要設(shè)計(jì)一個(gè)配置項(xiàng)，讓開發(fā)者配置是否需要繼續(xù)從commandIndexChunk文件查找命令I(lǐng)D。有時(shí)我們只希望從內(nèi)存查找即可，不希望再從磁盤查找了，因?yàn)榕袛嗝钍欠裰貜?fù)我們很多時(shí)候只希望檢查最近一段時(shí)間內(nèi)的命令，檢查全部命令代價(jià)過大，意義也不是很大；
•如果事件的版本號合法、命令I(lǐng)D不重復(fù)，則Append的方式寫入事件數(shù)據(jù)到eventDataChunk；
•寫入完成后，更新aggregateLatestVersionDict、commandIdDict，、BloomFilter的Bit數(shù)組，以及將當(dāng)前的事件放入內(nèi)存的一個(gè)雙緩沖隊(duì)列；隊(duì)列消費(fèi)者異步批量將事件索引和命令索引寫入對應(yīng)的索引文件；
•返回事件寫入結(jié)果；

5、其他邏輯

•異步線程定時(shí)批量持久化事件索引；
•異步線程定時(shí)批量持久化命令索引；
•異步線程定時(shí)清理不需要放在內(nèi)存的聚合根最新版本號信息（aggregateLatestVersionDict中的key），根據(jù)eventTime判斷，只保留最近1周有過變化（產(chǎn)生過事件）的聚合根；
•異步線程定時(shí)清理不需要放在內(nèi)存的命令索引（commandIdDict中的key），根據(jù)commandTime判斷，只保留最近1周的命令I(lǐng)D；
•異步線程定時(shí)進(jìn)行事件索引和命令索引的B+樹索引的建立，即對已經(jīng)寫入完成的eventIndexChunk和commandIndexChunk文件的內(nèi)部重構(gòu)；
•eventIndexChunk和commandIndexChunk文件標(biāo)記為寫入完成前，要把BloomFilter的Bit數(shù)組內(nèi)容寫入文件中；
•其他EventStore的啟動(dòng)邏輯，比如啟動(dòng)時(shí)加載一定數(shù)量的索引數(shù)據(jù)到內(nèi)存，以及索引數(shù)據(jù)相比事件數(shù)據(jù)是否有漏掉或無效的檢查；
•其他邏輯支持，如支持聚合根的快照存儲，從文件查找數(shù)據(jù)時(shí)，如果文件的B+樹索引信息還未建立，則需要進(jìn)行全文掃碼；

總結(jié)

以上所述是小編給大家介紹的EventStore文件存儲設(shè)計(jì)詳解,希望對大家有所幫助，如果大家有任何疑問請給我留言，小編會及時(shí)回復(fù)大家的。在此也非常感謝大家對腳本之家網(wǎng)站的支持！
如果你覺得本文對你有幫助，歡迎轉(zhuǎn)載，煩請注明出處，謝謝！