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

Question

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

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

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

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

Answer 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/

Answer 2

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

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

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

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

Answer 3

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

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

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

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

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

Answer 4

视情况而定。

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

希望它会有所帮助。