使用数据库（MySql）的生产者/消费者系统，这可行吗？

Posted 2023-03-10

【中文标题】使用数据库（MySql）的生产者/消费者系统，这可行吗？

【英文标题】：Producer/consumer system using database (MySql), is this feasible?

【发布时间】：2011-01-27 19:06:25

【问题描述】：

我需要使用 something 来协调我的系统与多个消费者/生产者，每个消费者/生产者都在具有不同操作系统的不同机器上运行。我一直在研究使用 mysql 来做到这一点，但似乎很难。

我的要求很简单：我希望能够随时添加或删除消费者/生产者，因此它们根本不应该相互依赖。数据库自然会很好地将两者分开。

我一直在研究 MySql 的 Q4M 消息队列插件，但使用起来似乎很复杂。

我真的需要一些关于如何最好地构建我的系统的意见。

【问题讨论】：

你问的是架构吗？消息队列是标准解决方案。您是在询问构建 Q4M 的技术问题吗？请将您的问题集中在一般架构或特别是 Q4M 上。两者都很难回答。

这个问题是关于架构的。我将发布另一篇关于 Q4M 编译的具体内容。

如果您实际上是在询问架构，您能否编辑您的问题以专注于架构？ Q4M 问题的干扰使人们很难弄清楚您的问题并提供明智的帮助。请删除分散注意力的内容并专注于您的问题。

【参考方案1】：

我需要用一些东西来协调 我的系统有几个 消费者/生产者各自运行 不同的机器有不同的 操作系统

这是一个消息队列。不要追求其他选择。其他一切（即，使用带有插入和删除功能的数据库）都非常缓慢和繁琐。

在实践中使用数据库构建大型、缓慢的消息队列通常结果很糟糕，因为 (1) 数据库速度很慢，(2) 数据库庞大而复杂，(3) 存在锁定和争用问题，这些问题可能会导致每个事务慢，(4) 它比问题应得的开销要多得多。

有很多消息队列解决方案。

如果你不能让 Q4M 发挥作用，你应该转向另一个。

http://en.wikipedia.org/wiki/Message_queue

http://linux.die.net/man/7/mq_overview

http://qpid.apache.org/

http://code.google.com/p/httpsqs/

【讨论】：

我明白了。感谢您的链接。我想我会使用消息队列解决方案。 MSMQ 听起来像是一个不错的解决方案（对于 .net）。

【参考方案2】：

构建这样的系统实际上（相当）复杂。 （我说公平，因为它当然是可行的）。

如果您有多个生产者和一个消费者，这很容易。所有生产者同时写入，单个消费者在数据可见（已提交）时立即读取数据。

但是，如果您想要几个消费者的可扩展性，您将需要创建一个不简单的锁定方案。 （您必须确保没有行被分派给两个消费者。这对于数据库事务和锁来说并不容易实现。幼稚的解决方案会导致所有消息传递的序列化，就像您只有一个消费者一样，这是我们不想要的。 )。

我建议使用内置解决方案。您也可以阅读this question 了解类似问题。

【参考方案3】：

我认为没有第三方软件也是可行的。

我的第一个设计是这样的：

生产者将数据写入数据库 为了保证一致性，它必须使用事务 消费者也使用事务处理数据（读取和删除）。

由于事务的要求，InnoDB 是存储引擎的逻辑选择。此外，您必须仔细选择隔离级别。我的第一个猜测是“可序列化”以避免幻读，但也许更弱的级别也是可能的。

如果性能和可扩展性是一个问题，您应该考虑使用“真正的”消息传递解决方案。推出你的产品很可能会导致性能和/或可扩展性问题。

【参考方案4】：

视情况而定。

在我的例子中，只有一个生产者每天发出数千条消息，几个消费者在接下来的 24 小时内消费这些消息，每个消费者都需要几个分钟才能完成。所以，我认为mysql可以满足我的要求，我可以使用事务来保证消费者之间的一致性。

希望它会有所帮助。