事件源中的多聚合事务
我是事件采购的新手，但对于我们当前的项目，我认为这是一个非常有前途的选择，主要是因为审计跟踪。
有一件事我不是100%满意，那就是缺乏跨聚合的超越。请考虑以下问题：
我有一个订单，它在不同的机器上处理，在不同的车站。我们有集装箱，工人们把订单放进去，然后把它从一台机器运到另一台机器。
必须通过容器（具有唯一的条形码id）进行跟踪，订单本身无法识别。问题是：容器是重用的，需要锁定，因此没有工作人员可以在同一个容器中同时下两个订单（为了简单起见，假设他们看不到容器中是否已经有订单）。
为了清晰起见，高级视图：
- 订单A已创建
- 订购放在容器1上的货物
- 容器1移动到机器A并被扫描
- 机器A为订单A生成一些事件
- 将订单A从集装箱1移动到集装箱2
- 订单B已创建
- 订单B放在容器1上
“将订单A从容器1移动到容器2”是我正在努力解决的问题。
这是交易（不存在）中应该发生的事情：
- 容器2:LockAquiredEvent
如果应用程序在位置1或位置2后崩溃，我们有被锁定的容器，无法重用。
我脑海中有多种可能的解决方案，但我不确定是否有更优雅的解决方案：
- 假设每周故障不会超过一次，并提供一种工人可以手动修复的方法
- 将容器跟踪视为另一个域，不要在该域中使用事件源
- 用补偿行动和其他东西来实现一个传奇故事
还有什么我能做的吗？
我认为saga是一个不错的选择，但我们将有一个rest api，在这里我们可以获得从容器1到容器2的命令传输顺序，这意味着api命令处理程序将需要侦听事件流，并等待一些saga生成的事件将200传递给请求者。我认为这不是一个好的设计，是吗？
不使用事件源进行跟踪也不完美，因为容器可能会影响订单的质量，因此订单也必须跟踪使用过的容器。
谢谢你的提示。
共有1个答案
聚合之间的一致性是最终的，这意味着AR1很容易改变其状态，Ar2无法改变其状态，现在您应该将AR1的状态恢复到一致状态。1） 如果这种情况经常发生，并且恢复过程非常痛苦，那么您的AR边界就会变大。2） 手动恢复。不要使用佐贺的，他们不应该用于这样的目的。如果您的传奇想要补偿AR1，但其他事务已将其状态更改为另一个事务，则补偿将失败。
-
我有一个条目主题，其中我从传感器接收数据。通常，我收到的数据如下所示： 为了稍后在拓扑中进行一些计算，我需要构建一个映射，其中包含从每个捕获者接收到的所有最后值。 关键字：项目id值：{ 为了做到这一点，我在传感器主题和聚合主题之间进行了连接，连接的结果是聚合主题中的post。 ------ 传感器（KStream）-| -------聚合（KTable）---| 更新：以下是实现这种连接的jav
-
当您的事件需要附加到更多侦听器或需要观察应用程序的某些功能并等待数据更新时，应使用事件聚合器。 Aurelia事件聚合器有三种方法。 publish方法将触发事件，并可供多个订阅者使用。 对于订阅事件，我们可以使用subscribe方法。 最后，我们可以使用dispose方法分离订阅者。 以下示例演示了这一点。 我们的视图将为三个功能中的每一个提供三个按钮。 app.html <template>
-
在实现基于事件源的微服务时，我们遇到的主要问题之一是聚合响应数据。例如，我们可能有两个实体，如学校和学生。一个微服务可能负责处理学校相关的业务逻辑，而另一个微服务可能处理学生。 现在，如果有人通过RESTendpoint进行查询并询问某个特定的学生，他们可能希望了解学校和学生的详细信息，那么对我来说，唯一已知的方法是以下方法。 > 使用类似于服务链接的东西。一个例子是Api-Gateway在向几个
-
如何读取自创建以来该聚合的所有事件？
-
我将Flink 1.11.3与SQL API和Blink planner结合使用。我在流模式下工作，使用带有文件系统连接器和CSV格式的CSV文件。对于一个时间列，我生成水印，并希望根据这个时间进行窗口聚合。就像根据事件时间快进过去一样。 是否必须为此对时间列进行排序，因为逐行使用时间列，如果不进行排序，可能会发生延迟事件，从而导致行的删除？ 我对Ververica的CDC连接器也很感兴趣。也许我
-
具有事件源的CQR看起来非常适合作为我们的一个系统的架构，目前我们只担心一件小事：处理大量事件，并因此处理大型事件商店。 我们当前的系统每天接收大约一百万个事件（目前与事件源无关），如果我们将它们存储在更长的时间内，我们的事件存储可能会变得相当大，但是如果我们经常转储/清除滚动快照，我们可能会失去事件源的一大优势：关于系统历史和重播的信息。 在CQRS架构中处理这个问题的常见方法是什么？这到底是个