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

查看:79
本文介绍了Axon事件通过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)发布一个命中ServiceAggregate构造函数的命令(例如CreateServiceCommand),然后(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的原因/方式的更多见解中,您可以检查

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屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆