NEventStore：未ディスパッチイベントのディスパッチはどのようにスケールされますか？

Question

NEventStoreのトランザクションの整合性について徹底的に読んでいますが、NEventStoreの多くのインスタンスを配線したときにNEventStoreが実際にどのように拡大するのか把握することはできません。

私の理解を要約すると、Eventはディスパッチャとしてコミットするために追加され、ディスパッチャにパブリッシュされ、ディスパッチされたとしてマークされます。

同時に、NEventStoreを接続するたびに、未ディスパッチイベントが検索され、ディスパッチされ、ディスパッチされたイベントとしてマークされます。

しかし、新しいイベントストアの配線が（他のストアからの）ディスパッチされようとしているディスパッチされていないイベントを見ると、短い時間間隔が必要です。新しいイベントストアがイベントを再送します。このアーキテクチャの

考える：私たちは私たちの負荷を処理するCommand Handlers多くを持っている場合は

Client -> Command Bus -> Command Handler -> EventStore persist -> Dispatch to Event Handlers

、我々はまた、多くのイベントを永続化されるだろう。

多くの場合、Command Handlersを処分したり作成したりすると、多くのイベントストアが配線され、すでにディスパッチされているイベントのディスパッチが発生します。

私はディスパッチャのコンシューマが冪等でなければならないことを理解していますが、これは私の問題ではありません。私の問題は、負荷の高い状況でコマンドハンドラが消費者に不必要な負荷をかけるかどうかです。

Answer 1

この質問は本当に古いですが、私はちょうどそれを偶然見つけたので、私は2つのセントを追加します。コマンドハンドラのすべてのインスタンスに対してNEventStoreの新しいインスタンスを結びつけるとは思わない。 NEventStoreオブジェクトはステートレスなので、プロセス全体に1つのインスタンス（またはAppDomain）を使用できます。

複数のプロセスがある場合は、それぞれが新しいNEventStoreを結び付け、シナリオが現実のものになる可能性があります。しかし、その影響はおそらく非常に小さく、スケーラビリティをあまりにも低下させることはありません。

Answer 2

私の意見では、この場合、メッセージは複数回送信されます。 this doc上の事実ベースで：

イベントのセットは、派遣が、まだそのようにマークされなくてもよい障害シナリオ中の小さな可能性があります。これにより、メッセージの同じセット内の が再ディスパッチされることがあります。メッセージ指向の システムでは、少なくとも一度の配信のコンセプトは常に が考慮されるべきものであり、この状況は変わりません。メッセージ 重複する受信メッセージを避けるために、消費者は（潜在的には 以前のメッセージのリストを追跡することによって）冪等を持たせる必要があります。

したがって、消費者は最終的に同じメッセージを複数回受け取ることができます。

Fabian Schmiedによると、neventstoreは各コマンドハンドラではなく、アプリケーションインスタンスごとに1回作成する必要があると思います。