只是想确认axon的预期行为，与我在应用程序中看到的对比。我们有一个与axon框架集成的定制kafka发布服务器，以及一个定制的cassandra支持的事件存储。
我看到的问题如下：（1）我发布了一个命令（例如createservicecommand），它命中serviceAgregate的构造函数，然后（2）一个servicecreatedevent应用于该聚合(3） 我们看到域事件保存在后端并通过eventbus发布（在这里我们有一个kafka使用者）。
很好，但是假设我用相同的聚合标识符再次发布相同的命令。我确实看到servicecreatedevent被应用到调试器中的聚合中，但是由于已经存在具有该键的域事件记录，因此没有任何内容被持久化到后端。同样，一切都很好，但是我看到servicecreatedevent被发布到kafka，并被我们的侦听器使用，这是意外的行为。
我想知道这是axon的预期行为，还是我们的kafka集成应该确保我们不会在eventbus上发布重复的事件。
编辑：
我在axon的jpa事件存储中进行了交换，并在尝试发出命令来创建已经存在的聚合时看到了以下日志。这个问题确实是由于我们的自定义事件存储的缺陷造成的。
"oracle.jdbc.OracleDatabaseException: ORA-00001: unique constraint (R671659.UK8S1F994P4LA2IPB13ME2XQM1W) violated\n\n\tat oracle.jdbc.driver.T4CTTIoer11.processError
1条答案
按热度按时间r1wp621o1#
给出的解释有几个漏洞，这使得坦白说很奇怪，而且很难找出问题所在。
简而言之，不，axon不会因为第二次发送完全相同的命令而两次发布事件。这取决于您的实现。如果该命令创建了一个聚合，那么您应该看到对聚合标识符和（聚合）序列号的唯一性要求的约束冲突。如果它是在现有聚合上工作的命令，则取决于您的实现是否是幂等的yes/no。
从你的成绩单我猜你说的是一个创建聚合的命令处理程序。因此你看到的行为让我觉得很奇怪。要么事件存储是自定义的，插入这种不希望的行为，要么是由于没有使用axon的专用kafka扩展。
另外请注意，使用单一的事件存储和消息分发解决方案（如axon server）将完全忽略该问题。您不再需要在kafka上配置任何自定义事件处理和发布，节省了您的个人开发工作和基础设施协调。此外，它为您提供了我前面讨论过的保证。从更多关于axon服务器的原因/方式的见解中，您可以检查我的另一个so响应。