2

イベント ストレージと読み取りモデルが実際のナットとボルトの実装に関してどのように関連しているかを理解しようとしています。

イベント ストアについての理解が限られているため、次のように考えています。

  1. イベントはイベント ストアにコミットされます
  2. Dispatcher の実行
  3. キューを使用している場合は、メッセージをキューに送信します (大量輸送としましょう)。
  4. 私の読み取りモデルはキューにサブスクライブされているため、読み取りデータベースはメッセージを取得します (mysql)
  5. データへの新しい変更で読み取りモデルが更新されます

これは、大量輸送機関に何かが起こった場合、私の読み取りデータベースが同期されなくなり、それを同期する方法を見つけなければならないことを意味します.

greg young によって公開された、私が読んだり見たりしたものの中には、イベント ストア自体をキューとして使用し、イベント ストア側で自動インクリメント番号を保持して一貫性を維持することを提案しているものがあります。それがjoliverのプロジェクトに実装されているのだろうか？

4

1 に答える 1

1

so my read database gets the message (mysql)

I'd re-state that as "my event processor(s) for a given event get the message and (in my case) will typically manipulate state in a mysql database" (Or do you mean something else?).

This would mean that if anything happened to mass transit, my read database will be out of sync and I have to figure out how to sync it back.

Yes, your queue becomes part of the state of your app and it needs to be backed up and resilient. Note that the Dispatcher does not mark the Commit dispatched until it has successfully put it onto the Queue, and the queuing system won't remove the message until you've confirmed completion of the processing to do the necessary updates to sync the state in your Read Model.

Remember that you can consider multiple web service calls to all be part of the necessary work to process an event.

The other thing to bear in mind is that you'll want to have your event processors be idempotent (i.e. be able to handle At Least Once delivery).

Further down the line, you'll have fun considering what you're going to do if an event cannot complete processing - are you going to Dead Letter the message? Who is going to monitor that?

BTW depending on your hosting arrangements, Azure (or the on-premise Windows) ServiceBus might be worth considering)

Some stuff I've read/watched that's been published by greg young suggest using the event store itself as a queue, and maintain consistency by keeping an auto increment number on the event store side in order to maintain eventual consistency. I'm wondering if that is implemented in joliver's project?

No, JOES provides you a Dispatcher hook and you decide what's right for you after that. This is good and bad. There are systems that don't have a Dispatcher tied to a stateful Read Model at all - they simply query the Event Store for events and build an in-memory Read Model to short circuit all this.

Not sure what you mean by auto increment numbers.

Beware that the Projection stuff in the GES is not fully 1.0 yet (but it goes without saying its extremely deserving of your strong consideration - it intrinsically deals with the bulk of the concerns you're touching on with these questions)

于 2013-03-07T09:31:55.760 に答える