c# - 事件源增量 int id

Question

我看了很多事件溯源教程，都在使用简单的演示来关注教程主题(事件溯源)

这很好，直到您在实际工作应用程序中遇到这些教程之一未涵盖的内容:)

我遇到了这样的事情。我有两个数据库，一个事件存储和一个投影存储(读取模型)所有聚合都有一个 GUID Id，到目前为止 100% 没问题。

现在我创建了一个新的 JobAggregate 和一个 Job Projection。我公司要求它有一个唯一的增量 int64 作业 ID。

现在我看起来很蠢:)另一个问题是每秒创建多次作业!这意味着，获取下一个数字的方法必须非常安全。

在过去(没有 ES)我有一个表，将 PK 定义为自动递增 int64，保存 Job，DB 完成工作给我下一个数字，完成。

但是我如何在我的聚合或命令处理程序中执行此操作？通常投影作业是由事件处理程序创建的，但在过程中已经晚了，因为聚合应该已经有 int64 了。 (用于在空数据库上重放聚合并具有相同的聚合 ID -> 作业 ID 关系)

我该如何解决这个问题？

亲切的问候

Answer 1

In the past (without ES) I had a table, defined the PK as auto increment int64, save Job, DB does the job to give me the next number, done.

在此序列中有一件重要的事情需要注意，即唯一标识符的生成和数据在记录簿中的持久化都共享一个事务。

当您将这些想法分开时，您从根本上看是在查看两个事务 - 一个使用该 ID，以便没有其他聚合尝试共享它，另一个将该 ID 写入存储。

最佳答案是将这两个部分安排为同一事务的一部分——例如，如果您使用关系数据库作为事件存储，那么您可以在“aggregate_id to long”表中创建一个条目与事件保存相同的事务。

另一种可能性是将聚合的“创建”视为 Prepare 后跟 Created；事件处理程序通过事后保留长标识符来响应准备事件，然后向聚合发送新命令以将长标识符分配给它。因此 Created 的所有消费者都看到了分配给它的 long 的聚合。

值得注意的是，您正在为您正在创建的每个聚合分配有效的随机长度，因此您最好深入了解公司认为它从中获得了什么好处——如果他们期望标识符将提供排序保证或完整性保证，那么您最好了解这一点。

首先保留 long 并没有什么特别的错误；根据聚合保存失败的频率，您最终可能会出现差距。在大多数情况下，您应该期望能够保持较低的失败率(即 - 您检查以确保您期望命令在实际运行之前成功)。

在真正意义上，唯一标识符的生成属于 set validation 的范畴;我们通常通过放弃任何排序假装并假装碰撞风险为零来“欺骗” UUID。关系数据库非常适合集合验证；事件商店可能没有那么多。如果您需要由模型控制的唯一顺序标识符，那么您的“分配的标识符集”需要在一个聚合中。

要遵循的关键词是“业务成本”——确保您了解长标识符的值(value)所在。