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