这是一个好的消息队列体系结构吗？
-
应用程序将消息存储到数据库表中
-
发布者（异步）从数据库中读取消息并将其发布到消息代理中
-
消费者（异步）从消息代理获取消息，对其进行处理并更新数据库表（字段burned_at）
数据库控制邮件是待处理还是已处理。
数据库“控件”是否必要？
消息队列架构+数据库
•
问答
colourpeak 回答：消息队列架构+数据库
您的要求似乎是：
- 数据的异步处理
- 交易一致性（以防止丢失数据和/或重复处理）
所提出的体系结构非常复杂，无法实现一致性。
研究两个选项：
-
数据库处于控制状态，没有消息代理：在建议的体系结构中，发布者的角色尚不清楚。为什么不能将发布者和使用者合并为一个，从而摆脱消息代理？这样做的好处是：交易的一致性和更少的组件。
-
数据库和消息代理集成：如果应用程序在数据库和消息代理之间架桥，则很难实现事务一致性。如果事务提交但消息代理连接失败，或者将消息发送给代理但是事务无法提交，则可能会丢失数据。因此，它需要在中间件级别上解决。几种数据库和消息代理组合提供了具有事务一致性的直接集成：数据库数据和消息都被保留，或者两者都被回滚/丢弃。同样，发布者将不再需要。根据集成的不同，初始应用程序将需要向代理发布消息（可能借助于数据库触发器）。
您所描述的基本上是Apache Kafka或Apache Pulsar之类的分布式pub-sub消息传递系统。与其像这样模仿，不如使用其中之一。关系数据库比使用队列更适合用于 sets 。
,采用这种架构的唯一原因是需要更新数据库中的应用程序状态并在事务中发布消息。事务发布在某些情况下可能非常有用。
仅将消息发布到数据库中以供日后使用，然后重新发布到消息代理中会增加复杂性而没有任何实际好处。仅使用数据库或队列来传递消息。