消息总线+事件存储+ PubSub

Question

我正在寻找构建一个包含许多数据源的应用程序，每个数据源都将事件放入我的系统。事件具有明确定义的数据结构，可以使用JSON或XML进行编码。

我希望能够保证事件被持久保存，并且事件被用作发布/订阅总线的一部分，每个事件可能有多个订阅者。

对于数据库，可用性非常重要，即使它扩展到多个节点，并且分区容差很重要，这样我可以扩展可以存储我的事件的位置数。最终的一致性对我来说已经足够了。

我在考虑使用JMS企业消息传递总线（例如Mule）或AMQP企业消息传递总线（例如RabbitMQ或ZeroMQ）。

但对于我的应用程序，似乎如果我可以使用CouchDB或类似的东西建立发布订阅系统，它将解决我的问题，而无需集成企业消息传递总线和持久存储系统。

哪个会更好，CouchDB +扩展+负载平衡+某种PubSub机制，或者是一个带有最终一致，可用，分区容忍存储的显式PubSub消息系统？哪一个更容易设置，管理和操作？对于给定的成本，哪种解决方案具有高吞吐量？为什么呢？

另外，在选择我的技术之前还有其他问题吗？ （顺便说一句，Java是服务器端和客户端语言）。

Answer 1

我在制作中使用了CouchDB message queue。 （这不是pub / sub，所以我不认为这个答案是完整的。）

目前（2011年6月），CouchDB作为消息传递基板具有巨大潜力：

1. 良好的数据持久性
2. 适合群集（在局域网上，使用BigCouch或休息室）
3. 准备好分发（全球数据中心之间）
4. 好平台。尽管下面列出了这些缺点，但我喜欢CQS，因为我可以重用我的数据库，它可以在Erlang，NodeJS和每个网络浏览器中使用。
5. _changes查询
   1. 连续投放，无需投票即时投放
   2. 网络停机没问题，只需稍后从之前的位置重试

尽管如此，即使CouchDB中的低容量消息系统也需要仔细规划和维护。 CouchDB 可能是一个出色的消息服务器。 （它的灵感来自Lotus笔记，它处理高电子邮件量。）

然而，这些是CouchDB面临的挑战：

1. 仅附加数据库文件增长很快
   1. 注意磁盘容量
   2. 注意磁盘i / o。压缩将读取并重写所有实时文档
2. 删除的文档并未真正删除。它们被标记为deleted=true并且即使在压实之后也会永远保留！这实际上是关于CouchDB的非常好，因为deleted操作将通过群集传播，即使网络停止运行一段时间。
3. 传播（复制）删除是很好的，但是删除的文档的构建呢？最终它将超过其他一切。解决方案是purge them，它实际上将它们从磁盘中删除。不幸的是，如果在查询地图/缩小视图之前进行2次或更多次清除，则视图将完全重建。这可能需要太多时间，具体取决于您的需求。

像往常一样，我们听到NoSQL数据库大喊“免费午餐！”，“免费午餐！”而CouchDB说“你将不得不为此工作。”

不幸的是，除非你有迫切需要重用CouchDB的压力，否则我会使用专用的消息传递平台。我在ejabberd作为消息传递平台以及与Google App Engine进行通信方面有过良好的体验。）

Answer 2

我认为最好的解决方案是CouchDB + Jabber / XMPP服务器（ejabberd）+书：http://professionalxmpp.com

• JSON是CouchDB的自然存储机制
• Jabber / XMPP服务器包括pubsub支持
• 这本书是必读的

Answer 3

虽然您可以使用数据库作为消息排队系统的替代方案，但是没有数据库是消息排队系统，甚至不是CouchDB。像AMQP这样的消息排队系统提供的不仅仅是消息的持久性，实际上使用RabbitMQ，持久性只是一个无形的服务，它可以解决您在CouchDB上必须处理的所有挑战。

仔细查看RabbitMQ网站，其中有大量关于AMQP的信息以及如何使用它。他们在收集有关消息排队的文章和博客方面做得很好。