事件溯源架构是否需要使用消息队列？答案

【问题标题】：Does event sourcing architecture need to use message queues?事件溯源架构是否需要使用消息队列？
【发布时间】：2019-09-18 12:44:11
【问题描述】：

考虑这个简单的例子。假设您有一个带有 ff 的事件表 TBL_EVENTS。列：

eventId (int)
dateTime（日期时间）
事件名称（字符串）
数据（json）

现在是ff。事件发生：

$UserService->registerUser();

USER_REGISTERED 事件现在与 ff 一起存储在 TBL_EVENTS 中。数据：

eventId: 1
dateTime: 2019-04-30 00:00:00
eventName: USER_REGISTERED
data: {"userId":1, "name":"foo"}

第一个问题：事件侦听器是否每 x 秒直接查询/侦听 TBL_EVENTS，或者是否需要消息队列以不使用轮询请求“轰炸”TBL_EVENTS？

例如，除了TBL_EVENTS，$UserService->registerUser(); 是否在单独的消息队列中推送“事件”（例如，AWS SQS），然后，$UserService->listener(); 轮询SQS 而不是TBL_EVENTS？或者，在实际应用中使用直接轮询TBL_EVENTS？

第二个问题：当$UserService->listener(); 获得USER_REGISTERED 事件时，它是只为单独的TBL_USERS 表创建一个新用户还是重播从0 到的所有事件现在，从而每次都在TBL_USERS 中创建所有用户？

【问题讨论】：

您始终可以使用某些数据库（如 PostgreSQL）的本机监听/通知功能。久经考验、可靠且高效。

标签： architecture message-queue event-sourcing event-driven

【解决方案1】：

对于类似的用例，我的设计实现了以下方法 -

[1] 事件源系统 -- 调用 --> 事件代理 -- 写入记录 --> 事件阶段表

[2] EVENT STAGE TABLE -- 触发器 --> DB PROCEDURE -- 写入 --> EVENT QUEUE

[3] 事件处理程序 -- 投票 --> 事件队列

这样的处理点链帮助我保持了一个非常简单和干净的实现，并且可以灵活地独立测试系统的单元部分。

现在，至于您的问题 2；我不明白您需要始终从头开始创建用户。然而，如果出于任何原因需要这样做，那么使用上述方法，您将需要另一个 DB 过程（在点 #2），它将迭代表的现有行，并调用写入事件队列的现有过程.

这里可以考虑的另一种替代方法是写入 DB 并并行处理事件 -

[1] 事件源系统 -- 广播 --> 事件通道

[2] DB PROCEDURE -- 监听 --> EVENT CHANNEL

[3] DB PROCEDURE -- 写入 --> USER TABLE

[4] 事件控制器 -- 监听 --> 事件通道

[5] 事件控制器 -- 调用 --> 事件处理器

上述方法可以提供一种声明式（数据驱动）方法来注册事件处理程序，并提供与写入数据库并行处理事件的性能优势；然而，缺点是写入数据库和处理事件可能需要额外的努力，如果您期望事务行为。

【讨论】：