消息总线+事件存储+ PubSub

Question

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

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

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

我在考虑使用JMS企业消息传递总线(例如Mule)或AMQP企业消息传递总线(例如RabbitMQ或ZeroMQ).

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

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

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

Answer 1

我在生产中使用CouchDB消息队列.(这不是pub/sub,所以我不认为这个答案是完整的.)

目前(2011年6月),CouchDB作为消息传递基板具有巨大潜力:

1. 良好的数据持久性
2. 适合群集(在局域网上,使用BigCouch或Lounge)
3. 准备好分发(世界各地的数据中心之间)
4. 好平台.尽管下面列出了这些缺点,但我喜欢CQS,因为我可以重用我的数据库,它可以在Erlang,NodeJS和每个网络浏览器中使用.
5. 该_changes查询
   1. 连续饲料,即时交付,无需轮询
   2. 网络故障没有问题,只需从以前的位置重试

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

但是,这些是CouchDB面临的挑战:

1. 仅附加数据库文件增长很快
   1. 注意磁盘容量
   2. 请注意磁盘i/o.压缩将读取并重写所有实时文档
2. 删除的文档并未真正删除.deleted=true即使在压实之后,它们也会被标记并永久保存!事实上,这对于CouchDB来说是独一无二的,因为deleted即使网络出现故障,该操作也会通过群集传播.
3. 传播(复制)删除很好,但是删除的文档的构建呢？最终它将超过其他一切.解决方案是清除它们,实际上将它们从磁盘中移除.不幸的是,如果在查询map/reduce视图之前执行2次或更多次清除,视图将完全重建自身.这可能需要太多时间,具体取决于您的需求.

像往常一样,我们听到NoSQL数据库大喊"免费午餐!","免费午餐!" 而CouchDB说"你将不得不为此工作."

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