设计：首先将记录推送到数据库然后从数据库中选择并推送到rabbitmq是否正确

Question

我们是电子商务网站，有几个列表。可以从各种应用程序创建/更新/删除列表： - 即桌面，移动，应用程序。

我们需要将所有这些更新的信息推送到某些第三方API，即创建/删除任何新列表，或者如果现有列表更新，我们需要通过某些第三方API推送完整的列表信息。我们正在使用Rabbitmq，因为我们期望大量的记录更新。

我们有两个选择：

• 从所有端点（桌面/网站/应用）推送信息，例如（listingId，列表上的操作，即CREATE / UPDATE / DELETE）到rabbitmq。 Rabbitmq进一步将这些消息出列并打到适当的API。
• 在列表表上实现触发器，即在创建时，使用列（listingId，要执行的数据库操作，即CREATE / UPDATE / DELETE）将条目插入到某个表中。现在，每隔10秒创建一个从此表中读取的作业。并将这些推送到rabbitmq。

哪个更好的appraoch？

Answer 1

我认为基于HTTP的API可能是最好的解决方案。您可以实现包含安全性（OAuth2 / SAML），速率限制等的网关。您可以在内部使用RabbitMQ。网关可以将更新发布到RabbitMQ，并让订阅者将数据写入主数据库，其他订阅者将数据发布到第三方API。

除了可用的额外安全控制之外，HTTP网关的额外好处是，您可以在未来改变您对RabbitMQ的看法，而不会影响难以全面更新的桌面和移动应用程序。

在我职业生涯的大部分时间里都使用过数据库，我倾向于避免使用触发器。特别是如果您期望大量更新。我过去经历过触发器的性能问题和可靠性问题。

值得注意的是，RabbitMQ确实存在消息重复问题 - 没有一次交付保证。因此，您需要实现自己的重复数据删除，或者最好使所有操作都是幂等的。