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

Question

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

• eventId（int）
• dateTime（datetime）
• eventName（字符串）
• 数据（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？

例如，除了$UserService->registerUser();之外，AWS SQS是否在一个单独的消息队列（例如TBL_EVENTS）中推送“事件”，然后，$UserService->listener();民意调查SQS而不是TBL_EVENTS？或者，直接轮询到TBL_EVENTS用于现实世界的应用程序？

---

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

Answer 1

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

[1] EVENT SOURCE SYSTEM - 调用 - > EVENT PROXY - 写入记录 - > EVENT STAGE TABLE

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

[3] EVENT HANDLER（S） - 民意调查 - >活动队列

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

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

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

[1]事件源系统 - 广播 - > EVENT CHANNEL

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

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

[4] EVENT CONTROLLER - 收听 - > EVENT CHANNEL

[5] EVENT CONTROLLER - 调用 - > EVENT HANDLER（S）

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