【问题标题】:Replicated message queue复制的消息队列
【发布时间】:2011-11-22 07:53:29
【问题描述】:

我正在寻找一个可以跨服务器集群复制消息的消息队列。我知道这会导致性能下降,但这就是要求 - 消息持久性非常重要。

复制可以是异步的,但它应该存在 - 如果有大量积压的消息等待处理,它们不应该丢失。

到目前为止,我还没有从著名的 MQ 中找到任何东西。例如 HornetQ 在 2.0 中支持消息复制,但在 2.2 中它似乎被删除了。 RabbitMQ 根本不复制消息,等等。

有什么可以满足我的要求吗?

【问题讨论】:

  • 所以您正在寻找一种保证消息传递形式,在这种形式中,您可以在代理端受到保护,免受断电或磁盘故障的影响?因此,换句话说,一旦代理收到消息,您几乎可以假设此后不久,在异步的情况下,您可能会丢失发布者和代理盒,但仍然可以恢复消息?
  • 是的,我希望将消息复制到另一台机器上。

标签: replication message-queue messaging cluster-computing


【解决方案1】:

至少有三种方法可以解决这个问题,具体取决于您需要的解决方案有多强大。

一:选择任何消息传递技术,然后复制您的磁盘存储。使用DRBD 之类的东西,您可以将文件支持的存储复制到另一台机器上。如果您的主机器死机,您应该能够从复制的文件在第二台机器上重新启动。

二:继续看。有各种商业系统肯定可以做到这一点,其中两个(我没有经济利益)是Informatica Ultra Messaging(以前的 29West)和Solace。这些在金融界很常用。

三:建立你自己的。 ZeroMQ 就是这样一种工具包,您可以使用它从预先构建的消息块中滚动您自己的系统。即使是一个没有正式支持它的系统也可以很容易地配置为将所有消息发布到两个队列。您的读者将不得不以某种方式耗尽两者,所以这很可能不是首发,但无论如何都是可能的。

总体而言:请测试您的性能假设,因为所有这些假设在各种情况下都会对性能产生不同的影响。

【讨论】:

  • 谢谢! :) 我一定会在空闲时间考虑“构建自己的”场景。同时,我在 MongoDB 之上添加了一个薄层,当在副本集中使用时,它可以按我的意愿工作。
【解决方案2】:

Amazon SQS 的设计正是考虑到这一点,但由于一致性模型(无论如何它是消息传递的一部分),您需要负责在消费者端对消息进行重复数据删除。诚然,SQS 可能有点慢,而且成本可能会增加很多消息,但如果你想保证没有消息丢失,那么这是一个非常可靠的方法。

【讨论】:

    【解决方案3】:

    新的 Kafka 0.8.1 提供复制功能!

    【讨论】:

      猜你喜欢
      • 2014-05-22
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2011-04-27
      • 1970-01-01
      • 2014-04-13
      • 1970-01-01
      相关资源
      最近更新 更多