我在实际生产环境中体验过消息传递系统的优点和缺点，我必须承认，一个组织良好的表或表架构每次都能胜过任何其他形式的消息队列，因为：
您对每种方法有何看法？
【问题讨论】：
标签： database queue message-queue
队列提供可靠的消息传递。队列的存储转发、断开连接的特性使其比数据库更具可扩展性，更不用说更健壮了。
队列不应该真正用于信息的永久存储 - 最好将它们视为临时收件箱，不像数据库。
【讨论】：
我首先使用了表格，然后在（如果）有原因时重构为一个成熟的 msg 队列 - 如果您的设计合理，这将是微不足道的。
最大的好处是 a.) 它更容易，(b. 它是一个更好的审计跟踪，因为您有其他表可以连接，c.) 如果您非常了解数据库工具，它们比Message Queue 工具，d.）在您的应用程序已经存在的上下文中设置测试/开发环境通常会更容易一些（如果同样熟悉的话）。
哦，而且 e。）也许对于您和其他人来说，它不是另一个需要学习、安装、配置、管理和支持的产品。
IMPE，它同样可靠、可断开连接，如果需要更高的可扩展性，您可以进行转换。
【讨论】：
数据永久存储在表中。我见过很多 java (jms) 应用程序在途中因未捕获的异常或其他错误而丢失或消失消息。
哪个 JMS 实现？ Sun 销售不会丢失消息的可靠队列。也许您刚刚购买了符合 JMS 标准的俗气产品。 IBM 的 MQ 非常可靠，并且有 JMS 库可以访问它。
队列往往会被填满。相反，数据库存储实际上是无限的。
嗯...如果您的队列已满，听起来好像有什么东西坏了。如果您的应用程序崩溃，那不是一件好事，队列与此关系不大。如果您购买了一个非常糟糕的 JMS 实现，我可以看到您可能对它不满意的地方。这是一个竞争激烈的市场。寻找更好的队列管理器。 Sun 的 JCAPS 有一个非常好的队列管理器，以前是 SeeBeyond 消息队列。
表格很容易访问，而您必须使用深奥的工具从队列中读取。
这不符合我的经验。表是通过这种特殊的“其他语言”(SQL) 访问的，并且要求我了解从表到对象的结构映射以及从 VARCHAR2 到字符串的数据类型映射。此外，我必须使用某种访问层（JDBC 或使用 JDBC 的 ORM）。这看起来非常非常复杂。通过 MessageConsumers 和 MessageProducers 使用简单的发送和接收访问队列。
【讨论】：
听起来您遇到的问题似乎不是消息传递所固有的，而是消息传递系统实现不善的产物。构建消息系统是否比构建数据库系统更难？是的，如果您所做的只是构建数据库系统。
使其优于数据库的消息传递方面：
如果你不需要这些东西，你可能不需要消息传递。
下面是一个简单的消息传递应用程序示例：我正在构建一个系统，其中分布在多个网络中的用户正在输入相当复杂的交易集，这些交易集用于生成打印输出。输出生成的计算成本很高，并且不是其工作流程的一部分；即，用户不在乎何时生成输出，只关心它。
因此，我们将事务序列化为消息并将其放入队列中。在服务器上运行的进程从队列中获取消息，生成输出，并将输出存储在映像系统中。
如果我们使用数据库作为我们的消息存储，我们必须想出一个模式来存储目前只有发送方和接收方关心的事务格式，我们需要确保网络上的每个工作站网络有到数据库服务器的永久持久连接，我们没有能力在多个服务器之间分配这个事务负载，我们的输出服务器每天必须查询数据库数千次，等待是否有新的作业要处理.
【讨论】：
每次都跳动这句话完全取决于您的要求。当然，它不会每次都击败所有人。
如果您正在构建一个已经在使用数据库的单一系统，那么您没有非常高的性能吞吐量要求，并且您不必与任何其他团队或系统进行通信，那么您可能是对的。
对于简单、低吞吐量、主要是单线程的东西，数据库是消息队列的完美替代品。
消息队列的亮点在于何时
对于具有单个数据库、团队和相当适中的性能要求的简单系统 - 一定要使用数据库。为工作使用正确的工具等。
但是，消息队列在大型组织中大放异彩，那里有许多需要相互通信的系统（因此您不希望业务数据库成为故障的中心点或版本地狱的地方）或当您有高性能要求时。
就性能而言，消息队列总是胜过数据库表——因为消息队列是专门为这项工作而设计的，并且不依赖于悲观表锁（这是数据库实现队列所必需的——执行负载均衡）和good message queues will perform eager loading of messages to queues to avoid the network overhead of a database。
同样 - 您永远不会使用数据库在 Web 服务器上对 HTTP 请求进行负载平衡 - 因为它太慢了 - 如果您对负载平衡器有很高的性能要求，您也不会使用数据库.
【讨论】：