1

我正在横向扩展应用程序，并且已经意识到读取模型更新（通过事件处理程序的外部投影）将需要在竞争消费者的基础上进行处理。

我最初假设我需要确保订购，但此要求取决于消息。在我想知道总数的购物车结账的情况下，无论订单如何，我都可以添加总数 - 获取消息，更新 SQL 数据库，然后确认消息。

我现在绞尽脑汁想出一个场景/消息，但我知道情况并非如此。一些额外的清晰度和示例将非常有用。

我需要帮助的问题是：

  1. 排序需要什么类型的消息很重要，以及如何按原样使用消息来解决这个问题？

  2. 当进程加入/离开时，我们如何知道要从哪个事件重新订阅我可以看到可能导致对刚刚被另一个进程处理的消息请求订阅的时间问题？

  3. 我看到有一种Pinned消费者策略可以使流与订阅者的最大努力亲和力，但这并不能保证。我可以解决这个问题，使特定的流单线程只按顺序处理那些消息 - 一个进程是否可以对不同的流进行多个订阅？

事件存储订购

4

1 回答 1

2

要使用您的购物车示例，订购对于以下事件可能很重要：

  • 添加项目
  • 更新项目计数
  • 除去项目

您可能有类似 A：“添加项目，删除项目”或 B：“添加项目，更新项目计数（至 2），更新项目计数（至 3）”的序列。对于A，如果你在添加之前处理删除，显然你有麻烦了。对于 B，如果您无序地处理两个更新项目计数，您最终会得到错误的最终计数。

这通常通过使用某种分片方案来扩展，其中所有聚合的子集分配给每个分片。对于 Event Store，我相信这可以通过使用 partitionBy 创建用户定义的投影来将流划分为多个流（又名“碎片”）来完成。然后您需要以某种方式将分区/分片分配给处理节点。一些技术是围绕这种水平扩展的方法构建的（我想到了 Kafka 和 Kinesis）。

于 2019-09-23T11:06:56.573 回答