8

我正在 AWS 上设计一个 Event Store，我选择了 DynamoDB，因为它似乎是最好的选择。我的设计似乎相当不错，但我面临一些我无法解决的问题。

**该设计

事件由该对唯一标识(StreamId, EventId)：

  • StreamId：和aggregateId一样，意思是一个Event Stream对应一个Aggregate。
  • EventId：一个递增的数字，有助于将排序保持在同一事件流中

事件保留在 DynamoDb 上。每个事件映射到表中的单个记录，其中必填字段是 StreamId、EventId、EventName、Payload（可以轻松添加更多字段）。

partitionKey 是 StreamId，sortKey 是 EventId。

将事件写入事件流时使用乐观锁定。为此，我使用了 DynamoDb 条件写入。如果已经存在具有相同（StreamId，EventId）的事件，我需要重新计算聚合，重新检查业务条件，如果业务条件通过，最后再次写入。

事件流

每个事件流由 partitionKey 标识。查询所有事件的流等于查询 partitionKey=${streamId} 和 0 到 MAX_INT 之间的 sortKey。

每个事件流标识一个且只有一个聚合。如前所述，这有助于使用乐观锁定处理同一聚合上的并发写入。这也可以在重新计算聚合时提供出色的性能。

活动发布

利用 DynamoDB Streams + Lambda 的组合发布事件。

重播事件

这是问题开始的地方。将每个事件流仅映射到一个聚合（这导致拥有大量事件流），没有简单的方法可以知道我需要从哪些事件流中查询所有事件。

我正在考虑在 DynamoDB 中的某处使用一个额外的记录，它将所有 StreamIds 存储在一个数组中。然后我可以查询它并开始查询事件，但如果在我重播时创建了一个新流，我会丢失它。

我错过了什么吗？或者，我的设计是否完全错误？

4

3 回答 3

4

您可以使用 GSI 检索给定时间段内的事件。根据正在处理的事件数量，您可能需要编写 GSI 分片以避免热键。假设事件项小于 1KB，如果摄取率高于 1000 项/秒，则需要将它们分散到 GSI 上。如果事件大于 1KB，则需要将它们分散得更多。对于小于 1KB 的项目，将每秒的事件总数除以 1000。这将告诉您 GSI 需要多少分片才能跟上表格，例如假设您每秒摄取 5K 事件，您将需要 5 个分片。

当您将事件写入表时，添加一个名为“GSIKey”的新属性，并在插入事件时为该属性创建一个介于 0-4 之间的随机值。使用“GSIKey”作为分区键和时间戳作为排序键创建 GSI。当您需要获取给定时间范围内的所有事件时，请使用您正在查找的时间范围查询所有 5 个分片，然后简单地对结果集进行合并排序以生成按时间排序的事件列表。如果您每秒处理的事件少于 1000 个，那么您可以使用“0”作为 GSIKey 值，并在该分区中查询您需要的事件。

于 2019-04-22T17:42:55.700 回答
2

我错过了什么吗？

并不真地; 这是一个难题[tm]。

您的写入用例通常只关注模型中的单个引用——指向当前事件历史的指针。您的读取用例通常涉及分布在多个流中的数据。

这通常起作用的方式是，您的持久性存储不仅维护已写入的更改，而且还维护一个支持读取的索引。例如，Eventide 的 postgres 消息存储依赖于将行插入表时发生的索引。在Event Store的情况下，对索引的更新将作为与流更改相同的序列化“事务”的一部分写入。

表达相同想法的另一种方式：查询实际上以比写入更粗的粒度运行，存储设备隐含地提供您期望的协调保证。

去掉协调，你就有了类似于为每个流分配一个唯一主机的东西。

仔细查看Git 对象数据库并熟悉隐藏在该存储中的实际情况可能会很有用。我还发现 Rich Hickey 的演讲The Language of the System提供了有用的概念来values区分names.references

我选择了 DynamoDB，因为它似乎是最好的选择

除非您有一些令人信服的商业理由从头开始构建您的活动商店，否则我鼓励您转而查看Aurora，看看您能走多远。它可能会为您赢得等待其他人为您组装成本效益高的云原生事件存储设备所需的时间。

于 2019-04-19T15:52:42.270 回答
0

原始答案：您能否详细说明“聚合”？它与 EventID 相同，还是不同的项目属性？

您是否需要存储事件和聚合？

您的活动持久性要求是什么？

如果 < 14 天，您可以选择将事件存储在 Kinesis 中吗？正如 Rick Houlihan 指出的那样，您的设计可能会遇到热分区或热键问题，这将需要您增加 DynamoDB 表上的 RCU / WCU。Kinesis 解决了这个问题。使用它将使您能够专注于您的应用程序逻辑。

如果您愿意，我很乐意提供帮助，如果您可以分享更多详细信息。

4/23 更新：

让我提出另一种可供您考虑的替代方案：CloudWatch Logs。CloudWatch 日志组相当于您的事件表。您的每个流都将映射到 CloudWatch 日志流。

您需要考虑上面针对 DynamoDB 表描述的条件写入等效逻辑。

CWL 的优点是您将避免上面提到的热键问题。缺点是： (1) 您需要考虑针对 CWL 的解决方案。(2) DynamoDB 为读取提供 < 10 毫秒的 P99 延迟，为写入提供 < 20 毫秒的 P99 延迟。CWL 读写操作要高得多（想想 10 秒到 100 秒或毫秒）。

我希望这能有所帮助。

于 2019-04-23T01:21:48.387 回答