消息队列架构+数据库答案

【问题标题】：Message queue architecture + database消息队列架构+数据库
【发布时间】：2020-03-07 22:23:01
【问题描述】：

这是一个好的消息队列架构吗？

数据库控制消息是待处理还是已处理。

数据库“控制”有必要吗？

【问题讨论】：

【解决方案1】：

看来你的要求是：

所提议的架构相当复杂，没有达到一致性。

研究两个选项：

数据库受控，无消息代理：在提议的架构中，发布者的角色不明确。为什么不能将发布者和消费者合二为一，从而摆脱消息代理？优点是：事务一致性和更少的组件。
数据库和消息代理集成：如果应用程序在数据库和消息代理之间架起桥梁，则很难实现事务一致性。如果事务提交但消息代理连接失败，或者您向代理发送消息但无法提交事务，您可能会丢失数据。因此，需要在中间件层面解决。一些数据库和消息代理组合提供了与事务一致性的直接集成：数据库数据和消息都被持久化，或者都被回滚/丢弃。再一次，出版商将不再需要。根据集成情况，初始应用程序需要向代理发布消息（可能借助数据库触发器）。

【讨论】：

【解决方案2】：

您所描述的本质上是一个类似于Apache Kafka 或Apache Pulsar 的系统，分布式发布-订阅消息系统。与其模仿那些系统，不如使用其中之一。与 queues 相比，关系数据库更适合使用 sets。

【讨论】：

【解决方案3】：

这种架构的唯一原因是需要更新数据库中的应用程序状态并在事务中发布消息。事务性发布在某些情况下可能非常有用。

只是将消息发布到数据库以便稍后获取它们并重新发布到消息代理中会增加复杂性，而没有任何实际好处。仅使用数据库或队列来传递消息。

【讨论】：

在没有存储库的情况下，您将如何控制消息是否已被处理？
消息系统支持确认消息以避免新的处理。但即使在仅 DB 解决方案的情况下，也无法确保没有双重处理。例如，可以处理消息，然后无法将该事实记录到 DB 中。然后消息将被重新传递并双重处理。