Broker vs Brokerless
RabbitMQ 团队一直在与 Martin Sustrik 合作，提供 将 RabbitMQ 和 ZeroMQ 一起使用的代码和文档。 为什么这是一个好主意？ 因为 Broker 和 Brokerless 方法是互补的。 随着代码库的演进，我们将发布更多关于这方面的内容。 这篇文章是介绍性的，可以看作是对 Ilya Grigorik 撰写的关于 ZeroMQ 的精彩介绍 以及 InfoQ 对 Ilya 文章的总结 的评论。
我喜欢 ZeroMQ，并且认为它很有用 - 更多内容见下文。 但我看到一些人为它提出的草率主张。 这 可能会导致混淆。
那么什么是“Brokerless”模型？ 在对 Ilya 和 InfoQ 文章的评论中，ZeroMQ 被比作 SCTP 和 JGroups。 这些都是重要的技术，为思考 Brokerless 消息传递模式提供了一个有益的起点。 让我们看看，如果您将消息传递（如 SCTP）与 pubsub 组（如 JGroups）结合起来，以使用“Brokerless”对等节点构建任意网络，您可能需要什么。
Brokerless 网络中您可能需要的一些东西
如果您设置了一个 Brokerless 消息传递网络，您可能需要的三件事是：发现、可用性和管理。
发现是维护系统可以向其发送消息的对等节点名录以及谁可以加入此名录的问题。
可用性是处理对等节点不时消失的问题。 例如，如果您有 50 个订阅源的订阅者，并且只有 40 个订阅者可以接收更新，您是否应该保留他们的消息副本直到他们重新出现？ 这可能意味着“很长时间”。 而且，如果您确实保留了消息和“谁看过什么”的列表，那么在哪里做这件事最好呢？
当消息接收者没有快速响应时，这也是一个问题。 引用 ZeroMQ 的 Martin Sustrik 的话，“您永远无法区分‘网络错误’和‘未收到响应’。 TCP 也没有更好。 您将不得不接受这一点，或者坚持使用单个盒子。”
管理也是一个有趣的分析领域。 ZeroMQ 的模型将消息传递与套接字紧密结合。 这意味着，就像在 TCP 中一样，“任何”通信网络都可以以这样一种方式实现，即它提供某种消息传递能力。 但是，网络可能是任意复杂的。 例如，除非您不在乎（您可能不在乎），否则“谁连接到谁，以及谁可以连接到谁”的管理可能会变得复杂。 这种管理问题随着规模的扩大而变得更加困难。 像 JGroups 这样的模型通常通过做一个简化的假设来消除这个问题，即：组中的每个人都与组中的其他人交谈。 简单 :-)
我并不是说您总是需要这些东西。 ZeroMQ 的理念是专注于网络，这创造了焦点。 但是，如果您确实需要它们，那么您最终可能会自己实现它们。 Broker 由此应运而生...
**Broker 如何帮助解决这些问题**
Broker 可以为发现、可用性和管理提供解决方案。 它们还可以形成可靠的网络，例如用于电子邮件传递和即时消息服务。
首先：什么是“Broker”？ 它既是领导者，又是中介。
Broker 是领导者。 在分布式计算中，管理、发现和可用性的问题通常通过在分布式组件集中选举一个领导者来解决。 在“消息传递”领域，这样的领导者通常被称为“Broker”。 说明为了成为领导者，您需要成为 Broker，这使得找出谁是领导者比在完全 Brokerless 系统中“任何人都可以领导，但没有人知道如何领导”更容易得多。
Broker 也是中介。 例如，通信器不必直接连接组中的每个人，而是简单地连接到 Broker（或多个 Broker）。 Broker 也可以用来解决可用性问题，例如“离线消费者”，通过提供持久性并代表无法自行完成的系统管理恢复。
因此，Broker 通过做出合理的假设来简化网络设计。 当然，当这些假设不成立时，您可能不需要 Broker。
Broker 并非“中心化”
关于 Broker 的一个常见的误解是它们是“中心化”的。 Broker 并非一定是“中心化”的解决方案。 中介可以是去中心化的。 您可以在单个网络中拥有多个 Broker，以提高吞吐量和可用性。 有时，这些服务器网络被称为联邦。 请注意，单个 Broker 不需要是“高可用”的，即可拥有冗余的服务器网络。
例如，电子邮件 (SMTP) 和 XMPP 网络就是这样工作的。 电子邮件和即时消息都是 Broker 模型，并且都以简单且冗余的方式使用多个 Broker。 例如，邮件传输代理为电子邮件提供传递和路由网络。 如果没有重新发明“特殊对等节点”——也称为 Broker，就很难提出一个完全对等的设计。
那么哪种模型最简单？
对等模型本质上并不比 Broker 模型更简单或更复杂。 如果您不需要发现、可用性、管理或中介，那么不使用它们可能会更简单。 但如果您需要它们，那么不自己实现它们可能会更简单。
服务器（Broker）网络并不比客户端（对等节点）网络更冗余或更去中心化。 Broker 和 Brokerless 模型在可靠性以及其他考虑因素（例如延迟）方面都有其优点和缺点。
这两种模型解决了不同的问题。
例如，RabbitMQ 和 ZeroMQ 是互补的。 从 RabbitMQ 的角度来看，ZeroMQ 是一个“智能客户端”，可以使用其缓冲区作为队列。 这在某些情况下很有用。 从 ZeroMQ 的角度来看，RabbitMQ 是一种网络设备，它提供了您不一定想要自己实现的服务。
我们希望我们的客户和用户始终拥有可用的最佳工具集，这就是我们提供 Github 存储库供您试用的原因。 再次感谢 Martin Sustrik 在这方面的工作。
请关注此空间，了解更多关于这个有趣的工作和讨论领域的信息。