4

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

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

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

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

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

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

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

4

3 回答 3

6

我在生产中使用CouchDB 消息队列。（它不是 pub/sub，所以我不认为这个答案是完整的。）

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

  1. 良好的数据持久性
  2. 为集群做好准备（在 LAN 上，使用 BigCouch 或 Lounge）
  3. 为分发做好准备（在全球数据中心之间）
  4. 好平台。尽管有下面列出的缺点，我还是喜欢 CQS，因为我可以重复使用我的数据库，并且它适用于 Erlang、NodeJS 和每个 Web 浏览器。
  5. _changes查询 _
    1. 连续供稿，即时交付，无需轮询
    2. 网络掉线没问题，从上一个位置稍后重试即可

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

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

  1. 仅追加数据库文件增长迅速
    1. 注意磁盘容量
    2. 请注意磁盘 i/o。压缩将读取和重写所有活动文档
  2. 删除的文档并没有真正删除。deleted=true即使在压实之后，它们也会被标记并永久保存！这实际上是CouchDB 的独特优势，因为该deleted操作将通过集群传播，即使网络中断了一段时间。
  3. 传播（复制）删除很棒，但是删除文档的积累呢？最终它将超过其他一切。解决方案是清除它们，这实际上是从磁盘中删除它们。不幸的是，如果您在查询 map/reduce 视图之前执行 2 次或更多次清除，则视图将完全重建自身。这可能需要太多时间，具体取决于您的需求。

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

不幸的是，除非您有重用 CouchDB 的巨大压力，否则我会使用专用的消息传递平台。我在将 ejabberd 作为消息传递平台以及与 Google App Engine 进行通信方面有很好的经验。）

于 2011-06-27T01:37:35.913 回答
2

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

  • JSON 是 CouchDB 的自然存储机制
  • Jabber/XMPP 服务器包括 pubsub 支持
  • 这本书是必读的
于 2011-06-26T13:10:35.633 回答
2

虽然您可以使用数据库作为消息队列系统的替代方案，但没有数据库是消息队列系统，甚至 CouchDB 也不行。像 AMQP 这样的消息队列系统提供的不仅仅是消息的持久化，事实上，对于 RabbitMQ，持久化只是底层的一项无形服务，它可以处理您在 CouchDB 上必须自己处理的所有挑战。

好好看看 RabbitMQ 网站，那里有很多关于 AMQP 以及如何使用它的信息。他们在收集有关消息队列的文章和博客方面做得很好。

于 2011-07-10T16:48:14.977 回答