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

Question

我需要使用某些东西来协调我的系统与几个在不同操作系统的不同机器上运行的消费者/生产者。我一直在研究使用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符合我的要求，我可以使用这些事务来确保消费者之间的一致性。

希望它会有所帮助。