1 简介为什么使用消息队列

不自己使用tcp，要使用可靠的消息队列组件？

ZeroMQ并不像传统MQ一样直接提供用户一个可部署的服务端程序，而是需要用户通过libzmq来封装核心的方法，再通过客户端程序远程调用服务端提供的服务。

• 1 如何处理 I/O？

ZeroMQ应用程序是阻塞，还是在后台处理 I/O？这是一个关键的设计决策。阻塞 I/O 会创建无法很好地扩展的体系结构。但是后台 I/O 可能很难正确完成。

• 2 如何处理动态组件，即暂时消失的部分？

我们是否正式将组件拆分为“客户端”和“服务器”，并强制要求服务器不能消失？那么，如果我们想将服务器连接到服务器怎么办？我们是否尝试每隔几秒钟重新连接一次？

• 3 如何在网络上表示消息？

我们如何构建数据，使其易于写入和读取，避免缓冲区溢出，对小消息有效，但足以处理戴着派对帽子跳舞的猫的最大视频？

• 4 如何处理无法立即传递的消息？

特别是，如果我们在等待组件重新上线？我们是丢弃消息，将它们放入数据库还是内存队列？

• 5 在哪里存储消息队列？

如果从队列中读取的组件非常慢并导致我们的队列堆积，会发生什么情况？那么我们的策略是什么呢？

• 6 如何处理丢失的消息？

我们是等待新数据，请求重新发送，还是构建某种可靠性层来确保消息不会丢失？如果该层本身崩溃怎么办？

• 7 如果我们需要使用不同的网络传输怎么办？

比如说，组播而不是TCP单播？还是IPv6？我们是否需要重写应用程序，或者是否在某个层中抽象了传输？

• 8 我们如何路由消息？

我们可以向多个对等方发送相同的消息吗？我们可以将回复发回给原始请求者吗？

• 9 我们如何为另一种语言编写 API？

我们是重新实现线级协议还是重新打包库？如果是前者，我们如何保证高效稳定的堆栈？如果是后者，我们如何保证互操作性？

• 10 我们如何表示数据，以便可以在不同的架构之间读取数据？

我们是否对数据类型强制执行特定的编码？这在多大程度上是消息传递系统的工作，而不是更高层的工作？

• 11 我们如何处理网络错误？

我们是等待并重试，默默地忽略它们，还是中止？

2 使用zeromq的步骤

zeromq是一个只需链接的库，没有任何其他依赖项。

没有额外的移动部件，因此没有额外的风险。它应该在任何操作系统上运行，并与任何编程语言一起使用

• zeroMQ的特点：

它在后台线程中异步处理 I/O。它们使用无锁数据结构与应用程序线程进行通信，因此并发 ZeroMQ 应用程序不需要锁、信号量或其他等待状态。

组件可以动态地来来去去，ZeroMQ 会自动重新连接。这意味着您可以按任何顺序启动组件。您可以创建“面向服务的架构”（SOA），其中服务可以随时加入和离开网络。

它会在需要时自动将消息排队。它智能地做到这一点，在排队之前将消息推送到尽可能靠近接收器的位置。

它有处理过满队列（称为“高水位线”）的方法。当队列已满时，ZeroMQ 会自动阻止发送者或丢弃消息，具体取决于您正在执行的消息传递类型（所谓的“模式”）。

它允许您的应用程序通过任意传输相互通信：TCP、多播、进程内、进程间。无需更改代码即可使用其他传输。

它使用取决于消息传递模式的不同策略安全地处理缓慢/被阻止的读者。

它允许您使用各种模式（例如请求-回复和 pub-sub）路由消息。这些模式是创建拓扑和网络结构的方式。

它允许您创建代理，以便通过单个调用对消息进行排队、转发或捕获消息。代理可以降低网络的互连复杂性。

它使用网络上的简单框架，完全按照发送的方式传递整个消息。如果您编写 10k 消息，您将收到 10k 消息。

它不会对消息施加任何格式。它们是从零到千兆字节大小的 Blob。当您想要表示数据时，您可以在上面选择其他一些产品，例如 msgpack、Google 的协议缓冲区等。

它通过在有意义的情况下自动重试来智能地处理网络错误。

它可以减少您的碳足迹。用更少的 CPU 做更多的事情意味着您的机箱使用更少的功率，并且您可以延长旧机箱的使用时间。Al Gore 会喜欢 ZeroMQ。

3 小结

ZeroMQ 是“消息模式库”而非完整队列，适合开发者精细控制通信逻辑；而 Kafka/RabbitMQ/NATS 是“产品级”解决方案，提供开箱即用的可靠性。

在 Go 生态中，NATS 通常比 ZeroMQ 更受青睐（因维护更活跃），而 Java 生态仍以 Kafka/RabbitMQ 为主导。