事件采购：在更新模型之前或之后编写事件

Question

我在推理活动采购时常常遇到鸡蛋问题。非常感谢有关如何推理这一点的一些提示。

如果我执行所有I / O绑定处理异步（即写入事件日志），那么如何处理或有时甚至检测到失败？

我正在使用Akka Actors，因此每个事件/消息的处理都是顺序的。我目前没有任何数据库，而是将所有事件保存在事件日志中，然后保持存储在内存中的模型中所有事件的聚合状态。查询都是针对此模型的，您可以将其视为缓存。

实施例

创建新用户：

1. 验证用户在模型中不存在
2. 将活动持续到期刊
3. 更新型号（内存中）

如果第3步中断，我仍然坚持我的活动，以便我可以在以后重播。如果第2步中断，我可以优雅地处理它。

这很好，但是由于第2步是I / O绑定的，我认为我应该在一个单独的actor中执行I / O以释放查询的第一个actor ：

允许查询时更新用户（A0 =前端/ GUI actor，A1 =处理器Actor，A2 = IO-actor，E =事件总线）。

1. （A0-＆gt; E-> A1）发布事件以更新用户'U1'。验证用户'U1'是否存在于模型
中
2. （A1-> A2）将事件持续到期刊（独立演员）
3. （A0-＆gt; E-> A1-> A0）查询用户'U1'个人资料
4. （A2-＆gt; A1）事件现在持续更新模型
5. （A0-> E-> A1-> A0）查询用户'U1'配置文件（现在返回新数据）

这很有吸引力，因为可以在I / O按照自己的节奏搅拌时处理查询。

但是现在我可能会遇到各种各样的问题，我可以将两个不兼容的命令（删除然后更新）保存到事件日志中，并在以后重播时崩溃，因为我之前进行了验证持久化事件然后更新模型。

我的目标是围绕我的模型进行简单的推理（因为Actor按顺序处理消息单线程）但在查询时不等待I / O绑定更新。我感觉我正在建模一个本身可能有问题的数据库。

如果事情不清楚请写评论。

Answer 1

异步I / O可以与事务更新共存。如果您在命令后发送“ACK”或“NACK”，那么您可以了解它是否已经发生。在分布式或真正的异步模型中，“NACK”可能来自显式故障和超时。