如何在事件驱动的体系结构中处理事务? [英] How to handle transaction in event driven architecture?
问题描述
我正在玩DDD& CQRS，我继续使用旧版应用程序.
假设我有一个Article实体，可以在该实体上投票.
将投票投给文章时，我想根据投票的值增加或减少计数器.
此计数器是我的查询模型的一部分，因此我认为它不适合域模型，出于这种原因，我决定编写一个CastArticleVoteService，在其中将业务逻辑放入表决中，并调度一个Event由自定义事件处理程序处理，该事件处理程序又更新数据库中的计数器.
首先，我持怀疑态度，因为我对自己说:嘿，更新计数器的过程应该与保存数据的事务在同一事务中".但是，如果我具有多语言持久性(即:MySQL/Redis)，那显然是错误的.
但是，事务仍然适用，如何确定整个事件处理程序得到正确处理并且我的数据是一致的? (这是我的柜台). (异步事件处理程序如何?)
有什么提示吗?
好的，这是我对您的问题的看法:
在event driven& CRQS体系结构，通常也使用 event sourcing 作为模式./p>
这意味着您的投票将不会存储为计数器(state)，而是会被存储为上下投票(fact).
在您的方案中，要查询文章已累积多少票，您可以阅读与聚合相关的所有事件，并按照发生的顺序将它们逐一应用(在内存中)并获得最终状态聚合实例(article).
有时，事件的数量很大时，会对通过将这些事件应用于汇总而得到的最新事实进行快照.
值得注意的:在将事件应用于 获得状态.因为如果上/下投票事件导致文章被 例如，关闭并向作者发送电子邮件，那么您就不会 希望在重播这些事件时再次发送该电子邮件.
将其视为与银行中的借方/贷方事件等同的财务状况.银行不只是存储您的余额.他们实际上存储了您的所有交易，以后进行对帐并更新您的余额.
如果债务人/债权人帐户在同一家银行内，则某些交易会立即发生
那为您带来了什么呢?
- 可扩展性；这是一种写优化的体系结构，可以处理较大的请求以更快地修改应用程序状态，而无需事务处理.锁定
- 跟踪性；在检查系统时，不仅会发现您所在的位置(当前状态)，而且还会知道如何/为什么到达那里(事件)
此外，由于您具有与系统的所有用户交互的数据流，因此您以后可以以不同的方式将该数据用于新功能，这些功能是您从设计系统开始就就不会想到的(例如，Analytics(分析)? )
进一步阅读:
I'm currently playing with DDD & CQRS, and I moved forward a legacy application.
Let's say I have an Article entity, on which I can cast votes.
When a Vote is casted on an Article, I want to increment or decrement a counter accordingly to the value of the vote.
This counter is part of my Query model and thus I don't think it fits the Domain Model, for such reasons, I decided to write a CastArticleVoteService in which I put the business logic about a vote, and I dispatch an Event to be handle by a custom Event Handler which in turns update the counter in a database.
First of all, I was skeptical because I told myself "hey, the process of updating the counter should be in the same transaction as the one which persist the data". But that's obviously wrong if I have polyglot persistence (ie: MySQL / Redis).
However, the transaction stills apply, how could I be sure that the whole event handlers are processed properly and my data are consistent? (here my counter). (what about asynchronous events handler?)
Any tips?
Alright, here is my take on your question:
In event driven & CRQS architecture, it is also common to use event sourcing as a pattern.
That means that your votes will not be stored as a counter (state), but rather as vote up/down (fact).
In your scenario, to query how many votes an article have accumulated, you can go read all the events related to an aggregate and apply them one by one (in memory) in the order they happened and get a final state of that aggregate instance (article).
Sometimes when the volume of events are big, a snapshot is kept on the most recent facts resulting from applying those events to an aggregate.
Worth noting: Be careful of side-effects when applying events to get state. Because if a vote up/down event caused an article to be closed for example and sent an email to the author, then you don't want that email to be sent again when replaying those events.
Think of this as the financial equivalent to debit/credit events in a bank. Banks don't just store your balance. They actually store all your transactions, and later do a reconciliation and update your balance.
Some transactions happen immediately if the debtor/creditor accounts are within the same bank
What that gives you out of the box?
- Scalability; this is a write-optimised architecture that can handle larger requests to modify application state faster without transactions & locking
- Traceability; when inspecting your system, not only you will find out where you're at (current state) but also you will know how/why you got there (events)
Also, since you have a data stream of all user interactions with the system, you can later use that data in different ways for new features that you would not have thought of from the beginning of designing the system (Analytics for example?)
Further reading:
- Event Sourcing Pattern - Martin Fowler
- Event Sourcing Basics - eventstore Db
- Why Use Event Sourcing - Greg Young
- MSDN: Event Sourcing Pattern
- MSDN: Using Events in Highly Distributed Architectures
这篇关于如何在事件驱动的体系结构中处理事务?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
