Axon 事件通过 EventBus 多次发布 [英] Axon Event Published Multiple Times Over EventBus

问题描述

只想确认 Axon 的预期行为，以及我在应用程序中看到的行为.我们有一个与 Axon 框架集成的定制 Kafka 发布器，以及一个由 Cassandra 支持的定制事件存储.

Just want to confirm the intended behavior of Axon, versus what I’m seeing in my application. We have a customized Kafka publisher integrated with the Axon framework, as well as, a custom Cassandra-backed event store.

我看到的问题如下:(1)我发布了一个命令(例如 CreateServiceCommand)，它命中了 ServiceAggregate 的构造函数，然后(2)一个 ServiceCreatedEvent 被应用到聚合.(3) 我们看到域事件在后端持久化并通过 EventBus(我们有一个 Kafka 消费者)发布.

The issue I’m seeing is as follows: (1) I publish a command (e.g. CreateServiceCommand) which hits the constructor of the ServiceAggregate, and then (2) A ServiceCreatedEvent is applied to the aggregate. (3) We see the domain event persisted in the backend and published over the EventBus (where we have a Kafka consumer).

一切都很好，但假设我使用相同的聚合标识符再次发布相同的命令.我确实看到 ServiceCreatedEvent 被应用于调试器中的聚合，但是由于域事件记录已经存在该键，因此没有任何内容持久保存到后端.同样，一切都很好，但是我看到 ServiceCreatedEvent 被发布到 Kafka 并被我们的侦听器使用，这是意外行为.

All well and good, but suppose I publish that same command again with the same aggregate identifier. I do see the ServiceCreatedEvent being applied to the aggregate in the debugger, but since a domain event record already exists with that key, nothing is persisted to the backend. Again, all well and good, however I see the ServiceCreatedEvent being published out to Kafka and consumed by our listener, which is unexpected behavior.

我想知道这是否是 Axon 的预期行为，或者我们的 Kafka 集成是否应该确保我们不会通过 EventBus 发布重复事件.

I’m wondering whether this is the expected behavior of Axon, or if our Kafka integrations ought to be ensuring we’re not publishing duplicate events over the EventBus.

我在 Axon 的 JPA 事件存储中交换，并在尝试发出命令以创建已存在的聚合时看到以下日志.那么这个问题确实是由于我们的自定义事件存储的缺陷造成的.

I swapped in Axon's JPA event store and saw the following log when attempting to issue a command to create the aggregate that already exists. This issue then is indeed due to a defect with our custom event store.

"oracle.jdbc.OracleDatabaseException: ORA-00001: unique constraint (R671659.UK8S1F994P4LA2IPB13ME2XQM1W) violated\n\n\tat oracle.jdbc.driver.T4CTTIoer11.processError

推荐答案

给出的解释有几个漏洞，老实说很奇怪，也很难查明问题出在哪里.

The given explanation has a couple of holes which make it odd to be honest, and hard to pinpoint where the problem lies.

简而言之，不会，Axon 不会因为第二次调度完全相同的命令而两次发布事件.这取决于您的实施.如果该命令创建了一个聚合，那么您应该会看到对聚合标识符和(聚合)序列号的唯一性要求的约束违规.如果是对现有聚合起作用的命令，则取决于您的实现是否幂等是/否.

In short no, Axon would not publish an event twice as a result of dispatching the exact same command a second time. This depends on your implementation. If the command creates an aggregate, then you should see a constraint violation on the uniqueness requirement of aggregate identifier and (aggregate) sequence number. If it's a command which works on an existing aggregate, it depends on your implementation whether it is idempotent yes/no.

从你的成绩单我猜你正在谈论一个创建聚合的命令处理程序.因此，你所看到的行为让我觉得很奇怪.事件存储是自定义的，插入了这种不受欢迎的行为，或者是由于没有使用 Axon 的专用 Kafka 扩展一>.

From your transcript I guess you are talking about a command handler which creates an Aggregate. Thus the behavior you are seeing strikes me as odd. Either the event store is custom which inserts this undesired behavior, or it's due to not using Axon's dedicated Kafka Extension.

另请注意，使用单一解决方案进行事件存储和消息分发，例如 Axon Server 将完全忽略这个问题.您不再需要在 Kafka 上配置任何自定义事件处理和发布，从而节省您的个人开发工作和基础设施协调工作.添加，它为您提供了我之前讨论过的保证.从更多关于 Axon Server 的原因/方式的见解，您可以查看 这个其他我的SO回应.

Also note that using a single solution for event storage and message distribution like Axon Server will omit the problem entirely. You'd no longer need to configure any custom event handling and publication on Kafka at all, saving you personal development work and infrastructure coordination. Added, it provides you the guarantees which I've discussed earlier. From more insights on why/how of Axon Server, you can check this other SO response of mine.

这篇关于Axon 事件通过 EventBus 多次发布的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！