可靠的事件日志（不是真正的事件源）

Question

我正在实现一个系统，它应该以一致的方式存储所有事件，但同时我希望通过使用某种混合方法来保持一致性。尽管事件来源的想法非常清楚--所有的突变都进入ES日志，然后消费者创建实体视图，但我最讨厌的是最终的一致性，因为系统现在是全系统异步的。

CQRS+ES方法建议在UI级别解决这个问题，要求客户机等待。假设，我有一些接近stackoverflow的东西。当我完成这个问题时，我会点击“发布你的问题”按钮，网站会立即带我去问我的问题。使用ES方法，点击“发布您的问题”将意味着我的问题将被推入ES存储，稍后处理，我将看到“我们正在发布您的问题，请稍等”，对吗？这就是我想避免的。我提出了以下模式：

CreateQuestionCommand command
    = new CreateQuestionCommand(uint userId, string questionBody, string[] tags)
QuestionSavedEvent result
    = command.execute() // save to DB as usual, return events
saveToES(result) // ugghhhhh...

如果我忘记了savetoes，ES日志就会变得不一致，实际上毫无用处。如果我团队中的任何一个开发人员忘记了它，同样的事情--整个ES日志只是一次性的。

1.

• 有些数据库允许访问提交日志，提交日志可能是事件源，但这种方法有点枯燥，因为读取提交日志不会说明可能需要的应用程序业务逻辑，即您只需从提交日志中读取Update users SET loggedIn=“2018-12-30 10:00:00”，其中id=1，本例中的事件只是UserUpdated，但在应用程序级别上，它可能是更好的Userloggedin.

ebay使用的另一种方法（据称，我在一本关于ES的书中读过，不记得书名了，tho）

2.

• 启动事务1
• 更新域。用户设置loggedIn=“2018-12-30 10:00:00”，其中id=1
• 启动事务2（内部trx）
• 插入events.log SET event=“{name:UserLoggedIn,userid:1}”,timestamp=“2018-12-30 10:00:00”
• 提交事务2
• 提交事务1

然后另一个进程可以轮询此events.log以将数据发布到ES存储区。根据设计，应该强制每个数据mutator返回一个事件和一个指向事务1的指针，这就是系统永远不会“忘记”向数据库提交事件的原因。

免责声明：我知道这个问题有多臃肿，如果你认为这个问题不属于这个社区，让我知道，我会把它拿下来。

Answer 1

这种方法可行吗？这将解决ES的缺点，即最终的一致性，并仍然保留其光明的一面，即总是可靠的事件日志。

这样做没有错，但要小心--重要的是确保您的事件和状态存储在同一个事务中，因此存储在同一个数据库中。

在状态一侧存储事件的想法已经存在了一段时间。您会经常发现这样的讨论集中在“域事件”的思想上，并使用一个聚合引发的事件来触发其他地方的行为。例如，请参见Udi Dahan关于没有分布式事务的可靠消息传递的谈话。