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

背景

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

一、需求概述

•存儲(chǔ)聚合根的事件數(shù)據(jù)
•支持事件的版本并發(fā)控制，新事件的版本號(hào)必須是當(dāng)前版本號(hào)+1
•支持命令重復(fù)判斷，即不可以處理重復(fù)命令產(chǎn)生的事件
•支持按聚合根ID查詢?cè)摼酆细乃惺录?br /> •支持按聚合根ID+事件版本號(hào)查詢指定的事件
•支持按命令I(lǐng)D查詢?cè)撁顚?duì)應(yīng)的事件數(shù)據(jù)
•高性能，寫(xiě)入要盡量快，查詢要盡量快

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

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

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

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

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

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

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

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

{
 "aggregateRootId": "",   //聚合根ID
 "aggregateRootType": "",  //聚合根類型
 "eventVersion": "",    //事件版本號(hào)
 "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": "",    //事件版本號(hào)
 "eventTime": "",      //事件產(chǎn)生時(shí)間
 "eventPosition": "",    //事件在事件數(shù)據(jù)文件中的位置
}

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

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

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

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

4、事件索引存儲(chǔ)

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

5、命令索引存儲(chǔ)

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

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

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

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

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

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

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

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

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

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

5、其他邏輯

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

總結(jié)

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