我需要使用一些东西来协调我的系统与多个消费者/生产者，每个消费者/生产者都在具有不同操作系统的不同机器上运行。我一直在研究使用 MySql 来做到这一点，但这似乎非常困难。
我的要求很简单：我希望能够随时添加或删除消费者/生产者，因此它们根本不应该相互依赖。自然，数据库会很好地将两者分开。
我一直在查看 MySql 的 Q4M 消息队列插件，但使用起来似乎很复杂。
我真的需要一些关于如何最好地构建我的系统的意见。
问问题
3347 次
4 回答
5
我需要使用一些东西来协调我的系统与几个消费者/生产者，每个消费者/生产者在不同的机器上运行不同的操作系统
那是一个消息队列。不要追求其他选择。其他一切（即，使用带有插入和删除功能的数据库）都非常缓慢和麻烦。
用数据库构建一个大而慢的消息队列在实践中通常会很糟糕，因为 (1) 数据库很慢，(2) 数据库庞大而复杂，(3) 存在锁定和争用问题，这可能会使每个事务都变慢，( 4）它的开销比问题应得的要多得多。
有许多消息队列解决方案。
如果你不能让 Q4M 发挥作用，你应该转向另一个。
http://en.wikipedia.org/wiki/Message_queue
于 2010-03-15T18:05:01.750 回答
2
构建这样的系统实际上（相当）复杂。（我说公平，因为它当然是可行的）。
如果你有多个生产者和一个消费者，这很容易。所有生产者同时写入，单个消费者在数据可见（提交）后立即读取数据。
但是，如果您希望具有多个使用者的可伸缩性，则需要创建一个重要的锁定方案。（您必须确保没有行被分派给两个消费者。这对于数据库事务和锁来说并不容易实现。幼稚的解决方案会导致所有消息传递的序列化，就像您只有一个消费者一样，这是我们不想要的。 ）。
我建议使用内置解决方案。您还可以阅读有关类似问题的这个问题。
于 2010-03-15T19:30:23.370 回答
1
我认为没有第三方软件是可行的。
我的第一个设计如下所示：
- 生产者将数据写入数据库
- 为了保证一致性，它必须使用事务
- 消费者也使用事务处理数据（读取和删除）。
由于事务的要求，InnoDB 是存储引擎的逻辑选择。此外，您必须仔细选择隔离级别。我的第一个猜测是“可序列化”以避免幻读，但也许更弱的级别也是可能的。
如果性能和可伸缩性是一个问题，您应该考虑使用“真正的”消息传递解决方案。推出你的产品很可能会导致性能和/或可扩展性问题。
于 2010-03-15T17:47:43.890 回答
0
这取决于情况。
在我的例子中，只有一个生产者每天发出数千条消息，几个消费者在接下来的 24 小时内消费这些消息，每个消费者都需要几个小时才能完成。所以，我认为mysql可以满足我的要求，我可以使用事务来保证消费者之间的一致性。
希望它会有所帮助。
于 2015-03-23T09:39:18.263 回答