代理 vs 无代理
RabbitMQ 团队一直在与 Martin Sustrik 合作,为RabbitMQ 和 ZeroMQ 结合使用提供代码和文档。 为什么这是一个好主意? 因为代理和无代理方法是互补的。 我们将在代码库发展时发布更多相关内容。 这篇文章是入门介绍,可以看作是对Ilya Grigorik 关于 ZeroMQ 的优秀介绍和InfoQ 对 Ilya 文章的总结的评论。
RabbitMQ 团队一直在与 Martin Sustrik 合作,为RabbitMQ 和 ZeroMQ 结合使用提供代码和文档。 为什么这是一个好主意? 因为代理和无代理方法是互补的。 我们将在代码库发展时发布更多相关内容。 这篇文章是入门介绍,可以看作是对Ilya Grigorik 关于 ZeroMQ 的优秀介绍和InfoQ 对 Ilya 文章的总结的评论。
我们最近收到了很多请求,要求我们将 RabbitMQ 代码放到GitHub上。
RabbitMQ 是开源的,我们用于开发代码的Mercurial 代码库是公开可访问的。 但 GitHub 正在迅速成为开源开发的“Facebook”:它使跟踪项目和参与其开发变得容易,所有这些都在一个流畅的基于 Web 的 UI 中进行。
因此,从今天开始,我们将我们的代码库镜像到 GitHub。 你可以在https://github.com/rabbitmq找到它们。 GitHub 上的代码库会延迟几分钟跟踪我们的 Mercurial 代码库。
RabbitMQ 的主要开发将继续在 Mercurial 上进行。 将我们的开发工作流程和基础设施转换为 Git 需要花费大量精力,我们宁愿将这些精力用于改进 RabbitMQ。 此外,团队成员对 hg 和 git 的相对优势持有不同的意见。
如果你希望为 RabbitMQ 做出贡献,我们很乐意通过 GitHub、Mercurial 托管站点(如Bitbucket)甚至传统的补丁来接收更改!
最近,除了其他事情外,我们还一直致力于改进 RabbitMQ 的路由性能。 特别是我们研究了通过使用一些众所周知的算法以及其他一些技巧来加快主题交换的速度。 我们能够找到比我们当前实现快许多倍的解决方案。
在我们推出 RabbitMQ 三年半后,我们本周发布了RabbitMQ 2.0。
这意味着一些重大变化。 其中最重要的就是我们新的可扩展存储引擎。 RabbitMQ 一直以来都为故障恢复提供持久性。 但现在,无论已经存储了多少数据,你都可以愉快地将数据推送到 Rabbit,并且无需担心缓慢的消费者会中断处理。 随着应用程序需求的增长,Rabbit 可以稳定可靠地与你一起扩展。
在介绍 RabbitMQ 2.0 之前,请允许我重申,随着 Rabbit 的发展,无论你是大型企业、下一代初创公司还是开源社区,你都可以依靠我们对您作为客户或最终用户的一贯高度承诺。 与往常一样,如果你需要帮助或商业支持,请与我们联系。
长期以来,RabbitMQ 中内置的管理和监控功能一直由 rabbitmqctl 组成。 虽然它是一个合理的管理工具(假设你喜欢命令行),但 rabbitmqctl 从未成为一个非常强大的监控工具。 因此,我们将构建更好的东西。
从一开始,RabbitMQ 就实现了 AMQP 规范的 0-8 版本。 这是第一个公开发布的版本,但此后已经进行了大量开发。 特别是,我们一直希望支持 AMQP 的 0-9-1 版本。
对 AMQP 的 basic.reject
的支持刚刚在默认情况下生效。 花了这么长时间是因为我们无法就一套遵循规范、真正有用且实现起来不太复杂的语义达成一致。
并欢迎来到全新的 RabbitMQ 博客!