????????在上一篇文章中颜屠，介紹了A+ES的基本概念及適合解決的一些問題辰妙，我們看到分布式最終一致性的解決方案的巧妙。如果您想實(shí)踐一下A+ES汽纤，先別急上岗，今天我們看看實(shí)踐過程中的常見問題福荸，實(shí)踐者可以更好的理解A+ES蕴坪，也為選型提供一些參考。
1. 并發(fā)控制
????????當(dāng)多個(gè)線程或多個(gè)實(shí)例同時(shí)訪問聚合的事件流，這將導(dǎo)制一些潛在的并發(fā)沖突背传，從而使聚合處于不正確的狀態(tài)呆瞻。如圖所示：
? ? ? ? 最簡單的方法就是在線程2處理事件4時(shí)拋出一個(gè)EventStoreConcurrency Exception供最終用戶處理，需要時(shí)也可以捕獲這個(gè)異常進(jìn)行重試径玖。
????????如果重新執(zhí)行聚合的成本過高痴脾，或者不方便重新執(zhí)行，那么我可以使用事件沖突決議(Event conflict resolution),它可以減少并發(fā)所致的異常梳星。這種方法的基本思想是在追加到事件流之前對事件進(jìn)行比對校驗(yàn)赞赖。
2. 性能
????????如果一個(gè)事件流由成百上千個(gè)事件組成，那么我們在回放一個(gè)聚合時(shí)可能會(huì)有性能問題冤灾。解決方法有兩種：
????????a. 版本號前域，為事件指定版本號，在內(nèi)存中緩存加載過的事件韵吨，在聚合進(jìn)行操作時(shí)匿垄，基于最后一個(gè)版本號獲取該事件之后的那些事件進(jìn)行播放。這種方法是以內(nèi)存換取性能归粉。
????????b. 聚合快照椿疗，在加載聚合實(shí)例時(shí)，我們只需要加載最近的一次快照糠悼，然后對發(fā)生在其后的事件進(jìn)行重放届榄。也可以使用資源庫來訪問快照。
3. 如何實(shí)現(xiàn)事件存儲
????????事件可以存儲在SQL绢掰，NoSQL或基于文件的BLOB存儲痒蓬。存儲的實(shí)現(xiàn)都比較簡單，我們看一下基于關(guān)系支持版本號的存儲表結(jié)構(gòu)如何設(shè)計(jì)：
? ? ? ? 如果使用基于文件的BLOB存儲的滴劲，一般策略是：每個(gè)聚合實(shí)例對應(yīng)一個(gè)文件攻晒，每個(gè)事件對應(yīng)一條記錄：
4. 讀模型投射
????????上一篇我們提到在基于A+ES的實(shí)踐中，如何實(shí)現(xiàn)不同維度的聚合查詢是常見問題班挖，例：最近一個(gè)月所有客戶的訂單總量鲁捏。對于A+ES的實(shí)踐中，并沒有像關(guān)系型數(shù)據(jù)庫那樣靈活的連接查詢操作萧芙。差勁的方法是先構(gòu)建聚合给梅，然后重播所有事件，讓當(dāng)前聚合進(jìn)入正確的狀態(tài)双揪，然后匹配我們的查詢條件动羽，One by one最終得到我們想要的結(jié)果。想想就很復(fù)雜渔期，實(shí)踐中我們一般不會(huì)這樣去做运吓，這里我們推薦一種被稱為讀模型投射(Read Model Projection)可供查詢使用的模式渴邦。
????????讀模型投射中，使用一組簡單的領(lǐng)域事件訂閱方來生成和更新讀模型拘哨，當(dāng)訂閱方接收到新的事件時(shí)谋梭，它們將計(jì)算一些查詢結(jié)果，然后將這些結(jié)果保存了到讀模型中以供后續(xù)使用倦青。
5. 事件變更的支持
????????在敏捷實(shí)踐中瓮床，我們提倡小步快跑，快速開發(fā)产镐，在應(yīng)對新需求的加入時(shí)隘庄，可以讓現(xiàn)在模型演化達(dá)到支持新需求的目的，那么如果我們的新需求需要修改領(lǐng)域事件該如何處理呢癣亚？
????????如果我們只是簡單的變更了字段峭沦，那么必然會(huì)對訂閱方產(chǎn)生影響，這時(shí)選擇一個(gè)有利于版本控制和事件重命名的序列器是不錯(cuò)的選擇逃糟，對于不同版本的屬性變更可以通過標(biāo)簽而不是名字來跟蹤各個(gè)契約成員吼鱼。Google 開源了一個(gè)Protocol Buffer可供選擇。
總結(jié)
????????A+ES不同于我們原來的基于數(shù)據(jù)庫的應(yīng)用绰咽，它在某種程度上簡化了一類問題的解決方法菇肃，同時(shí)也讓另一類問題變得復(fù)雜，今天的內(nèi)容希望能夠幫助我們的實(shí)踐者在做架構(gòu)決策提提供更多的支持取募。
