我正在使用 Java 和 Cassandra 的事件溯源从头开始构建一个项目。
我的应用程序基于微服务，在某些用例中，信息将被异步处理。我想知道消息队列(例如 Rabbit、Active MQ Artemis、Kafka 等)的哪一部分将在这种环境中改进技术堆栈，以及如果我不使用它，我是否了解场景。
最佳答案
我首先将像 RabbitMQ 这样的消息传递基础设施与像 Kafka 这样的事件流/存储/处理分开。这是为两个(或更多)不同目的而制作的两种不同的东西。
关于事件溯源，您必须有一个必须存储事件的地方。此存储必须是仅附加的，并支持基于身份的非结构化数据的快速读取。这种持久性的一个例子是 EventStore .
事件溯源与 CQRS 一起使用，这意味着您必须将您的更改(事件)转换到另一个商店，您可以查询该商店。这是通过将事件转换到该存储来完成的，这是处理事件以更改域对象状态的地方。重要的是要了解使用消息基础设施进行预测通常是一个坏主意。这是由于消息传递和两阶段提交问题的性质。
如果您查看事件如何持久化，您会发现它们作为一个事务被保存到存储中。如果您随后需要发布事件，这将是另一个事务。由于您正在处理两种不同的基础设施，因此事情可能会被破坏。
这样的消息传递问题是通常保证消息“至少一次”传递，并且通常不保证消息的顺序。此外，当您的消息使用者失败并且 NACK 消息时，它将被重新传递，但通常会稍晚一些，再次破坏序列。
排序和重复问题，不管是谁，都不适用于像 Kafka 这样的事件流服务器。此外，如果您使用追赶订阅，EventStore 将保证仅按顺序传递一次事件。
根据我的经验，消息用于发送命令并实现事件驱动架构以 react 方式连接独立服务。另一方面，事件存储用于持久化事件，只有到达那里的事件才会被投影到查询存储并发布到消息总线。
关于asynchronous - 事件溯源:我什么时候(而不是)应该使用 Message Queue？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/41131609/