Chapter 2 - Sockets and Patterns
第 2 章 - 套接字与模式#

In Chapter 1 - Basics we took ZeroMQ for a drive, with some basic examples of the main ZeroMQ patterns: request-reply, pub-sub, and pipeline. In this chapter, we’re going to get our hands dirty and start to learn how to use these tools in real programs.
在第 1 章 - 基础中，我们通过一些基本示例体验了 ZeroMQ 的主要模式：请求-响应、发布-订阅和流水线。在本章中，我们将深入实践，开始学习如何在实际程序中使用这些工具。

We’ll cover: 我们将涵盖：

How to create and work with ZeroMQ sockets.
如何创建和使用 ZeroMQ 套接字。
How to send and receive messages on sockets.
如何在套接字上发送和接收消息。
How to build your apps around ZeroMQ’s asynchronous I/O model.
如何围绕 ZeroMQ 的异步 I/O 模型构建应用程序。
How to handle multiple sockets in one thread.
如何在一个线程中处理多个套接字。
How to handle fatal and nonfatal errors properly.
如何正确处理致命和非致命错误。
How to handle interrupt signals like Ctrl-C.
如何处理中断信号，如 Ctrl-C。
How to shut down a ZeroMQ application cleanly.
如何干净地关闭 ZeroMQ 应用程序。
How to check a ZeroMQ application for memory leaks.
如何检查 ZeroMQ 应用程序的内存泄漏。
How to send and receive multipart messages.
如何发送和接收多部分消息。
How to forward messages across networks.
如何在网络间转发消息。
How to build a simple message queuing broker.
如何构建一个简单的消息队列代理。
How to write multithreaded applications with ZeroMQ.
如何使用 ZeroMQ 编写多线程应用程序。
How to use ZeroMQ to signal between threads.
如何使用 ZeroMQ 在线程之间发送信号。
How to use ZeroMQ to coordinate a network of nodes.
如何使用 ZeroMQ 协调一个节点网络。
How to create and use message envelopes for pub-sub.
如何为发布-订阅创建和使用消息信封。
Using the HWM (high-water mark) to protect against memory overflows.
使用 HWM（高水位标记）防止内存溢出。

The Socket API
套接字 API#

To be perfectly honest, ZeroMQ does a kind of switch-and-bait on you, for which we don’t apologize. It’s for your own good and it hurts us more than it hurts you. ZeroMQ presents a familiar socket-based API, which requires great effort for us to hide a bunch of message-processing engines. However, the result will slowly fix your world view about how to design and write distributed software.
说实话，ZeroMQ 对你有点“诱敌深入”，对此我们不感到抱歉。这是为了你好，对我们来说甚至比对你更痛苦。ZeroMQ 呈现了一个熟悉的基于套接字的 API，而我们付出了巨大努力来隐藏一堆消息处理引擎。然而，最终结果会慢慢改变你对如何设计和编写分布式软件的世界观。

Sockets are the de facto standard API for network programming, as well as being useful for stopping your eyes from falling onto your cheeks. One thing that makes ZeroMQ especially tasty to developers is that it uses sockets and messages instead of some other arbitrary set of concepts. Kudos to Martin Sustrik for pulling this off. It turns “Message Oriented Middleware”, a phrase guaranteed to send the whole room off to Catatonia, into “Extra Spicy Sockets!”, which leaves us with a strange craving for pizza and a desire to know more.
套接字是网络编程的事实标准 API，同时也有助于防止你的眼睛掉到脸颊上。ZeroMQ 对开发者特别有吸引力的一点是它使用套接字和消息，而不是其他任意的一套概念。向 Martin Sustrik 致敬，他做到了这一点。它将“面向消息的中间件”——一个保证让全场陷入昏睡的词汇——变成了“超辣套接字！”，这让我们奇怪地渴望披萨，并且想了解更多。

Like a favorite dish, ZeroMQ sockets are easy to digest. Sockets have a life in four parts, just like BSD sockets:
就像一道拿手菜，ZeroMQ 套接字易于理解。套接字的生命周期分为四个部分，就像 BSD 套接字一样：

Creating and destroying sockets, which go together to form a karmic circle of socket life (see zmq_socket(), zmq_close()).
创建和销毁套接字，这两者共同构成了套接字生命周期的因果循环（参见 zmq_socket() ， zmq_close() ）。
Configuring sockets by setting options on them and checking them if necessary (see zmq_setsockopt(), zmq_getsockopt()).
通过设置选项来配置套接字，并在必要时检查它们（参见 zmq_setsockopt() ， zmq_getsockopt() ）。
Plugging sockets into the network topology by creating ZeroMQ connections to and from them (see zmq_bind(), zmq_connect()).
通过创建 ZeroMQ 连接将套接字插入网络拓扑中，实现与套接字的双向连接（参见 zmq_bind() ， zmq_connect() ）。
Using the sockets to carry data by writing and receiving messages on them (see zmq_msg_send(), zmq_msg_recv()).
使用套接字通过写入和接收消息来传输数据（参见 zmq_msg_send() ， zmq_msg_recv() ）。

Note that sockets are always void pointers, and messages (which we’ll come to very soon) are structures. So in C you pass sockets as-such, but you pass addresses of messages in all functions that work with messages, like zmq_msg_send() and zmq_msg_recv(). As a mnemonic, realize that “in ZeroMQ, all your sockets belong to us”, but messages are things you actually own in your code.
请注意，套接字始终是无类型指针，而消息（我们很快会介绍）是结构体。因此，在 C 语言中，套接字直接传递，但在所有处理消息的函数中，如 zmq_msg_send() 和 zmq_msg_recv() ，传递的是消息的地址。作为记忆提示，请记住“在 ZeroMQ 中，所有的套接字都属于我们”，但消息是你在代码中实际拥有的对象。

Creating, destroying, and configuring sockets works as you’d expect for any object. But remember that ZeroMQ is an asynchronous, elastic fabric. This has some impact on how we plug sockets into the network topology and how we use the sockets after that.
创建、销毁和配置套接字的方式与任何对象的操作相同。但请记住，ZeroMQ 是一个异步的、弹性的通信框架。这会影响我们如何将套接字插入网络拓扑，以及之后如何使用这些套接字。

Plugging Sockets into the Topology
将套接字插入拓扑结构#

To create a connection between two nodes, you use zmq_bind() in one node and zmq_connect() in the other. As a general rule of thumb, the node that does zmq_bind() is a “server”, sitting on a well-known network address, and the node which does zmq_connect() is a “client”, with unknown or arbitrary network addresses. Thus we say that we “bind a socket to an endpoint” and “connect a socket to an endpoint”, the endpoint being that well-known network address.
要在两个节点之间创建连接，你需要在一个节点使用 zmq_bind() ，在另一个节点使用 zmq_connect() 。一般来说，执行 zmq_bind() 的节点是“服务器”，位于一个众所周知的网络地址上，而执行 zmq_connect() 的节点是“客户端”，其网络地址未知或任意。因此，我们说“将套接字绑定到端点”和“将套接字连接到端点”，端点即那个众所周知的网络地址。

ZeroMQ connections are somewhat different from classic TCP connections. The main notable differences are:
ZeroMQ 连接与经典的 TCP 连接有所不同。主要的显著区别有：

They go across an arbitrary transport (inproc, ipc, tcp, pgm, or epgm). See zmq_inproc(), zmq_ipc(), zmq_tcp(), zmq_pgm(), and zmq_epgm().
它们可以通过任意传输（ inproc 、 ipc 、 tcp 、 pgm 或 epgm ）进行。参见 zmq_inproc() 、 zmq_ipc() 、 zmq_tcp() 、 zmq_pgm() 和 zmq_epgm() 。
One socket may have many outgoing and many incoming connections.
一个套接字可以有多个出站和多个入站连接。
There is no zmq_accept() method. When a socket is bound to an endpoint it automatically starts accepting connections.
没有 zmq_accept () 方法。当套接字绑定到一个端点时，它会自动开始接受连接。
The network connection itself happens in the background, and ZeroMQ will automatically reconnect if the network connection is broken (e.g., if the peer disappears and then comes back).
网络连接本身在后台进行，如果网络连接中断（例如，对等方消失然后又回来），ZeroMQ 会自动重新连接。
Your application code cannot work with these connections directly; they are encapsulated under the socket.
您的应用程序代码无法直接操作这些连接；它们被封装在套接字下。

Many architectures follow some kind of client/server model, where the server is the component that is most static, and the clients are the components that are most dynamic, i.e., they come and go the most. There are sometimes issues of addressing: servers will be visible to clients, but not necessarily vice versa. So mostly it’s obvious which node should be doing zmq_bind() (the server) and which should be doing zmq_connect() (the client). It also depends on the kind of sockets you’re using, with some exceptions for unusual network architectures. We’ll look at socket types later.
许多架构遵循某种客户端/服务器模型，其中服务器是最静态的组件，客户端是最动态的组件，即它们最频繁地出现和消失。有时会存在寻址问题：服务器对客户端可见，但客户端不一定对服务器可见。因此，大多数情况下很明显哪个节点应该执行 zmq_bind() （服务器），哪个应该执行 zmq_connect() （客户端）。这也取决于您使用的套接字类型，某些不寻常的网络架构会有例外。我们稍后会介绍套接字类型。

Now, imagine we start the client before we start the server. In traditional networking, we get a big red Fail flag. But ZeroMQ lets us start and stop pieces arbitrarily. As soon as the client node does zmq_connect(), the connection exists and that node can start to write messages to the socket. At some stage (hopefully before messages queue up so much that they start to get discarded, or the client blocks), the server comes alive, does a zmq_bind(), and ZeroMQ starts to deliver messages.
现在，想象一下我们在启动服务器之前先启动客户端。在传统网络中，我们会遇到一个大大的失败标志。但 ZeroMQ 允许我们任意启动和停止各个部分。只要客户端节点执行了 zmq_connect() ，连接就存在了，该节点就可以开始向套接字写入消息。在某个阶段（希望是在消息积压过多以至于开始被丢弃，或者客户端阻塞之前），服务器启动，执行 zmq_bind() ，ZeroMQ 就开始传递消息。

A server node can bind to many endpoints (that is, a combination of protocol and address) and it can do this using a single socket. This means it will accept connections across different transports:
服务器节点可以绑定到多个端点（即协议和地址的组合），并且可以使用单个套接字完成此操作。这意味着它将接受跨不同传输的连接：


zmq_bind (socket, "tcp://*:5555");
zmq_bind (socket, "tcp://*:9999");
zmq_bind (socket, "inproc://somename");

With most transports, you cannot bind to the same endpoint twice, unlike for example in UDP. The ipc transport does, however, let one process bind to an endpoint already used by a first process. It’s meant to allow a process to recover after a crash.
对于大多数传输方式，您不能对同一端点进行两次绑定，这与 UDP 等协议不同。然而， ipc 传输允许一个进程绑定到已被第一个进程使用的端点。它旨在允许进程在崩溃后恢复。

Although ZeroMQ tries to be neutral about which side binds and which side connects, there are differences. We’ll see these in more detail later. The upshot is that you should usually think in terms of “servers” as static parts of your topology that bind to more or less fixed endpoints, and “clients” as dynamic parts that come and go and connect to these endpoints. Then, design your application around this model. The chances that it will “just work” are much better like that.
尽管 ZeroMQ 试图对哪一方绑定、哪一方连接保持中立，但两者之间还是存在差异。我们稍后会更详细地讨论这些差异。结论是，您通常应该将“服务器”视为拓扑中绑定到或多或少固定端点的静态部分，而“客户端”则是动态部分，随时连接和断开这些端点。然后，围绕这个模型设计您的应用程序。这样做，它“能正常工作”的可能性会大大提高。

Sockets have types. The socket type defines the semantics of the socket, its policies for routing messages inwards and outwards, queuing, etc. You can connect certain types of socket together, e.g., a publisher socket and a subscriber socket. Sockets work together in “messaging patterns”. We’ll look at this in more detail later.
套接字有类型。套接字类型定义了套接字的语义、消息的进出路由策略、排队等规则。您可以将某些类型的套接字连接在一起，例如发布者套接字和订阅者套接字。套接字协同工作形成“消息模式”。我们稍后会更详细地介绍这一点。

It’s the ability to connect sockets in these different ways that gives ZeroMQ its basic power as a message queuing system. There are layers on top of this, such as proxies, which we’ll get to later. But essentially, with ZeroMQ you define your network architecture by plugging pieces together like a child’s construction toy.
正是能够以这些不同方式连接套接字，使得 ZeroMQ 作为消息队列系统具备了其基本的强大功能。在此之上还有一些层，比如代理，我们稍后会讲到。但本质上，使用 ZeroMQ 你可以像玩儿童积木一样，通过拼接各个部分来定义你的网络架构。

Sending and Receiving Messages
发送和接收消息#

To send and receive messages you use the zmq_msg_send() and zmq_msg_recv() methods. The names are conventional, but ZeroMQ’s I/O model is different enough from the classic TCP model that you will need time to get your head around it.
要发送和接收消息，你使用 zmq_msg_send() 和 zmq_msg_recv() 方法。名称是约定俗成的，但 ZeroMQ 的 I/O 模型与经典的 TCP 模型有足够的不同，你需要时间来理解它。

Figure 9 - TCP sockets are 1 to 1
图 9 - TCP 套接字是一对一的

Let’s look at the main differences between TCP sockets and ZeroMQ sockets when it comes to working with data:
让我们来看一下在处理数据时，TCP 套接字和 ZeroMQ 套接字之间的主要区别：

ZeroMQ sockets carry messages, like UDP, rather than a stream of bytes as TCP does. A ZeroMQ message is length-specified binary data. We’ll come to messages shortly; their design is optimized for performance and so a little tricky.
ZeroMQ 套接字传递的是消息，类似于 UDP，而不是像 TCP 那样传输字节流。ZeroMQ 消息是长度指定的二进制数据。我们稍后会详细介绍消息；它们的设计经过性能优化，因此有些复杂。
ZeroMQ sockets do their I/O in a background thread. This means that messages arrive in local input queues and are sent from local output queues, no matter what your application is busy doing.
ZeroMQ 套接字在后台线程中进行 I/O 操作。这意味着无论您的应用程序正在忙什么，消息都会到达本地输入队列，并从本地输出队列发送。
ZeroMQ sockets have one-to-N routing behavior built-in, according to the socket type.
ZeroMQ 套接字根据套接字类型内置了一对多的路由行为。

The zmq_send() method does not actually send the message to the socket connection(s). It queues the message so that the I/O thread can send it asynchronously. It does not block except in some exception cases. So the message is not necessarily sent when zmq_send() returns to your application.
zmq_send() 方法实际上并不会将消息发送到套接字连接。它会将消息排入队列，以便 I/O 线程可以异步发送。除了一些例外情况外，它不会阻塞。因此，当 zmq_send() 返回到您的应用程序时，消息不一定已经发送。

Unicast Transports 单播传输#

ZeroMQ provides a set of unicast transports (inproc, ipc, and tcp) and multicast transports (epgm, pgm). Multicast is an advanced technique that we’ll come to later. Don’t even start using it unless you know that your fan-out ratios will make 1-to-N unicast impossible.
ZeroMQ 提供了一组单播传输（ inproc 、 ipc 和 tcp ）以及多播传输（epgm、pgm）。多播是一种高级技术，我们稍后会介绍。除非您确定您的扇出比使得 1 对 N 的单播不可能，否则不要开始使用它。

For most common cases, use tcp, which is a disconnected TCP transport. It is elastic, portable, and fast enough for most cases. We call this disconnected because ZeroMQ’s tcp transport doesn’t require that the endpoint exists before you connect to it. Clients and servers can connect and bind at any time, can go and come back, and it remains transparent to applications.
对于大多数常见情况，使用 tcp ，这是一种无连接的 TCP 传输。它具有弹性、可移植，并且速度足够快。我们称之为无连接，是因为 ZeroMQ 的 tcp 传输不要求端点在连接之前必须存在。客户端和服务器可以随时连接和绑定，可以断开后再重新连接，这对应用程序来说是透明的。

The inter-process ipc transport is disconnected, like tcp. It has one limitation: it does not yet work on Windows. By convention we use endpoint names with an “.ipc” extension to avoid potential conflict with other file names. On UNIX systems, if you use ipc endpoints you need to create these with appropriate permissions otherwise they may not be shareable between processes running under different user IDs. You must also make sure all processes can access the files, e.g., by running in the same working directory.
进程间 ipc 传输是断开连接的，类似于 tcp 。它有一个限制：目前尚不支持 Windows 系统。按照惯例，我们使用带有“.ipc”扩展名的端点名称，以避免与其他文件名发生潜在冲突。在 UNIX 系统上，如果使用 ipc 端点，则需要以适当的权限创建这些端点，否则它们可能无法在不同用户 ID 下运行的进程之间共享。你还必须确保所有进程都能访问这些文件，例如，通过在相同的工作目录下运行。

The inter-thread transport, inproc, is a connected signaling transport. It is much faster than tcp or ipc. This transport has a specific limitation compared to tcp and ipc: the server must issue a bind before any client issues a connect. This was fixed in ZeroMQ v4.0 and later versions.
线程间传输 inproc 是一种连接的信号传输方式。它比 tcp 或 ipc 快得多。与 tcp 和 ipc 相比，这种传输有一个特定的限制：服务器必须先执行 bind 操作，然后客户端才能执行 connect 操作。这个问题在 ZeroMQ v4.0 及更高版本中已被修复。

ZeroMQ is Not a Neutral Carrier
ZeroMQ 不是中立的载体#

A common question that newcomers to ZeroMQ ask (it’s one I’ve asked myself) is, “how do I write an XYZ server in ZeroMQ?” For example, “how do I write an HTTP server in ZeroMQ?” The implication is that if we use normal sockets to carry HTTP requests and responses, we should be able to use ZeroMQ sockets to do the same, only much faster and better.
ZeroMQ 新手常问的一个问题（我自己也问过）是，“如何用 ZeroMQ 编写一个 XYZ 服务器？”例如，“如何用 ZeroMQ 编写一个 HTTP 服务器？”其含义是，如果我们使用普通套接字来传输 HTTP 请求和响应，那么我们应该也能用 ZeroMQ 套接字做同样的事情，只是速度更快、效果更好。

The answer used to be “this is not how it works”. ZeroMQ is not a neutral carrier: it imposes a framing on the transport protocols it uses. This framing is not compatible with existing protocols, which tend to use their own framing. For example, compare an HTTP request and a ZeroMQ request, both over TCP/IP.
答案过去是“这不是它的工作方式”。ZeroMQ 不是一个中立的载体：它对所使用的传输协议施加了帧结构。这种帧结构与现有协议不兼容，后者往往使用自己的帧结构。例如，比较通过 TCP/IP 传输的 HTTP 请求和 ZeroMQ 请求。

Figure 10 - HTTP on the Wire
图 10 - 网络上的 HTTP

The HTTP request uses CR-LF as its simplest framing delimiter, whereas ZeroMQ uses a length-specified frame. So you could write an HTTP-like protocol using ZeroMQ, using for example the request-reply socket pattern. But it would not be HTTP.
HTTP 请求使用 CR-LF 作为最简单的帧定界符，而 ZeroMQ 使用长度指定的帧。因此，你可以使用 ZeroMQ 编写类似 HTTP 的协议，例如使用请求-应答套接字模式。但它不会是 HTTP。

Figure 11 - ZeroMQ on the Wire
图 11 - 网络上的 ZeroMQ

Since v3.3, however, ZeroMQ has a socket option called ZMQ_ROUTER_RAW that lets you read and write data without the ZeroMQ framing. You could use this to read and write proper HTTP requests and responses. Hardeep Singh contributed this change so that he could connect to Telnet servers from his ZeroMQ application. At time of writing this is still somewhat experimental, but it shows how ZeroMQ keeps evolving to solve new problems. Maybe the next patch will be yours.
然而，从 v3.3 开始，ZeroMQ 引入了一个名为 ZMQ_ROUTER_RAW 的套接字选项，允许你在不使用 ZeroMQ 帧格式的情况下读写数据。你可以用它来读写标准的 HTTP 请求和响应。Hardeep Singh 贡献了这项改动，以便他能从 ZeroMQ 应用程序连接到 Telnet 服务器。撰写本文时，这项功能仍处于实验阶段，但它展示了 ZeroMQ 如何不断发展以解决新问题。也许下一个补丁就是你的。

I/O Threads I/O 线程#

We said that ZeroMQ does I/O in a background thread. One I/O thread (for all sockets) is sufficient for all but the most extreme applications. When you create a new context, it starts with one I/O thread. The general rule of thumb is to allow one I/O thread per gigabyte of data in or out per second. To raise the number of I/O threads, use the zmq_ctx_set() call before creating any sockets:
我们之前提到 ZeroMQ 在后台线程中进行 I/O 操作。对于除极端应用外，单个 I/O 线程（处理所有套接字）就足够了。当你创建一个新上下文时，它默认启动一个 I/O 线程。一般经验法则是每秒传入或传出一 GB 数据分配一个 I/O 线程。要增加 I/O 线程数量，请在创建任何套接字之前使用 zmq_ctx_set() 调用：


int io_threads = 4;
void *context = zmq_ctx_new ();
zmq_ctx_set (context, ZMQ_IO_THREADS, io_threads);
assert (zmq_ctx_get (context, ZMQ_IO_THREADS) == io_threads);

We’ve seen that one socket can handle dozens, even thousands of connections at once. This has a fundamental impact on how you write applications. A traditional networked application has one process or one thread per remote connection, and that process or thread handles one socket. ZeroMQ lets you collapse this entire structure into a single process and then break it up as necessary for scaling.
我们已经看到，一个套接字可以同时处理数十个，甚至数千个连接。这对你编写应用程序的方式有根本性的影响。传统的网络应用程序为每个远程连接创建一个进程或线程，该进程或线程处理一个套接字。而 ZeroMQ 允许你将整个结构合并到单个进程中，然后根据需要拆分以实现扩展。

If you are using ZeroMQ for inter-thread communications only (i.e., a multithreaded application that does no external socket I/O) you can set the I/O threads to zero. It’s not a significant optimization though, more of a curiosity.
如果你仅使用 ZeroMQ 进行线程间通信（即一个不进行外部套接字 I/O 的多线程应用程序），你可以将 I/O 线程数设置为零。不过这并不是一个显著的优化，更像是一种好奇的设置。

Messaging Patterns 消息传递模式#

Underneath the brown paper wrapping of ZeroMQ’s socket API lies the world of messaging patterns. If you have a background in enterprise messaging, or know UDP well, these will be vaguely familiar. But to most ZeroMQ newcomers, they are a surprise. We’re so used to the TCP paradigm where a socket maps one-to-one to another node.
在 ZeroMQ 套接字 API 的棕色纸包装下，隐藏着消息模式的世界。如果你有企业消息传递的背景，或者熟悉 UDP，这些模式会有些熟悉。但对大多数 ZeroMQ 新手来说，这些是一个惊喜。我们已经习惯了 TCP 范式，即一个套接字一对一映射到另一个节点。

Let’s recap briefly what ZeroMQ does for you. It delivers blobs of data (messages) to nodes, quickly and efficiently. You can map nodes to threads, processes, or nodes. ZeroMQ gives your applications a single socket API to work with, no matter what the actual transport (like in-process, inter-process, TCP, or multicast). It automatically reconnects to peers as they come and go. It queues messages at both sender and receiver, as needed. It limits these queues to guard processes against running out of memory. It handles socket errors. It does all I/O in background threads. It uses lock-free techniques for talking between nodes, so there are never locks, waits, semaphores, or deadlocks.
让我们简要回顾一下 ZeroMQ 为你做了什么。它将数据块（消息）快速高效地传递给节点。你可以将节点映射到线程、进程或物理节点。ZeroMQ 为你的应用程序提供了一个统一的套接字 API，无论实际传输方式是进程内、进程间、TCP 还是多播。它会自动在对等方上线和下线时重新连接。它根据需要在发送方和接收方排队消息。它限制这些队列的大小，以防止进程内存耗尽。它处理套接字错误。所有 I/O 操作都在后台线程中完成。它使用无锁技术进行节点间通信，因此不会出现锁、等待、信号量或死锁。

But cutting through that, it routes and queues messages according to precise recipes called patterns. It is these patterns that provide ZeroMQ’s intelligence. They encapsulate our hard-earned experience of the best ways to distribute data and work. ZeroMQ’s patterns are hard-coded but future versions may allow user-definable patterns.
但归根结底，它根据称为模式的精确方案路由和排队消息。正是这些模式赋予了 ZeroMQ 智能。它们封装了我们通过实践积累的最佳数据分发和工作方式的经验。ZeroMQ 的模式是硬编码的，但未来版本可能允许用户自定义模式。

ZeroMQ patterns are implemented by pairs of sockets with matching types. In other words, to understand ZeroMQ patterns you need to understand socket types and how they work together. Mostly, this just takes study; there is little that is obvious at this level.
ZeroMQ 模式是由成对的匹配类型的套接字实现的。换句话说，要理解 ZeroMQ 模式，你需要了解套接字类型及其如何协同工作。大多数情况下，这只需要学习；在这个层面上几乎没有显而易见的东西。

The built-in core ZeroMQ patterns are:
内置的核心 ZeroMQ 模式有：

Request-reply, which connects a set of clients to a set of services. This is a remote procedure call and task distribution pattern.
请求-响应（Request-reply），它连接一组客户端和一组服务端。这是一种远程过程调用和任务分发模式。
Pub-sub, which connects a set of publishers to a set of subscribers. This is a data distribution pattern.
发布-订阅（Pub-sub），它连接一组发布者和一组订阅者。这是一种数据分发模式。
Pipeline, which connects nodes in a fan-out/fan-in pattern that can have multiple steps and loops. This is a parallel task distribution and collection pattern.
Pipeline，连接节点形成一个多步骤和循环的分发/汇聚模式。这是一种并行任务分发和收集模式。
Exclusive pair, which connects two sockets exclusively. This is a pattern for connecting two threads in a process, not to be confused with “normal” pairs of sockets.
Exclusive pair，专门连接两个套接字。这是一种用于连接进程中两个线程的模式，不应与“普通”套接字对混淆。

We looked at the first three of these in Chapter 1 - Basics, and we’ll see the exclusive pair pattern later in this chapter. The zmq_socket() man page is fairly clear about the patterns – it’s worth reading several times until it starts to make sense. These are the socket combinations that are valid for a connect-bind pair (either side can bind):
我们在第 1 章《基础》中已经看过前三种模式，本章稍后会介绍 exclusive pair 模式。 zmq_socket() 手册页对这些模式解释得相当清楚——值得多读几遍，直到理解为止。这些是适用于 connect-bind 对（任一方都可以 bind）的有效套接字组合：

PUB and SUB PUB 和 SUB
REQ and REP REQ 和 REP
REQ and ROUTER (take care, REQ inserts an extra null frame)
REQ 和 ROUTER（注意，REQ 会插入一个额外的空帧）
DEALER and REP (take care, REP assumes a null frame)
DEALER 和 REP（注意，REP 假设有一个空帧）
DEALER and ROUTER DEALER 和 ROUTER
DEALER and DEALER DEALER 和 DEALER
ROUTER and ROUTER ROUTER 和 ROUTER
PUSH and PULL PUSH 和 PULL
PAIR and PAIR PAIR 和 PAIR

You’ll also see references to XPUB and XSUB sockets, which we’ll come to later (they’re like raw versions of PUB and SUB). Any other combination will produce undocumented and unreliable results, and future versions of ZeroMQ will probably return errors if you try them. You can and will, of course, bridge other socket types via code, i.e., read from one socket type and write to another.
你还会看到对 XPUB 和 XSUB 套接字的引用，我们稍后会讲到它们（它们类似于 PUB 和 SUB 的原始版本）。任何其他组合都会产生未记录且不可靠的结果，未来版本的 ZeroMQ 可能会在你尝试时返回错误。当然，你可以并且会通过代码桥接其他套接字类型，即从一种套接字类型读取并写入另一种。

High-Level Messaging Patterns
高级消息传递模式#

These four core patterns are cooked into ZeroMQ. They are part of the ZeroMQ API, implemented in the core C++ library, and are guaranteed to be available in all fine retail stores.
这四个核心模式是内置于 ZeroMQ 的。它们是 ZeroMQ API 的一部分，在核心 C++ 库中实现，并保证在所有正规零售渠道中可用。

On top of those, we add high-level messaging patterns. We build these high-level patterns on top of ZeroMQ and implement them in whatever language we’re using for our application. They are not part of the core library, do not come with the ZeroMQ package, and exist in their own space as part of the ZeroMQ community. For example the Majordomo pattern, which we explore in Chapter 4 - Reliable Request-Reply Patterns, sits in the GitHub Majordomo project in the ZeroMQ organization.
在此基础上，我们添加了高级消息传递模式。我们在 ZeroMQ 之上构建这些高级模式，并用我们应用程序所用的任何语言实现它们。它们不是核心库的一部分，不随 ZeroMQ 包一起提供，而是作为 ZeroMQ 社区的一部分存在于自己的空间中。例如 Majordomo 模式，我们将在第 4 章《可靠的请求-响应模式》中探讨，它位于 ZeroMQ 组织的 GitHub Majordomo 项目中。

One of the things we aim to provide you with in this book are a set of such high-level patterns, both small (how to handle messages sanely) and large (how to make a reliable pub-sub architecture).
本书旨在为您提供一套高级模式，既有小型的（如何理智地处理消息），也有大型的（如何构建可靠的发布-订阅架构）。

Working with Messages
消息处理#

The libzmq core library has in fact two APIs to send and receive messages. The zmq_send() and zmq_recv() methods that we’ve already seen and used are simple one-liners. We will use these often, but zmq_recv() is bad at dealing with arbitrary message sizes: it truncates messages to whatever buffer size you provide. So there’s a second API that works with zmq_msg_t structures, with a richer but more difficult API:
libzmq 核心库实际上有两个用于发送和接收消息的 API。我们已经见过并使用过的 zmq_send() 和 zmq_recv() 方法是简单的一行代码。我们会经常使用它们，但 zmq_recv() 在处理任意消息大小时表现不佳：它会将消息截断到您提供的缓冲区大小。因此，还有第二个 API，它使用 zmq_msg_t 结构，API 更丰富但更复杂：

Initialise a message: zmq_msg_init(), zmq_msg_init_size(), zmq_msg_init_data().
初始化消息： zmq_msg_init() ， zmq_msg_init_size() ， zmq_msg_init_data() 。
Sending and receiving a message: zmq_msg_send(), zmq_msg_recv().
发送和接收消息： zmq_msg_send() ， zmq_msg_recv() 。
Release a message: zmq_msg_close().
释放消息： zmq_msg_close() 。
Access message content: zmq_msg_data(), zmq_msg_size(), zmq_msg_more().
访问消息内容： zmq_msg_data() ， zmq_msg_size() ， zmq_msg_more() 。
Work with message properties: zmq_msg_get(), zmq_msg_set().
处理消息属性： zmq_msg_get() ， zmq_msg_set() 。
Message manipulation: zmq_msg_copy(), zmq_msg_move().
消息操作： zmq_msg_copy() ， zmq_msg_move() 。

On the wire, ZeroMQ messages are blobs of any size from zero upwards that fit in memory. You do your own serialization using protocol buffers, msgpack, JSON, or whatever else your applications need to speak. It’s wise to choose a data representation that is portable, but you can make your own decisions about trade-offs.
在传输层，ZeroMQ 消息是任意大小的内存块，从零字节起。你需要使用协议缓冲区、msgpack、JSON 或其他应用程序需要的格式自行进行序列化。选择一种可移植的数据表示方式是明智的，但你可以根据权衡自行决定。

In memory, ZeroMQ messages are zmq_msg_t structures (or classes depending on your language). Here are the basic ground rules for using ZeroMQ messages in C:
在内存中，ZeroMQ 消息是 zmq_msg_t 结构（或根据你的语言是类）。以下是在 C 语言中使用 ZeroMQ 消息的基本规则：

You create and pass around zmq_msg_t objects, not blocks of data.
你创建并传递的是 zmq_msg_t 对象，而不是数据块。
To read a message, you use zmq_msg_init() to create an empty message, and then you pass that to zmq_msg_recv().
要读取消息，您使用 zmq_msg_init() 创建一个空消息，然后将其传递给 zmq_msg_recv() 。
To write a message from new data, you use zmq_msg_init_size() to create a message and at the same time allocate a block of data of some size. You then fill that data using memcpy, and pass the message to zmq_msg_send().
要从新数据写入消息，您使用 zmq_msg_init_size() 创建一个消息，同时分配一块一定大小的数据。然后使用 memcpy 填充该数据，并将消息传递给 zmq_msg_send() 。
To release (not destroy) a message, you call zmq_msg_close(). This drops a reference, and eventually ZeroMQ will destroy the message.
要释放（而非销毁）消息，您调用 zmq_msg_close() 。这会减少一个引用，最终 ZeroMQ 会销毁该消息。
To access the message content, you use zmq_msg_data(). To know how much data the message contains, use zmq_msg_size().
要访问消息内容，您使用 zmq_msg_data() 。要知道消息包含多少数据，使用 zmq_msg_size() 。
Do not use zmq_msg_move(), zmq_msg_copy(), or zmq_msg_init_data() unless you read the man pages and know precisely why you need these.
除非你阅读了手册页并且确切知道为什么需要使用它们，否则不要使用 zmq_msg_move() 、 zmq_msg_copy() 或 zmq_msg_init_data() 。
After you pass a message to zmq_msg_send(), ØMQ will clear the message, i.e., set the size to zero. You cannot send the same message twice, and you cannot access the message data after sending it.
当你将消息传递给 zmq_msg_send() 后，ØMQ 会清除该消息，即将大小设置为零。你不能发送同一条消息两次，也不能在发送后访问消息数据。
These rules don’t apply if you use zmq_send() and zmq_recv(), to which you pass byte arrays, not message structures.
如果你使用 zmq_send() 和 zmq_recv() ，并传递字节数组而非消息结构体，则这些规则不适用。

If you want to send the same message more than once, and it’s sizable, create a second message, initialize it using zmq_msg_init(), and then use zmq_msg_copy() to create a copy of the first message. This does not copy the data but copies a reference. You can then send the message twice (or more, if you create more copies) and the message will only be finally destroyed when the last copy is sent or closed.
如果你想多次发送同一条较大的消息，可以创建第二条消息，使用 zmq_msg_init() 初始化它，然后使用 zmq_msg_copy() 创建第一条消息的副本。这不会复制数据，而是复制一个引用。这样你就可以发送该消息两次（或更多次，如果你创建了更多副本），消息只有在最后一个副本被发送或关闭时才会被最终销毁。

ZeroMQ also supports multipart messages, which let you send or receive a list of frames as a single on-the-wire message. This is widely used in real applications and we’ll look at that later in this chapter and in Chapter 3 - Advanced Request-Reply Patterns.
ZeroMQ 还支持多部分消息，允许你将一组帧作为单个网络传输消息发送或接收。这在实际应用中被广泛使用，我们将在本章后面以及第 3 章——高级请求-响应模式中详细介绍。

Frames (also called “message parts” in the ZeroMQ reference manual pages) are the basic wire format for ZeroMQ messages. A frame is a length-specified block of data. The length can be zero upwards. If you’ve done any TCP programming you’ll appreciate why frames are a useful answer to the question “how much data am I supposed to read of this network socket now?”
帧（在 ZeroMQ 参考手册中也称为“消息部分”）是 ZeroMQ 消息的基本传输格式。帧是一个指定长度的数据块。长度可以为零或更大。如果你有过 TCP 编程经验，就会理解为什么帧是回答“我现在应该从这个网络套接字读取多少数据？”这个问题的有用方案。

There is a wire-level protocol called ZMTP that defines how ZeroMQ reads and writes frames on a TCP connection. If you’re interested in how this works, the spec is quite short.
有一个名为 ZMTP 的传输层协议，定义了 ZeroMQ 如何在 TCP 连接上读写帧。如果你对其工作原理感兴趣，规范文档相当简短。

Originally, a ZeroMQ message was one frame, like UDP. We later extended this with multipart messages, which are quite simply series of frames with a “more” bit set to one, followed by one with that bit set to zero. The ZeroMQ API then lets you write messages with a “more” flag and when you read messages, it lets you check if there’s “more”.
最初，ZeroMQ 消息是单帧的，类似 UDP。后来我们扩展了多部分消息，它实际上是一系列帧，前面的帧的“more”位设置为 1，最后一帧的该位设置为 0。ZeroMQ API 允许你写带有“more”标志的消息，读取消息时也可以检查是否还有“more”。

In the low-level ZeroMQ API and the reference manual, therefore, there’s some fuzziness about messages versus frames. So here’s a useful lexicon:
在低级 ZeroMQ API 和参考手册中，消息与帧之间存在一些模糊之处。因此，这里有一个有用的词汇表：

A message can be one or more parts.
一个消息可以包含一个或多个部分。
These parts are also called “frames”.
这些部分也称为“帧”。
Each part is a zmq_msg_t object.
每个部分都是一个 zmq_msg_t 对象。
You send and receive each part separately, in the low-level API.
在低级 API 中，您需要分别发送和接收每个部分。
Higher-level APIs provide wrappers to send entire multipart messages.
高级 API 提供了封装，可以发送整个多部分消息。

Some other things that are worth knowing about messages:
关于消息，还有一些值得了解的内容：

You may send zero-length messages, e.g., for sending a signal from one thread to another.
您可以发送零长度消息，例如，用于从一个线程向另一个线程发送信号。
ZeroMQ guarantees to deliver all the parts (one or more) for a message, or none of them.
ZeroMQ 保证要么传递消息的所有部分（一个或多个），要么一个都不传递。
ZeroMQ does not send the message (single or multipart) right away, but at some indeterminate later time. A multipart message must therefore fit in memory.
ZeroMQ 不会立即发送消息（单部分或多部分），而是在某个不确定的稍后时间发送。因此，多部分消息必须能放入内存。
A message (single or multipart) must fit in memory. If you want to send files of arbitrary sizes, you should break them into pieces and send each piece as separate single-part messages. Using multipart data will not reduce memory consumption.
消息（单部分或多部分）必须能放入内存。如果你想发送任意大小的文件，应将其拆分成多个部分，并将每个部分作为单独的单部分消息发送。使用多部分数据不会减少内存消耗。
You must call zmq_msg_close() when finished with a received message, in languages that don’t automatically destroy objects when a scope closes. You don’t call this method after sending a message.
在不自动在作用域关闭时销毁对象的语言中，接收消息后必须调用 zmq_msg_close() 。发送消息后不需要调用此方法。

And to be repetitive, do not use zmq_msg_init_data() yet. This is a zero-copy method and is guaranteed to create trouble for you. There are far more important things to learn about ZeroMQ before you start to worry about shaving off microseconds.
再重复一遍，暂时不要使用 zmq_msg_init_data() 。这是一种零拷贝方法，肯定会给你带来麻烦。在你开始担心节省微秒级时间之前，有许多关于 ZeroMQ 更重要的内容需要学习。

This rich API can be tiresome to work with. The methods are optimized for performance, not simplicity. If you start using these you will almost definitely get them wrong until you’ve read the man pages with some care. So one of the main jobs of a good language binding is to wrap this API up in classes that are easier to use.
这个丰富的 API 使用起来可能会让人感到疲惫。方法是为了性能优化，而非简洁性。如果你开始使用这些方法，几乎肯定会出错，除非你仔细阅读了手册页。因此，一个好的语言绑定的主要任务之一就是将这个 API 封装成更易用的类。

Handling Multiple Sockets
处理多个套接字#

In all the examples so far, the main loop of most examples has been:
到目前为止，所有示例中的主循环大多是：

Wait for message on socket.
等待套接字上的消息。
Process message. 处理消息。
Repeat. 重复。

What if we want to read from multiple endpoints at the same time? The simplest way is to connect one socket to all the endpoints and get ZeroMQ to do the fan-in for us. This is legal if the remote endpoints are in the same pattern, but it would be wrong to connect a PULL socket to a PUB endpoint.
如果我们想同时从多个端点读取数据怎么办？最简单的方法是将一个套接字连接到所有端点，让 ZeroMQ 为我们执行汇聚操作。如果远程端点属于同一模式，这是合法的，但将 PULL 套接字连接到 PUB 端点则是错误的。

To actually read from multiple sockets all at once, use zmq_poll(). An even better way might be to wrap zmq_poll() in a framework that turns it into a nice event-driven reactor, but it’s significantly more work than we want to cover here.
要真正同时从多个套接字读取数据，请使用 zmq_poll() 。更好的方法可能是将 zmq_poll() 封装在一个框架中，将其变成一个良好的事件驱动反应器，但这比我们这里想要涵盖的内容要复杂得多。

Let’s start with a dirty hack, partly for the fun of not doing it right, but mainly because it lets me show you how to do nonblocking socket reads. Here is a simple example of reading from two sockets using nonblocking reads. This rather confused program acts both as a subscriber to weather updates, and a worker for parallel tasks:
让我们从一个简单的技巧开始，部分原因是为了体验不按常规操作的乐趣，但主要是因为它让我向你展示如何进行非阻塞套接字读取。这里有一个使用非阻塞读取从两个套接字读取数据的简单示例。这个有些混乱的程序既作为天气更新的订阅者，也作为并行任务的工作者：

msreader: Multiple socket reader in C++
msreader：C++中的多套接字读取器

//
//  Reading from multiple sockets in C++
//  This version uses a simple recv loop
//


#include "zhelpers.hpp"


int main (int argc, char *argv[])
{
    //  Prepare our context and sockets
    zmq::context_t context(1);

    //  Connect to task ventilator
    zmq::socket_t receiver(context, ZMQ_PULL);
    receiver.connect("tcp://localhost:5557");

    //  Connect to weather server
    zmq::socket_t subscriber(context, ZMQ_SUB);
    subscriber.connect("tcp://localhost:5556");
    subscriber.set(zmq::sockopt::subscribe, "10001 ");

    //  Process messages from both sockets
    //  We prioritize traffic from the task ventilator
    while (1) {
    	
        //  Process any waiting tasks
        bool rc;
        do {
            zmq::message_t task;
            if ((rc = receiver.recv(&task, ZMQ_DONTWAIT)) == true) {
                //  process task
            }
        } while(rc == true);
        
        //  Process any waiting weather updates
        do {
            zmq::message_t update;
            if ((rc = subscriber.recv(&update, ZMQ_DONTWAIT)) == true) {
                //  process weather update

            }
        } while(rc == true);
        
        //  No activity, so sleep for 1 msec
        s_sleep(1);
    }
    return 0;
}

The cost of this approach is some additional latency on the first message (the sleep at the end of the loop, when there are no waiting messages to process). This would be a problem in applications where submillisecond latency was vital. Also, you need to check the documentation for nanosleep() or whatever function you use to make sure it does not busy-loop.
这种方法的代价是在第一条消息上会有一些额外的延迟（循环末尾的休眠，当没有等待处理的消息时）。在亚毫秒延迟至关重要的应用中，这将是一个问题。此外，您需要查看 nanosleep() 或您使用的任何函数的文档，以确保它不会进行忙等待循环。

You can treat the sockets fairly by reading first from one, then the second rather than prioritizing them as we did in this example.
你可以通过先从一个套接字读取，然后再从第二个套接字读取，而不是像我们在这个例子中那样优先处理它们，从而实现对套接字的公平处理。

Now let’s see the same senseless little application done right, using zmq_poll():
现在让我们看看使用 zmq_poll() 正确完成的同样无意义的小应用：

mspoller: Multiple socket poller in C++
mspoller：C++中的多套接字轮询器

//
//  Reading from multiple sockets in C++
//  This version uses zmq_poll()
//

#include "zhelpers.hpp"


int main (int argc, char *argv[])
{
    zmq::context_t context(1);

    //  Connect to task ventilator
    zmq::socket_t receiver(context, ZMQ_PULL);
    receiver.connect("tcp://localhost:5557");

    //  Connect to weather server
    zmq::socket_t subscriber(context, ZMQ_SUB);
	subscriber.connect("tcp://localhost:5556");
    subscriber.set(zmq::sockopt::subscribe, "10001 ");

    //  Initialize poll set
    zmq::pollitem_t items [] = {
        { receiver, 0, ZMQ_POLLIN, 0 },
        { subscriber, 0, ZMQ_POLLIN, 0 }
    };
    //  Process messages from both sockets
    while (1) {
        zmq::message_t message;
        zmq::poll (&items [0], 2, -1);
        
        if (items [0].revents & ZMQ_POLLIN) {
            receiver.recv(&message);
            //  Process task
        }
        if (items [1].revents & ZMQ_POLLIN) {
            subscriber.recv(&message);
            //  Process weather update
        }
    }
    return 0;
}

The items structure has these four members:
items 结构包含以下四个成员：

typedef struct {
    void *socket;       //  ZeroMQ socket to poll on
    int fd;             //  OR, native file handle to poll on
    short events;       //  Events to poll on
    short revents;      //  Events returned after poll
} zmq_pollitem_t;

Multipart Messages 多部分消息#

ZeroMQ lets us compose a message out of several frames, giving us a “multipart message”. Realistic applications use multipart messages heavily, both for wrapping messages with address information and for simple serialization. We’ll look at reply envelopes later.
ZeroMQ 允许我们将消息由多个帧组成，形成“多部分消息”。实际应用中大量使用多部分消息，既用于为消息封装地址信息，也用于简单的序列化。我们稍后会讨论回复信封。

What we’ll learn now is simply how to blindly and safely read and write multipart messages in any application (such as a proxy) that needs to forward messages without inspecting them.
我们现在要学习的是如何在任何需要转发消息而不检查消息内容的应用（例如代理）中，盲目且安全地读取和写入多部分消息。

When you work with multipart messages, each part is a zmq_msg item. E.g., if you are sending a message with five parts, you must construct, send, and destroy five zmq_msg items. You can do this in advance (and store the zmq_msg items in an array or other structure), or as you send them, one-by-one.
处理多部分消息时，每个部分都是一个 zmq_msg 项。例如，如果你发送一个包含五个部分的消息，你必须构造、发送并销毁五个 zmq_msg 项。你可以提前完成这些操作（并将 zmq_msg 项存储在数组或其他结构中），也可以在发送时逐个处理。

Here is how we send the frames in a multipart message (we receive each frame into a message object):
以下是我们如何发送多部分消息中的帧（我们将每个帧接收到一个消息对象中）：


zmq_msg_send (&message, socket, ZMQ_SNDMORE);
...
zmq_msg_send (&message, socket, ZMQ_SNDMORE);
...
zmq_msg_send (&message, socket, 0);

Here is how we receive and process all the parts in a message, be it single part or multipart:
以下是我们如何接收并处理消息中的所有部分，无论是单部分还是多部分：


while (1) {
    zmq_msg_t message;
    zmq_msg_init (&message);
    zmq_msg_recv (&message, socket, 0);
    //  Process the message frame
    ...
    zmq_msg_close (&message);
    if (!zmq_msg_more (&message))
        break;      //  Last message frame
}

Some things to know about multipart messages:
关于多部分消息需要了解的一些事项：

When you send a multipart message, the first part (and all following parts) are only actually sent on the wire when you send the final part.
当你发送多部分消息时，第一部分（以及所有后续部分）只有在你发送最后一部分时才会真正通过网络发送。
If you are using zmq_poll(), when you receive the first part of a message, all the rest has also arrived.
如果您使用的是 zmq_poll() ，当您接收到消息的第一部分时，所有其余部分也已经到达。
You will receive all parts of a message, or none at all.
您将接收到消息的所有部分，或者一个都不会接收到。
Each part of a message is a separate zmq_msg item.
消息的每个部分都是一个独立的 zmq_msg 项。
You will receive all parts of a message whether or not you check the more property.
无论您是否检查 more 属性，您都会接收到消息的所有部分。
On sending, ZeroMQ queues message frames in memory until the last is received, then sends them all.
在发送时，ZeroMQ 会将消息帧排队存储在内存中，直到接收到最后一帧，然后一次性发送所有帧。
There is no way to cancel a partially sent message, except by closing the socket.
除了关闭套接字外，没有办法取消部分发送的消息。

Intermediaries and Proxies
中间件和代理#

ZeroMQ aims for decentralized intelligence, but that doesn’t mean your network is empty space in the middle. It’s filled with message-aware infrastructure and quite often, we build that infrastructure with ZeroMQ. The ZeroMQ plumbing can range from tiny pipes to full-blown service-oriented brokers. The messaging industry calls this intermediation, meaning that the stuff in the middle deals with either side. In ZeroMQ, we call these proxies, queues, forwarders, device, or brokers, depending on the context.
ZeroMQ 追求去中心化智能，但这并不意味着你的网络中间是空白的。它充满了对消息感知的基础设施，而且我们经常使用 ZeroMQ 来构建这些基础设施。ZeroMQ 的管道可以从微小的管道扩展到完整的面向服务的代理。消息传递行业称之为中介，意思是中间的部分处理双方的通信。在 ZeroMQ 中，我们根据上下文将这些称为代理（proxies）、队列（queues）、转发器（forwarders）、设备（device）或代理服务器（brokers）。

This pattern is extremely common in the real world and is why our societies and economies are filled with intermediaries who have no other real function than to reduce the complexity and scaling costs of larger networks. Real-world intermediaries are typically called wholesalers, distributors, managers, and so on.
这种模式在现实世界中极为常见，这也是为什么我们的社会和经济中充满了中间商，他们的唯一真正功能就是减少更大网络的复杂性和扩展成本。现实中的中间商通常被称为批发商、分销商、经理等。

The Dynamic Discovery Problem
动态发现问题#

One of the problems you will hit as you design larger distributed architectures is discovery. That is, how do pieces know about each other? It’s especially difficult if pieces come and go, so we call this the “dynamic discovery problem”.
在设计更大规模的分布式架构时，你会遇到的一个问题是发现。也就是说，组件如何相互了解？如果组件不断进出，这个问题尤其困难，因此我们称之为“动态发现问题”。

There are several solutions to dynamic discovery. The simplest is to entirely avoid it by hard-coding (or configuring) the network architecture so discovery is done by hand. That is, when you add a new piece, you reconfigure the network to know about it.
针对动态发现有几种解决方案。最简单的是完全避免它，通过硬编码（或配置）网络架构来手动完成发现。也就是说，当你添加一个新组件时，需要重新配置网络以识别它。

Figure 12 - Small-Scale Pub-Sub Network
图 12 - 小规模发布-订阅网络

In practice, this leads to increasingly fragile and unwieldy architectures. Let’s say you have one publisher and a hundred subscribers. You connect each subscriber to the publisher by configuring a publisher endpoint in each subscriber. That’s easy. Subscribers are dynamic; the publisher is static. Now say you add more publishers. Suddenly, it’s not so easy any more. If you continue to connect each subscriber to each publisher, the cost of avoiding dynamic discovery gets higher and higher.
在实际操作中，这会导致架构变得越来越脆弱且难以管理。假设你有一个发布者和一百个订阅者。你通过在每个订阅者中配置一个发布者端点来连接每个订阅者到发布者。这很简单。订阅者是动态的；发布者是静态的。现在假设你增加了更多的发布者。突然间，情况就不那么简单了。如果你继续将每个订阅者连接到每个发布者，避免动态发现的成本会越来越高。

Figure 13 - Pub-Sub Network with a Proxy
图 13 - 带代理的发布-订阅网络

There are quite a few answers to this, but the very simplest answer is to add an intermediary; that is, a static point in the network to which all other nodes connect. In classic messaging, this is the job of the message broker. ZeroMQ doesn’t come with a message broker as such, but it lets us build intermediaries quite easily.
对此有很多答案，但最简单的答案是添加一个中介；也就是说，在网络中设置一个静态点，所有其他节点都连接到该点。在传统消息传递中，这就是消息代理的职责。ZeroMQ 本身不带消息代理，但它让我们能够非常容易地构建中介。

You might wonder, if all networks eventually get large enough to need intermediaries, why don’t we simply have a message broker in place for all applications? For beginners, it’s a fair compromise. Just always use a star topology, forget about performance, and things will usually work. However, message brokers are greedy things; in their role as central intermediaries, they become too complex, too stateful, and eventually a problem.
你可能会想，如果所有网络最终都变得足够大以至于需要中介，为什么我们不直接为所有应用都设置一个消息代理？对于初学者来说，这是一种合理的折中方案。只要始终使用星型拓扑，忽略性能，事情通常都能正常运行。然而，消息代理是贪婪的存在；作为中央中介，它们变得过于复杂、过于有状态，最终成为一个问题。

It’s better to think of intermediaries as simple stateless message switches. A good analogy is an HTTP proxy; it’s there, but doesn’t have any special role. Adding a pub-sub proxy solves the dynamic discovery problem in our example. We set the proxy in the “middle” of the network. The proxy opens an XSUB socket, an XPUB socket, and binds each to well-known IP addresses and ports. Then, all other processes connect to the proxy, instead of to each other. It becomes trivial to add more subscribers or publishers.
最好将中介视为简单的无状态消息交换机。一个很好的类比是 HTTP 代理；它存在，但没有任何特殊角色。在我们的示例中，添加一个发布-订阅代理解决了动态发现问题。我们将代理设置在网络的“中间”。代理打开一个 XSUB 套接字和一个 XPUB 套接字，并将它们分别绑定到众所周知的 IP 地址和端口。然后，所有其他进程连接到代理，而不是彼此连接。这样，添加更多的订阅者或发布者变得非常简单。

Figure 14 - Extended Pub-Sub
图 14 - 扩展的发布-订阅模型

We need XPUB and XSUB sockets because ZeroMQ does subscription forwarding from subscribers to publishers. XSUB and XPUB are exactly like SUB and PUB except they expose subscriptions as special messages. The proxy has to forward these subscription messages from subscriber side to publisher side, by reading them from the XPUB socket and writing them to the XSUB socket. This is the main use case for XSUB and XPUB.
我们需要 XPUB 和 XSUB 套接字，因为 ZeroMQ 会将订阅信息从订阅者转发到发布者。XSUB 和 XPUB 与 SUB 和 PUB 完全相同，只是它们将订阅信息作为特殊消息暴露出来。代理必须将这些订阅消息从订阅者端转发到发布者端，通过从 XPUB 套接字读取并写入到 XSUB 套接字。这是 XSUB 和 XPUB 的主要使用场景。

Shared Queue (DEALER and ROUTER sockets)
共享队列（DEALER 和 ROUTER 套接字）#

In the Hello World client/server application, we have one client that talks to one service. However, in real cases we usually need to allow multiple services as well as multiple clients. This lets us scale up the power of the service (many threads or processes or nodes rather than just one). The only constraint is that services must be stateless, all state being in the request or in some shared storage such as a database.
在 Hello World 客户端/服务器应用程序中，我们有一个客户端与一个服务进行通信。然而，在实际情况下，我们通常需要允许多个服务以及多个客户端。这使我们能够扩展服务的能力（多个线程、进程或节点，而不仅仅是一个）。唯一的限制是服务必须是无状态的，所有状态都应包含在请求中或存储在某些共享存储中，例如数据库。

Figure 15 - Request Distribution
图 15 - 请求分发

There are two ways to connect multiple clients to multiple servers. The brute force way is to connect each client socket to multiple service endpoints. One client socket can connect to multiple service sockets, and the REQ socket will then distribute requests among these services. Let’s say you connect a client socket to three service endpoints; A, B, and C. The client makes requests R1, R2, R3, R4. R1 and R4 go to service A, R2 goes to B, and R3 goes to service C.
有两种方法可以将多个客户端连接到多个服务器。粗暴的方法是将每个客户端套接字连接到多个服务端点。一个客户端套接字可以连接到多个服务套接字，REQ 套接字随后会在这些服务之间分配请求。假设你将一个客户端套接字连接到三个服务端点：A、B 和 C。客户端发出请求 R1、R2、R3、R4。R1 和 R4 发送到服务 A，R2 发送到 B，R3 发送到服务 C。

This design lets you add more clients cheaply. You can also add more services. Each client will distribute its requests to the services. But each client has to know the service topology. If you have 100 clients and then you decide to add three more services, you need to reconfigure and restart 100 clients in order for the clients to know about the three new services.
这种设计让你可以低成本地添加更多客户端。你也可以添加更多服务。每个客户端会将请求分发给各个服务。但每个客户端必须知道服务的拓扑结构。如果你有 100 个客户端，然后决定再添加三个服务，你需要重新配置并重启这 100 个客户端，以便客户端能够识别这三个新服务。

That’s clearly not the kind of thing we want to be doing at 3 a.m. when our supercomputing cluster has run out of resources and we desperately need to add a couple of hundred of new service nodes. Too many static pieces are like liquid concrete: knowledge is distributed and the more static pieces you have, the more effort it is to change the topology. What we want is something sitting in between clients and services that centralizes all knowledge of the topology. Ideally, we should be able to add and remove services or clients at any time without touching any other part of the topology.
这显然不是我们想在凌晨 3 点做的事情——当我们的超级计算集群资源耗尽，急需添加几百个新的服务节点时。过多的静态组件就像液态混凝土：知识是分散的，静态组件越多，改变拓扑结构的工作量就越大。我们需要的是一种介于客户端和服务端之间的东西，能够集中管理所有拓扑知识。理想情况下，我们应该能够随时添加或移除服务或客户端，而无需触及拓扑结构的其他部分。

So we’ll write a little message queuing broker that gives us this flexibility. The broker binds to two endpoints, a frontend for clients and a backend for services. It then uses zmq_poll() to monitor these two sockets for activity and when it has some, it shuttles messages between its two sockets. It doesn’t actually manage any queues explicitly–ZeroMQ does that automatically on each socket.
所以我们将编写一个小型消息队列代理，为我们提供这种灵活性。代理绑定到两个端点，一个用于客户端的前端，另一个用于服务的后端。然后它使用 zmq_poll() 来监控这两个套接字的活动，当有活动时，它在两个套接字之间传递消息。它实际上并不显式管理任何队列——ZeroMQ 会自动在每个套接字上处理这些队列。

When you use REQ to talk to REP, you get a strictly synchronous request-reply dialog. The client sends a request. The service reads the request and sends a reply. The client then reads the reply. If either the client or the service try to do anything else (e.g., sending two requests in a row without waiting for a response), they will get an error.
当你使用 REQ 与 REP 通信时，会得到一个严格同步的请求-响应对话。客户端发送请求，服务端读取请求并发送响应。然后客户端读取响应。如果客户端或服务端尝试执行其他操作（例如，连续发送两个请求而不等待响应），将会收到错误。

But our broker has to be nonblocking. Obviously, we can use zmq_poll() to wait for activity on either socket, but we can’t use REP and REQ.
但我们的代理必须是非阻塞的。显然，我们可以使用 zmq_poll() 来等待任一套接字上的活动，但我们不能使用 REP 和 REQ。

Figure 16 - Extended Request-Reply
图 16 - 扩展请求-响应

Luckily, there are two sockets called DEALER and ROUTER that let you do nonblocking request-response. You’ll see in Chapter 3 - Advanced Request-Reply Patterns how DEALER and ROUTER sockets let you build all kinds of asynchronous request-reply flows. For now, we’re just going to see how DEALER and ROUTER let us extend REQ-REP across an intermediary, that is, our little broker.
幸运的是，有两种名为 DEALER 和 ROUTER 的套接字可以让你实现非阻塞的请求-响应。你将在第 3 章——高级请求-响应模式中看到 DEALER 和 ROUTER 套接字如何让你构建各种异步请求-响应流程。现在，我们只会了解 DEALER 和 ROUTER 如何让我们将 REQ-REP 扩展到中间件，也就是我们的小型代理。

In this simple extended request-reply pattern, REQ talks to ROUTER and DEALER talks to REP. In between the DEALER and ROUTER, we have to have code (like our broker) that pulls messages off the one socket and shoves them onto the other.
在这个简单的扩展请求-响应模式中，REQ 与 ROUTER 通信，DEALER 与 REP 通信。在 DEALER 和 ROUTER 之间，我们必须有代码（如我们的代理）将消息从一个套接字拉取并推送到另一个套接字。

The request-reply broker binds to two endpoints, one for clients to connect to (the frontend socket) and one for workers to connect to (the backend). To test this broker, you will want to change your workers so they connect to the backend socket. Here is a client that shows what I mean:
请求-响应代理绑定到两个端点，一个供客户端连接（前端套接字），一个供工作线程连接（后端套接字）。要测试此代理，您需要更改工作线程，使其连接到后端套接字。下面是一个展示我意思的客户端示例：

rrclient: Request-reply client in C++
rrclient：C++ 中的请求-应答客户端

//   Request-reply client in C++
//   Connects REQ socket to tcp://localhost:5559
//   Sends "Hello" to server, expects "World" back
//

#include "zhelpers.hpp"
 
int main (int argc, char *argv[])
{
    zmq::context_t context(1);

	zmq::socket_t requester(context, ZMQ_REQ);
	requester.connect("tcp://localhost:5559");
 
	for( int request = 0 ; request < 10 ; request++) {
		
		s_send (requester, std::string("Hello"));
        std::string string = s_recv (requester);
		
		std::cout << "Received reply " << request 
				<< " [" << string << "]" << std::endl;
	}
}

Here is the worker:
这是工作线程：

rrworker: Request-reply worker in C++
rrworker：C++ 中的请求-应答工作线程

//
//   Request-reply service in C++
//   Connects REP socket to tcp://localhost:5560
//   Expects "Hello" from client, replies with "World"
//


#include <zmq.hpp>
#include <chrono>
#include <thread>

int main(int argc, char* argv[])
{
    zmq::context_t context{1};

    zmq::socket_t responder{context, zmq::socket_type::rep};
    responder.connect("tcp://localhost:5560");

    while (true) {
        //  Wait for next request from client
        zmq::message_t request_msg;
        auto recv_result = responder.recv(request_msg, zmq::recv_flags::none);
        std::string string = request_msg.to_string();

        std::cout << "Received request: " << string << std::endl;

        // Do some 'work'
        std::this_thread::sleep_for(std::chrono::seconds(1));

        //  Send reply back to client
        zmq::message_t reply_msg{std::string{"World"}};
        responder.send(reply_msg, zmq::send_flags::none);

    }
}

And here is the broker, which properly handles multipart messages:
这是代理，能够正确处理多部分消息：

rrbroker: Request-reply broker in C++
rrbroker：C++中的请求-响应代理

//
//  Simple request-reply broker in C++
//

#include "zhelpers.hpp"


int main (int argc, char *argv[])
{
    //  Prepare our context and sockets
    zmq::context_t context(1);
    zmq::socket_t frontend (context, ZMQ_ROUTER);
    zmq::socket_t backend (context, ZMQ_DEALER);

    frontend.bind("tcp://*:5559");
    backend.bind("tcp://*:5560");

    //  Initialize poll set
    zmq::pollitem_t items [] = {
        { frontend, 0, ZMQ_POLLIN, 0 },
        { backend, 0, ZMQ_POLLIN, 0 }
    };
    
    //  Switch messages between sockets
    while (1) {
        zmq::message_t message;
        int more;               //  Multipart detection

        zmq::poll (&items [0], 2, -1);
        
        if (items [0].revents & ZMQ_POLLIN) {
            while (1) {
                //  Process all parts of the message
                frontend.recv(&message);
                // frontend.recv(message, zmq::recv_flags::none); // new syntax
                size_t more_size = sizeof (more);
                frontend.getsockopt(ZMQ_RCVMORE, &more, &more_size);
                backend.send(message, more? ZMQ_SNDMORE: 0);
                // more = frontend.get(zmq::sockopt::rcvmore); // new syntax
                // backend.send(message, more? zmq::send_flags::sndmore : zmq::send_flags::none);
                
                if (!more)
                    break;      //  Last message part
            }
        }
        if (items [1].revents & ZMQ_POLLIN) {
            while (1) {
                //  Process all parts of the message
                backend.recv(&message);
                size_t more_size = sizeof (more);
                backend.getsockopt(ZMQ_RCVMORE, &more, &more_size);
                frontend.send(message, more? ZMQ_SNDMORE: 0);
                // more = backend.get(zmq::sockopt::rcvmore); // new syntax
                //frontend.send(message, more? zmq::send_flags::sndmore : zmq::send_flags::none);

                if (!more)
                    break;      //  Last message part
            }
        }
    }
    return 0;
}

Figure 17 - Request-Reply Broker
图 17 - 请求-响应代理

Using a request-reply broker makes your client/server architectures easier to scale because clients don’t see workers, and workers don’t see clients. The only static node is the broker in the middle.
使用请求-响应代理使您的客户端/服务器架构更易于扩展，因为客户端看不到工作者，工作者也看不到客户端。唯一的静态节点是中间的代理。

You may wonder how a response is routed back to the right client. Router uses envelop for the message that has info on the client to the dealer and dealer response will include envelope that will be used to map the response back to the client.
你可能会想知道响应是如何路由回正确的客户端的。Router 使用信封（envelope）来携带包含客户端信息的消息发送给 Dealer，Dealer 的响应也会包含信封，这个信封将用于将响应映射回客户端。

ZeroMQ’s Built-In Proxy Function
ZeroMQ 内置代理功能#

It turns out that the core loop in the previous section’s rrbroker is very useful, and reusable. It lets us build pub-sub forwarders and shared queues and other little intermediaries with very little effort. ZeroMQ wraps this up in a single method, zmq_proxy():
事实证明，上一节中 rrbroker 的核心循环非常有用且可重用。它让我们能够轻松构建发布-订阅转发器、共享队列以及其他小型中间件。ZeroMQ 将其封装在一个名为 zmq_proxy() 的方法中：


zmq_proxy (frontend, backend, capture);

The two (or three sockets, if we want to capture data) must be properly connected, bound, and configured. When we call the zmq_proxy method, it’s exactly like starting the main loop of rrbroker. Let’s rewrite the request-reply broker to call zmq_proxy, and re-badge this as an expensive-sounding “message queue” (people have charged houses for code that did less):
这两个（或者如果我们想捕获数据则是三个）套接字必须正确连接、绑定和配置。当我们调用 zmq_proxy 方法时，就像启动 rrbroker 的主循环一样。让我们重写请求-响应代理以调用 zmq_proxy ，并将其重新标记为听起来很昂贵的“消息队列”（有人为功能更少的代码收取了高价）：

msgqueue: Message queue broker in C++
msgqueue：C++中的消息队列代理

//
//  Simple message queuing broker in C++
//  Same as request-reply broker but using QUEUE device
//

#include "zhelpers.hpp"

int main (int argc, char *argv[])
{
    zmq::context_t context(1);

    //  Socket facing clients
    zmq::socket_t frontend (context, ZMQ_ROUTER);
    frontend.bind("tcp://*:5559");

    //  Socket facing services
    zmq::socket_t backend (context, ZMQ_DEALER);
    backend.bind("tcp://*:5560");

    //  Start the proxy
    zmq::proxy(static_cast<void*>(frontend),
               static_cast<void*>(backend),
               nullptr);
    return 0;
}

If you’re like most ZeroMQ users, at this stage your mind is starting to think, “What kind of evil stuff can I do if I plug random socket types into the proxy?” The short answer is: try it and work out what is happening. In practice, you would usually stick to ROUTER/DEALER, XSUB/XPUB, or PULL/PUSH.
如果你和大多数 ZeroMQ 用户一样，这个阶段你的脑海中可能会开始思考：“如果我把随机的套接字类型插入代理，会发生什么邪恶的事情？”简短的回答是：试试看，弄清楚发生了什么。实际上，你通常会坚持使用 ROUTER/DEALER、XSUB/XPUB 或 PULL/PUSH。

Transport Bridging 传输桥接#

A frequent request from ZeroMQ users is, “How do I connect my ZeroMQ network with technology X?” where X is some other networking or messaging technology.
ZeroMQ 用户经常提出的一个请求是：“我如何将我的 ZeroMQ 网络与技术 X 连接？”其中 X 是其他某种网络或消息传递技术。

Figure 18 - Pub-Sub Forwarder Proxy
图 18 - 发布-订阅转发代理

The simple answer is to build a bridge. A bridge is a small application that speaks one protocol at one socket, and converts to/from a second protocol at another socket. A protocol interpreter, if you like. A common bridging problem in ZeroMQ is to bridge two transports or networks.
简单的答案是构建一个桥接程序。桥接程序是一个小型应用程序，在一个套接字上使用一种协议通信，并在另一个套接字上转换为另一种协议。可以把它看作是协议解释器。ZeroMQ 中一个常见的桥接问题是桥接两种传输或网络。

As an example, we’re going to write a little proxy that sits in between a publisher and a set of subscribers, bridging two networks. The frontend socket (SUB) faces the internal network where the weather server is sitting, and the backend (PUB) faces subscribers on the external network. It subscribes to the weather service on the frontend socket, and republishes its data on the backend socket.
作为示例，我们将编写一个小型代理，位于发布者和一组订阅者之间，桥接两个网络。前端套接字（SUB）面向内部网络，天气服务器就在该网络中，后端套接字（PUB）面向外部网络的订阅者。它在前端套接字上订阅天气服务，并在后端套接字上重新发布其数据。

wuproxy: Weather update proxy in C++
wuproxy：用 C++编写的天气更新代理

//
//  Weather proxy device C++
//

#include "zhelpers.hpp"

int main (int argc, char *argv[])
{
    zmq::context_t context(1);

    //  This is where the weather server sits
    zmq::socket_t frontend(context, ZMQ_SUB);
    frontend.connect("tcp://192.168.55.210:5556");

    //  This is our public endpoint for subscribers
    zmq::socket_t backend (context, ZMQ_PUB);
    backend.bind("tcp://10.1.1.0:8100");

    //  Subscribe on everything
    frontend.set(zmq::sockopt::subscribe, "");

    //  Shunt messages out to our own subscribers
    while (1) {
        while (1) {
            zmq::message_t message;
            int more;
            size_t more_size = sizeof (more);

            //  Process all parts of the message
            frontend.recv(&message);
            frontend.getsockopt( ZMQ_RCVMORE, &more, &more_size);
            backend.send(message, more? ZMQ_SNDMORE: 0);
            if (!more)
                break;      //  Last message part
        }
    }
    return 0;
}

It looks very similar to the earlier proxy example, but the key part is that the frontend and backend sockets are on two different networks. We can use this model for example to connect a multicast network (pgm transport) to a tcp publisher.
它看起来与之前的代理示例非常相似，但关键部分是前端和后端套接字位于两个不同的网络上。我们可以使用此模型，例如将多播网络（ pgm 传输）连接到 tcp 发布者。

Handling Errors and ETERM
处理错误和 ETERM#

ZeroMQ’s error handling philosophy is a mix of fail-fast and resilience. Processes, we believe, should be as vulnerable as possible to internal errors, and as robust as possible against external attacks and errors. To give an analogy, a living cell will self-destruct if it detects a single internal error, yet it will resist attack from the outside by all means possible.
ZeroMQ 的错误处理理念是快速失败与弹性的结合。我们认为，进程应尽可能对内部错误保持脆弱，同时对外部攻击和错误保持尽可能的强健。打个比方，活细胞如果检测到单一的内部错误会自我毁灭，但它会尽一切可能抵抗外部攻击。

Assertions, which pepper the ZeroMQ code, are absolutely vital to robust code; they just have to be on the right side of the cellular wall. And there should be such a wall. If it is unclear whether a fault is internal or external, that is a design flaw to be fixed. In C/C++, assertions stop the application immediately with an error. In other languages, you may get exceptions or halts.
断言在 ZeroMQ 代码中随处可见，对健壮代码至关重要；它们必须位于细胞壁的正确一侧。而且必须有这样一道墙。如果无法明确故障是内部还是外部的，那就是设计缺陷，需要修正。在 C/C++ 中，断言会立即以错误停止应用程序。在其他语言中，可能会抛出异常或停止执行。

When ZeroMQ detects an external fault it returns an error to the calling code. In some rare cases, it drops messages silently if there is no obvious strategy for recovering from the error.
当 ZeroMQ 检测到外部故障时，会向调用代码返回错误。在某些罕见情况下，如果没有明显的错误恢复策略，它会静默丢弃消息。

In most of the C examples we’ve seen so far there’s been no error handling. Real code should do error handling on every single ZeroMQ call. If you’re using a language binding other than C, the binding may handle errors for you. In C, you do need to do this yourself. There are some simple rules, starting with POSIX conventions:
到目前为止，我们看到的大多数 C 语言示例中都没有错误处理。实际代码应对每一个 ZeroMQ 调用进行错误处理。如果你使用的是除 C 以外的语言绑定，绑定可能会为你处理错误。在 C 语言中，你需要自己处理错误。有一些简单的规则，首先遵循 POSIX 约定：

Methods that create objects return NULL if they fail.
创建对象的方法在失败时返回 NULL。
Methods that process data may return the number of bytes processed, or -1 on an error or failure.
处理数据的方法可能返回处理的字节数，或者在错误或失败时返回 -1。
Other methods return 0 on success and -1 on an error or failure.
其他方法在成功时返回 0，错误或失败时返回 -1。
The error code is provided in errno or zmq_errno().
错误代码由 errno 或 zmq_errno() 提供。
A descriptive error text for logging is provided by zmq_strerror().
用于日志记录的描述性错误文本由 zmq_strerror() 提供。

For example: 例如：


void *context = zmq_ctx_new ();
assert (context);
void *socket = zmq_socket (context, ZMQ_REP);
assert (socket);
int rc = zmq_bind (socket, "tcp://*:5555");
if (rc == -1) {
    printf ("E: bind failed: %s\n", strerror (errno));
    return -1;
}

There are two main exceptional conditions that you should handle as nonfatal:
有两种主要的异常情况应作为非致命错误处理：

When your code receives a message with the ZMQ_DONTWAIT option and there is no waiting data, ZeroMQ will return -1 and set errno to EAGAIN.
当您的代码使用 ZMQ_DONTWAIT 选项接收消息且没有等待数据时，ZeroMQ 将返回 -1 并将 errno 设置为 EAGAIN 。
When one thread calls zmq_ctx_destroy(), and other threads are still doing blocking work, the zmq_ctx_destroy() call closes the context and all blocking calls exit with -1, and errno set to ETERM.
当一个线程调用 zmq_ctx_destroy() ，而其他线程仍在进行阻塞操作时， zmq_ctx_destroy() 调用会关闭上下文，所有阻塞调用以 -1 退出，并且 errno 被设置为 ETERM 。

In C/C++, asserts can be removed entirely in optimized code, so don’t make the mistake of wrapping the whole ZeroMQ call in an assert(). It looks neat; then the optimizer removes all the asserts and the calls you want to make, and your application breaks in impressive ways.
在 C/C++ 中，断言在优化代码中可以被完全移除，所以不要犯将整个 ZeroMQ 调用包裹在 assert() 中的错误。看起来很整洁；但优化器会移除所有断言和你想要执行的调用，导致你的应用程序以令人印象深刻的方式崩溃。

Figure 19 - Parallel Pipeline with Kill Signaling
图 19 - 带终止信号的并行流水线

Let’s see how to shut down a process cleanly. We’ll take the parallel pipeline example from the previous section. If we’ve started a whole lot of workers in the background, we now want to kill them when the batch is finished. Let’s do this by sending a kill message to the workers. The best place to do this is the sink because it really knows when the batch is done.
让我们看看如何干净地关闭一个进程。我们将使用上一节的并行流水线示例。如果我们在后台启动了大量的工作线程，现在想在批处理完成时终止它们。我们通过向工作线程发送一个终止消息来实现这一点。最合适的地方是 sink，因为它真正知道批处理何时完成。

How do we connect the sink to the workers? The PUSH/PULL sockets are one-way only. We could switch to another socket type, or we could mix multiple socket flows. Let’s try the latter: using a pub-sub model to send kill messages to the workers:
我们如何将汇聚器连接到工作线程？PUSH/PULL 套接字是单向的。我们可以切换到另一种套接字类型，或者混合使用多种套接字流。让我们尝试后者：使用发布-订阅模型向工作线程发送终止消息：

The sink creates a PUB socket on a new endpoint.
汇聚端在一个新的端点上创建一个 PUB 套接字。
Workers connect their input socket to this endpoint.
工作线程将它们的输入套接字连接到此端点。
When the sink detects the end of the batch, it sends a kill to its PUB socket.
当汇聚端检测到批处理结束时，它会向其 PUB 套接字发送一个终止信号。
When a worker detects this kill message, it exits.
当工作线程检测到此终止消息时，它会退出。

It doesn’t take much new code in the sink:
汇聚端不需要太多新代码：


void *controller = zmq_socket (context, ZMQ_PUB);
zmq_bind (controller, "tcp://*:5559");
...
//  Send kill signal to workers
s_send (controller, "KILL");

Here is the worker process, which manages two sockets (a PULL socket getting tasks, and a SUB socket getting control commands), using the zmq_poll() technique we saw earlier:
这是工作进程，它管理两个套接字（一个用于接收任务的 PULL 套接字和一个用于接收控制命令的 SUB 套接字），使用了我们之前看到的 zmq_poll() 技术：

taskwork2: Parallel task worker with kill signaling in C++
taskwork2：带有终止信号的并行任务工作者（C++）

//
//  Task worker in C++ - design 2
//  Adds pub-sub flow to receive and respond to kill signal
//

#include "zhelpers.hpp"
#include <string>

int main (int argc, char *argv[])
{
    zmq::context_t context(1);
    
    //  Socket to receive messages on
    zmq::socket_t receiver(context, ZMQ_PULL);
    receiver.connect("tcp://localhost:5557");

    //  Socket to send messages to
    zmq::socket_t sender(context, ZMQ_PUSH);
    sender.connect("tcp://localhost:5558");

    //  Socket for control input
    zmq::socket_t controller (context, ZMQ_SUB);
    controller.connect("tcp://localhost:5559");
    controller.set(zmq::sockopt::subscribe, "");

    //  Process messages from receiver and controller
    zmq::pollitem_t items [] = {
        { receiver, 0, ZMQ_POLLIN, 0 },
        { controller, 0, ZMQ_POLLIN, 0 }
    };
    //  Process messages from both sockets
    while (1) {
        zmq::message_t message;
        zmq::poll (&items [0], 2, -1);
        
        if (items [0].revents & ZMQ_POLLIN) {
            receiver.recv(&message);

            //  Process task
            int workload;           //  Workload in msecs
           
            std::string sdata(static_cast<char*>(message.data()), message.size());
            std::istringstream iss(sdata);
            iss >> workload;

            //  Do the work
            s_sleep(workload);

            //  Send results to sink
            message.rebuild();
            sender.send(message);

            //  Simple progress indicator for the viewer
            std::cout << "." << std::flush;

        }
        //  Any waiting controller command acts as 'KILL'
        if (items [1].revents & ZMQ_POLLIN) {
        	std::cout << std::endl;
            break;                      //  Exit loop
        }
    }
    //  Finished
    return 0;
}

Here is the modified sink application. When it’s finished collecting results, it broadcasts a kill message to all workers:
这是修改后的 sink 应用程序。当它完成收集结果后，会向所有工作线程广播一个终止消息：

tasksink2: Parallel task sink with kill signaling in C++
tasksink2：带有终止信号的并行任务接收器（C++）

//
//  Task sink in C++ - design 2
//  Adds pub-sub flow to send kill signal to workers
//

#include "zhelpers.hpp"

int main (int argc, char *argv[])
{
    zmq::context_t context(1);

    //  Socket to receive messages on
    zmq::socket_t receiver (context, ZMQ_PULL);
    receiver.bind("tcp://*:5558");

    //  Socket for worker control
    zmq::socket_t controller (context, ZMQ_PUB);
    controller.bind("tcp://*:5559");

    //  Wait for start of batch
    s_recv (receiver);

    //  Start our clock now
    struct timeval tstart;
    gettimeofday (&tstart, NULL);

    //  Process 100 confirmations
    int task_nbr;
    for (task_nbr = 0; task_nbr < 100; task_nbr++) {
        s_recv (receiver);

        if (task_nbr % 10 == 0)
            std::cout << ":" ;
        else
            std::cout << "." ;
    }
    //  Calculate and report duration of batch
    struct timeval tend, tdiff;
    gettimeofday (&tend, NULL);

    if (tend.tv_usec < tstart.tv_usec) {
        tdiff.tv_sec = tend.tv_sec - tstart.tv_sec - 1;
        tdiff.tv_usec = 1000000 + tend.tv_usec - tstart.tv_usec;
    }
    else {
        tdiff.tv_sec = tend.tv_sec - tstart.tv_sec;
        tdiff.tv_usec = tend.tv_usec - tstart.tv_usec;
    }
    int total_msec = tdiff.tv_sec * 1000 + tdiff.tv_usec / 1000;
    std::cout << "\nTotal elapsed time: " << total_msec 
            << " msec\n" << std::endl;

    //  Send kill signal to workers
    s_send (controller, std::string("KILL"));

    //  Finished
    sleep (1);              //  Give 0MQ time to deliver
    return 0;
}

Handling Interrupt Signals
处理中断信号#

Realistic applications need to shut down cleanly when interrupted with Ctrl-C or another signal such as SIGTERM. By default, these simply kill the process, meaning messages won’t be flushed, files won’t be closed cleanly, and so on.
实际应用需要在按下 Ctrl-C 或其他信号（如 SIGTERM ）中断时能够干净地关闭。默认情况下，这些信号会直接终止进程，导致消息无法刷新，文件无法正常关闭，等等。

Here is how we handle a signal in various languages:
以下是在各种语言中处理信号的方法：

interrupt: Handling Ctrl-C cleanly in C++
interrupt：在 C++ 中优雅处理 Ctrl-C

//  Handling Interrupt Signals in C++
//
//  Saad Hussain <saadnasir31@gmail.com>

#include <csignal>
#include <iostream>
#include <zmq.hpp>

int interrupted{0};

void signal_handler(int signal_value) { interrupted = 1; }

void catch_signals() {
  std::signal(SIGINT, signal_handler);
  std::signal(SIGTERM, signal_handler);
  std::signal(SIGSEGV, signal_handler);
  std::signal(SIGABRT, signal_handler);
}

int main() {
  zmq::context_t ctx(1);

  zmq::socket_t socket(ctx, ZMQ_REP);
  socket.bind("tcp://localhost:5555");

  catch_signals();
  while (true) {
    zmq::message_t msg;

    try {
      socket.recv(&msg);
    } catch (zmq::error_t &e) {
      std::cout << "interrupt received, proceeding..." << std::endl;
    }

    if (interrupted) {
      std::cout << "interrupt received, killing program..." << std::endl;
      break;
    }
  }
  return 0;
}

The program provides s_catch_signals(), which traps Ctrl-C (SIGINT) and SIGTERM. When either of these signals arrive, the s_catch_signals() handler sets the global variable s_interrupted. Thanks to your signal handler, your application will not die automatically. Instead, you have a chance to clean up and exit gracefully. You have to now explicitly check for an interrupt and handle it properly. Do this by calling s_catch_signals() (copy this from interrupt.c) at the start of your main code. This sets up the signal handling. The interrupt will affect ZeroMQ calls as follows:
该程序提供了 s_catch_signals() ，用于捕获 Ctrl-C（ SIGINT ）和 SIGTERM 。当任一信号到达时， s_catch_signals() 处理程序会设置全局变量 s_interrupted 。多亏了您的信号处理程序，您的应用程序不会自动终止。相反，您有机会进行清理并优雅地退出。您现在必须显式检查中断并正确处理它。通过在主代码开始处调用 s_catch_signals() （从 interrupt.c 复制）来实现。这会设置信号处理。中断将对 ZeroMQ 调用产生以下影响：

If your code is blocking in a blocking call (sending a message, receiving a message, or polling), then when a signal arrives, the call will return with EINTR.
如果您的代码在阻塞调用（发送消息、接收消息或轮询）中阻塞，那么当信号到达时，该调用将返回 EINTR 。
Wrappers like s_recv() return NULL if they are interrupted.
像 s_recv() 这样的封装在被中断时会返回 NULL。

So check for an EINTR return code, a NULL return, and/or s_interrupted.
所以检查返回码是否为 EINTR ，返回值是否为 NULL，和/或是否为 s_interrupted 。

Here is a typical code fragment:
下面是一个典型的代码片段：

s_catch_signals ();
client = zmq_socket (...);
while (!s_interrupted) {
    char *message = s_recv (client);
    if (!message)
        break;          //  Ctrl-C used
}
zmq_close (client);

If you call s_catch_signals() and don’t test for interrupts, then your application will become immune to Ctrl-C and SIGTERM, which may be useful, but is usually not.
如果调用 s_catch_signals() 而不检测中断，那么您的应用程序将对 Ctrl-C 和 SIGTERM 免疫，这可能有用，但通常不是。

Detecting Memory Leaks
检测内存泄漏#

Any long-running application has to manage memory correctly, or eventually it’ll use up all available memory and crash. If you use a language that handles this automatically for you, congratulations. If you program in C or C++ or any other language where you’re responsible for memory management, here’s a short tutorial on using valgrind, which among other things will report on any leaks your programs have.
任何长时间运行的应用程序都必须正确管理内存，否则最终会耗尽所有可用内存并崩溃。如果你使用的语言能自动处理内存管理，恭喜你。如果你使用 C、C++ 或任何其他需要自己负责内存管理的语言编程，这里有一个关于使用 valgrind 的简短教程，valgrind 可以报告程序中的内存泄漏等问题。

To install valgrind, e.g., on Ubuntu or Debian, issue this command:
要在 Ubuntu 或 Debian 上安装 valgrind，请执行以下命令：

sudo apt-get install valgrind

By default, ZeroMQ will cause valgrind to complain a lot. To remove these warnings, create a file called vg.supp that contains this:
默认情况下，ZeroMQ 会导致 valgrind 报告大量警告。要消除这些警告，请创建一个名为 vg.supp 的文件，内容如下：

{
   <socketcall_sendto>
   Memcheck:Param
   socketcall.sendto(msg)
   fun:send
   ...
}
{
   <socketcall_sendto>
   Memcheck:Param
   socketcall.send(msg)
   fun:send
   ...
}

Fix your applications to exit cleanly after Ctrl-C. For any application that exits by itself, that’s not needed, but for long-running applications, this is essential, otherwise valgrind will complain about all currently allocated memory.
修正您的应用程序，使其在按下 Ctrl-C 后能够干净地退出。对于任何自动退出的应用程序，这不是必需的，但对于长时间运行的应用程序来说，这是必不可少的，否则 valgrind 会抱怨所有当前分配的内存。
Build your application with -DDEBUG if it’s not your default setting. That ensures valgrind can tell you exactly where memory is being leaked.
如果这不是您的默认设置，请使用 -DDEBUG 构建您的应用程序。这样可以确保 valgrind 精确地告诉您内存泄漏的位置。
Finally, run valgrind thus:
最后，按如下方式运行 valgrind：

valgrind --tool=memcheck --leak-check=full --suppressions=vg.supp someprog

And after fixing any errors it reported, you should get the pleasant message:
修复它报告的任何错误后，你应该会看到如下愉快的消息：

==30536== ERROR SUMMARY: 0 errors from 0 contexts...

Multithreading with ZeroMQ
ZeroMQ 多线程编程#

ZeroMQ is perhaps the nicest way ever to write multithreaded (MT) applications. Whereas ZeroMQ sockets require some readjustment if you are used to traditional sockets, ZeroMQ multithreading will take everything you know about writing MT applications, throw it into a heap in the garden, pour gasoline over it, and set it alight. It’s a rare book that deserves burning, but most books on concurrent programming do.
ZeroMQ 可能是迄今为止编写多线程（MT）应用程序最优雅的方式。虽然如果你习惯了传统套接字，ZeroMQ 套接字需要一些调整，但 ZeroMQ 的多线程会将你对编写多线程应用程序的所有认知，统统扔进花园里的堆里，浇上汽油，然后点燃。很少有书值得焚烧，但大多数关于并发编程的书都值得。

To make utterly perfect MT programs (and I mean that literally), we don’t need mutexes, locks, or any other form of inter-thread communication except messages sent across ZeroMQ sockets.
为了编写绝对完美的多线程程序（我是字面意思），我们不需要互斥锁、锁机制或任何其他形式的线程间通信，唯一需要的就是通过 ZeroMQ 套接字发送的消息。

By “perfect MT programs”, I mean code that’s easy to write and understand, that works with the same design approach in any programming language, and on any operating system, and that scales across any number of CPUs with zero wait states and no point of diminishing returns.
所谓“完美的多线程程序”，是指那些易于编写和理解的代码，能够在任何编程语言和操作系统中采用相同的设计方法运行，并且能够在任意数量的 CPU 上扩展，且无等待状态且不存在收益递减点。

If you’ve spent years learning tricks to make your MT code work at all, let alone rapidly, with locks and semaphores and critical sections, you will be disgusted when you realize it was all for nothing. If there’s one lesson we’ve learned from 30+ years of concurrent programming, it is: just don’t share state. It’s like two drunkards trying to share a beer. It doesn’t matter if they’re good buddies. Sooner or later, they’re going to get into a fight. And the more drunkards you add to the table, the more they fight each other over the beer. The tragic majority of MT applications look like drunken bar fights.
如果你花了多年时间学习各种技巧，让你的多线程代码能够运行，甚至运行得很快，使用锁、信号量和临界区，那么当你意识到这一切都是徒劳时，你会感到非常失望。我们从 30 多年的并发编程中学到的一个教训是：千万不要共享状态。这就像两个醉汉试图共享一瓶啤酒。无论他们多么要好，迟早都会吵架。而且你桌上醉汉越多，他们为了那瓶啤酒争吵得越激烈。绝大多数多线程应用看起来就像醉酒的酒吧斗殴。

The list of weird problems that you need to fight as you write classic shared-state MT code would be hilarious if it didn’t translate directly into stress and risk, as code that seems to work suddenly fails under pressure. A large firm with world-beating experience in buggy code released its list of “11 Likely Problems In Your Multithreaded Code”, which covers forgotten synchronization, incorrect granularity, read and write tearing, lock-free reordering, lock convoys, two-step dance, and priority inversion.
当你编写经典的共享状态多线程代码时，需要应对的一系列奇怪问题本来会让人发笑，但由于这些问题直接转化为压力和风险——看似正常工作的代码在压力下突然失败——情况就不那么好笑了。一家在处理有缺陷代码方面拥有世界领先经验的大公司发布了他们的“多线程代码中 11 个可能出现的问题”清单，涵盖了忘记同步、粒度不正确、读写撕裂、无锁重排序、锁队列、两步舞以及优先级反转等问题。

Yeah, we counted seven problems, not eleven. That’s not the point though. The point is, do you really want that code running the power grid or stock market to start getting two-step lock convoys at 3 p.m. on a busy Thursday? Who cares what the terms actually mean? This is not what turned us on to programming, fighting ever more complex side effects with ever more complex hacks.
是的，我们数了七个问题，不是十一。重点不是这个。重点是，你真的希望那些控制电网或股市的代码，在一个繁忙的星期四下午三点开始出现两步锁定连锁反应吗？谁在乎这些术语实际上是什么意思？这并不是我们热衷于编程的原因，我们并不是为了用越来越复杂的黑客手段来对抗越来越复杂的副作用。

Some widely used models, despite being the basis for entire industries, are fundamentally broken, and shared state concurrency is one of them. Code that wants to scale without limit does it like the Internet does, by sending messages and sharing nothing except a common contempt for broken programming models.
一些被广泛使用的模型，尽管是整个行业的基础，实际上是根本有缺陷的，共享状态并发就是其中之一。想要无限扩展的代码，就像互联网那样，通过发送消息来实现，除了对破碎编程模型的共同蔑视外，不共享任何东西。

You should follow some rules to write happy multithreaded code with ZeroMQ:
编写使用 ZeroMQ 的高效多线程代码时，应遵循以下规则：

Isolate data privately within its thread and never share data in multiple threads. The only exception to this are ZeroMQ contexts, which are threadsafe.
在其线程内私有隔离数据，绝不在多个线程间共享数据。唯一的例外是 ZeroMQ 上下文，它们是线程安全的。
Stay away from the classic concurrency mechanisms like as mutexes, critical sections, semaphores, etc. These are an anti-pattern in ZeroMQ applications.
远离经典的并发机制，如互斥锁、临界区、信号量等。这些在 ZeroMQ 应用中是反模式。
Create one ZeroMQ context at the start of your process, and pass that to all threads that you want to connect via inproc sockets.
在进程开始时创建一个 ZeroMQ 上下文，并将其传递给所有希望通过 inproc 套接字连接的线程。
Use attached threads to create structure within your application, and connect these to their parent threads using PAIR sockets over inproc. The pattern is: bind parent socket, then create child thread which connects its socket.
使用附属线程在应用程序内创建结构，并使用 PAIR 套接字通过 inproc 将它们连接到其父线程。模式是：绑定父套接字，然后创建连接其套接字的子线程。
Use detached threads to simulate independent tasks, with their own contexts. Connect these over tcp. Later you can move these to stand-alone processes without changing the code significantly.
使用分离线程模拟独立任务，拥有自己的上下文。通过 tcp 连接它们。以后你可以将这些线程迁移到独立进程，而无需显著更改代码。
All interaction between threads happens as ZeroMQ messages, which you can define more or less formally.
线程之间的所有交互都以 ZeroMQ 消息的形式进行，您可以更正式或更随意地定义这些消息。
Don’t share ZeroMQ sockets between threads. ZeroMQ sockets are not threadsafe. Technically it’s possible to migrate a socket from one thread to another but it demands skill. The only place where it’s remotely sane to share sockets between threads are in language bindings that need to do magic like garbage collection on sockets.
不要在多个线程之间共享 ZeroMQ 套接字。ZeroMQ 套接字不是线程安全的。从技术上讲，可以将套接字从一个线程迁移到另一个线程，但这需要一定的技巧。唯一可能在多个线程之间共享套接字的合理场景是那些需要对套接字进行垃圾回收等魔法操作的语言绑定。

If you need to start more than one proxy in an application, for example, you will want to run each in their own thread. It is easy to make the error of creating the proxy frontend and backend sockets in one thread, and then passing the sockets to the proxy in another thread. This may appear to work at first but will fail randomly in real use. Remember: Do not use or close sockets except in the thread that created them.
如果你需要在一个应用程序中启动多个代理，例如，你会希望让每个代理运行在自己的线程中。很容易犯的一个错误是，在一个线程中创建代理的前端和后端套接字，然后将这些套接字传递给另一个线程中的代理。这在开始时可能看起来可行，但在实际使用中会随机失败。请记住：不要在创建套接字的线程之外使用或关闭套接字。

If you follow these rules, you can quite easily build elegant multithreaded applications, and later split off threads into separate processes as you need to. Application logic can sit in threads, processes, or nodes: whatever your scale needs.
如果遵循这些规则，你可以轻松构建优雅的多线程应用程序，之后根据需要将线程拆分为独立的进程。应用逻辑可以运行在线程、进程或节点中：完全取决于你的规模需求。

ZeroMQ uses native OS threads rather than virtual “green” threads. The advantage is that you don’t need to learn any new threading API, and that ZeroMQ threads map cleanly to your operating system. You can use standard tools like Intel’s ThreadChecker to see what your application is doing. The disadvantages are that native threading APIs are not always portable, and that if you have a huge number of threads (in the thousands), some operating systems will get stressed.
ZeroMQ 使用本地操作系统线程，而非虚拟的“绿色”线程。其优点是您无需学习任何新的线程 API，且 ZeroMQ 线程能够与操作系统一一对应。您可以使用诸如 Intel 的 ThreadChecker 等标准工具来查看应用程序的运行情况。缺点是本地线程 API 并不总是具有可移植性，且如果线程数量庞大（达到数千个），某些操作系统可能会出现压力。

Let’s see how this works in practice. We’ll turn our old Hello World server into something more capable. The original server ran in a single thread. If the work per request is low, that’s fine: one ØMQ thread can run at full speed on a CPU core, with no waits, doing an awful lot of work. But realistic servers have to do nontrivial work per request. A single core may not be enough when 10,000 clients hit the server all at once. So a realistic server will start multiple worker threads. It then accepts requests as fast as it can and distributes these to its worker threads. The worker threads grind through the work and eventually send their replies back.
让我们看看这在实际中的运作方式。我们将把旧的 Hello World 服务器改造成更强大的版本。原始服务器运行在单线程中。如果每个请求的工作量很小，那没问题：一个 ØMQ 线程可以在一个 CPU 核心上全速运行，无需等待，完成大量工作。但现实中的服务器每个请求都需要做非平凡的工作。当有 10,000 个客户端同时访问服务器时，单个核心可能不够用。因此，现实中的服务器会启动多个工作线程。它会尽可能快地接受请求，并将这些请求分发给工作线程。工作线程处理完任务后，最终将回复发送回去。

You can, of course, do all this using a proxy broker and external worker processes, but often it’s easier to start one process that gobbles up sixteen cores than sixteen processes, each gobbling up one core. Further, running workers as threads will cut out a network hop, latency, and network traffic.
当然，你也可以使用代理代理和外部工作进程来完成所有这些，但通常启动一个占用十六个核心的进程比启动十六个各占用一个核心的进程更简单。此外，将工作线程作为线程运行可以减少一次网络跳转、延迟和网络流量。

The MT version of the Hello World service basically collapses the broker and workers into a single process:
Hello World 服务的 MT 版本基本上将代理和工作线程合并到一个进程中：

mtserver: Multithreaded service in C++
mtserver：C++中的多线程服务

/*
author: Saad Hussain <saadnasir31@gmail.com>
date: 30th January 2024
*/

#include <string>
#include <iostream>
#include <thread>
#include <zmq.hpp>

void worker_routine(zmq::context_t& ctx) {
    zmq::socket_t socket(ctx, ZMQ_REP);
    socket.connect("inproc://workers");

    while(true) {
        zmq::message_t request;
        socket.recv(&request);
        std::cout << "Received request: [" << (char*) request.data() << "]" << std::endl;
        std::this_thread::sleep_for(std::chrono::seconds(1));

        zmq::message_t reply("World", 5);
        socket.send(reply);
    }
}

int main() {
    zmq::context_t ctx(1);
    zmq::socket_t clients(ctx, ZMQ_ROUTER);
    clients.bind("tcp://localhost:5555");

    zmq::socket_t workers(ctx, ZMQ_DEALER);
    workers.bind("inproc://workers");
    
    std::vector<std::thread> worker_threads;
    for (int thread_nbr = 0; thread_nbr != 5; ++thread_nbr) {
        worker_threads.emplace_back([&ctx] { worker_routine(ctx); }); 
    }

    zmq::proxy(clients, workers, nullptr);

    for (auto& thread : worker_threads) {
        thread.join();
    }
    
    return 0;

}

Figure 20 - Multithreaded Server
图 20 - 多线程服务器

All the code should be recognizable to you by now. How it works:
到现在为止，所有代码你应该都能认得。它的工作原理是：

The server starts a set of worker threads. Each worker thread creates a REP socket and then processes requests on this socket. Worker threads are just like single-threaded servers. The only differences are the transport (inproc instead of tcp), and the bind-connect direction.
服务器启动一组工作线程。每个工作线程创建一个 REP 套接字，然后在该套接字上处理请求。工作线程就像单线程服务器。唯一的区别是传输方式（ inproc 而不是 tcp ）以及绑定-连接方向。
The server creates a ROUTER socket to talk to clients and binds this to its external interface (over tcp).
服务器创建一个 ROUTER 套接字与客户端通信，并将其绑定到外部接口（通过 tcp ）。
The server creates a DEALER socket to talk to the workers and binds this to its internal interface (over inproc).
服务器创建一个 DEALER 套接字与工作线程通信，并将其绑定到内部接口（通过 inproc ）。
The server starts a proxy that connects the two sockets. The proxy pulls incoming requests fairly from all clients, and distributes those out to workers. It also routes replies back to their origin.
服务器启动一个代理，连接这两个套接字。代理公平地从所有客户端拉取传入请求，并将其分发给工作线程。同时，它还将回复路由回请求的源头。

Note that creating threads is not portable in most programming languages. The POSIX library is pthreads, but on Windows you have to use a different API. In our example, the pthread_create call starts up a new thread running the worker_routine function we defined. We’ll see in Chapter 3 - Advanced Request-Reply Patterns how to wrap this in a portable API.
请注意，在大多数编程语言中创建线程并不具备可移植性。POSIX 库是 pthreads，但在 Windows 上必须使用不同的 API。在我们的示例中， pthread_create 调用启动了一个运行我们定义的 worker_routine 函数的新线程。我们将在第 3 章 - 高级请求-响应模式中看到如何将其封装在一个可移植的 API 中。

Here the “work” is just a one-second pause. We could do anything in the workers, including talking to other nodes. This is what the MT server looks like in terms of ØMQ sockets and nodes. Note how the request-reply chain is REQ-ROUTER-queue-DEALER-REP.
这里的“工作”只是暂停一秒钟。我们可以在工作线程中执行任何操作，包括与其他节点通信。这就是 MT 服务器在 ØMQ 套接字和节点方面的样子。请注意请求-响应链是 REQ-ROUTER-queue-DEALER-REP 。

Signaling Between Threads (PAIR Sockets)
线程间信号传递（PAIR 套接字）#

When you start making multithreaded applications with ZeroMQ, you’ll encounter the question of how to coordinate your threads. Though you might be tempted to insert “sleep” statements, or use multithreading techniques such as semaphores or mutexes, the only mechanism that you should use are ZeroMQ messages. Remember the story of The Drunkards and The Beer Bottle.
当你开始使用 ZeroMQ 编写多线程应用程序时，你会遇到如何协调线程的问题。虽然你可能会想插入“sleep”语句，或使用信号量、互斥锁等多线程技术，但你唯一应该使用的机制是 ZeroMQ 消息。记住《醉汉与啤酒瓶》的故事。

Let’s make three threads that signal each other when they are ready. In this example, we use PAIR sockets over the inproc transport:
让我们创建三个线程，当它们准备好时相互发送信号。在此示例中，我们使用基于 inproc 传输的 PAIR 套接字：

mtrelay: Multithreaded relay in C++
mtrelay：C++中的多线程接力

/*
author: Saad Hussain <saadnasir31@gmail.com>
*/

#include <iostream>
#include <thread>
#include <zmq.hpp>

void step1(zmq::context_t &context) {
  // Connect to step2 and tell it we're ready
  zmq::socket_t xmitter(context, zmq::socket_type::pair);
  xmitter.connect("inproc://step2");

  std::cout << "Step 1 ready, signaling step 2" << std::endl;

  zmq::message_t msg("READY");
  xmitter.send(msg, zmq::send_flags::none);
}

void step2(zmq::context_t &context) {
  // Bind inproc socket before starting step1
  zmq::socket_t receiver(context, zmq::socket_type::pair);
  receiver.bind("inproc://step2");

  std::thread thd(step1, std::ref(context));

  // Wait for signal and pass it on
  zmq::message_t msg;
  receiver.recv(msg, zmq::recv_flags::none);

  // Connect to step3 and tell it we're ready
  zmq::socket_t xmitter(context, zmq::socket_type::pair);
  xmitter.connect("inproc://step3");

  std::cout << "Step 2 ready, signaling step 3" << std::endl;

  xmitter.send(zmq::str_buffer("READY"), zmq::send_flags::none);
  thd.join();
}

int main() {
  zmq::context_t context(1);

  // Bind inproc socket before starting step2
  zmq::socket_t receiver(context, zmq::socket_type::pair);
  receiver.bind("inproc://step3");

  std::thread thd(step2, std::ref(context));

  // Wait for signal
  zmq::message_t msg;
  receiver.recv(msg, zmq::recv_flags::none);

  std::cout << "Test successful!" << std::endl;
  thd.join();
  return 0;
}

This is a classic pattern for multithreading with ZeroMQ:
这是使用 ZeroMQ 进行多线程的经典模式：

Two threads communicate over inproc, using a shared context.
两个线程通过 inproc 进行通信，使用共享上下文。
The parent thread creates one socket, binds it to an inproc:@<*>@ endpoint, and *then// starts the child thread, passing the context to it.
父线程创建一个套接字，将其绑定到一个 inproc:@<*>@ 端点，然后启动子线程，将上下文传递给它。
The child thread creates the second socket, connects it to that inproc:@<*>@ endpoint, and *then// signals to the parent thread that it’s ready.
子线程创建第二个套接字，连接到该 inproc:@<*>@ 端点，然后向父线程发出准备就绪的信号。

Note that multithreading code using this pattern is not scalable out to processes. If you use inproc and socket pairs, you are building a tightly-bound application, i.e., one where your threads are structurally interdependent. Do this when low latency is really vital. The other design pattern is a loosely bound application, where threads have their own context and communicate over ipc or tcp. You can easily break loosely bound threads into separate processes.
请注意，使用此模式的多线程代码无法扩展到进程。如果您使用 inproc 和套接字对，您正在构建一个紧密绑定的应用程序，即线程在结构上相互依赖的应用程序。当低延迟非常关键时，请采用此方法。另一种设计模式是松散绑定的应用程序，线程拥有自己的上下文，并通过 ipc 或 tcp 进行通信。您可以轻松地将松散绑定的线程拆分为独立的进程。

This is the first time we’ve shown an example using PAIR sockets. Why use PAIR? Other socket combinations might seem to work, but they all have side effects that could interfere with signaling:
这是我们第一次展示使用 PAIR 套接字的示例。为什么使用 PAIR？其他套接字组合看似可行，但它们都有可能干扰信号传递的副作用：

You can use PUSH for the sender and PULL for the receiver. This looks simple and will work, but remember that PUSH will distribute messages to all available receivers. If you by accident start two receivers (e.g., you already have one running and you start a second), you’ll “lose” half of your signals. PAIR has the advantage of refusing more than one connection; the pair is exclusive.
你可以使用 PUSH 作为发送端，PULL 作为接收端。这看起来简单且可行，但请记住，PUSH 会将消息分发给所有可用的接收端。如果你不小心启动了两个接收端（例如，你已经有一个在运行，然后又启动了第二个），你将“丢失”一半的信号。PAIR 的优点是拒绝多个连接；该对等连接是独占的。
You can use DEALER for the sender and ROUTER for the receiver. ROUTER, however, wraps your message in an “envelope”, meaning your zero-size signal turns into a multipart message. If you don’t care about the data and treat anything as a valid signal, and if you don’t read more than once from the socket, that won’t matter. If, however, you decide to send real data, you will suddenly find ROUTER providing you with “wrong” messages. DEALER also distributes outgoing messages, giving the same risk as PUSH.
你可以使用 DEALER 作为发送端，ROUTER 作为接收端。然而，ROUTER 会将你的消息包装在一个“信封”中，这意味着你的零长度信号会变成一个多部分消息。如果你不关心数据，并且将任何内容都视为有效信号，且不会从套接字读取多次，那这不会有影响。但如果你决定发送真实数据，你会突然发现 ROUTER 会给你提供“错误”的消息。DEALER 也会分发外发消息，存在与 PUSH 相同的风险。
You can use PUB for the sender and SUB for the receiver. This will correctly deliver your messages exactly as you sent them and PUB does not distribute as PUSH or DEALER do. However, you need to configure the subscriber with an empty subscription, which is annoying.
你可以使用 PUB 作为发送端，SUB 作为接收端。这将准确地按你发送的方式传递消息，且 PUB 不像 PUSH 或 DEALER 那样进行分发。然而，你需要为订阅者配置一个空订阅，这比较麻烦。

For these reasons, PAIR makes the best choice for coordination between pairs of threads.
基于这些原因，PAIR 是线程对之间协调的最佳选择。

Node Coordination 节点协调#

When you want to coordinate a set of nodes on a network, PAIR sockets won’t work well any more. This is one of the few areas where the strategies for threads and nodes are different. Principally, nodes come and go whereas threads are usually static. PAIR sockets do not automatically reconnect if the remote node goes away and comes back.
当你想协调网络上的一组节点时，PAIR 套接字将不再适用。这是线程和节点策略不同的少数几个领域之一。主要区别在于，节点会动态加入和离开，而线程通常是静态的。如果远程节点断开后再重新连接，PAIR 套接字不会自动重连。

Figure 22 - Pub-Sub Synchronization
图 22 - 发布-订阅同步

The second significant difference between threads and nodes is that you typically have a fixed number of threads but a more variable number of nodes. Let’s take one of our earlier scenarios (the weather server and clients) and use node coordination to ensure that subscribers don’t lose data when starting up.
线程和节点之间的第二个显著区别是，线程的数量通常是固定的，而节点的数量则更为可变。让我们以之前的一个场景（天气服务器和客户端）为例，使用节点协调来确保订阅者在启动时不会丢失数据。

This is how the application will work:
应用程序的工作流程如下：

The publisher knows in advance how many subscribers it expects. This is just a magic number it gets from somewhere.
发布者事先知道它期望有多少订阅者。这只是它从某处获得的一个魔数。
The publisher starts up and waits for all subscribers to connect. This is the node coordination part. Each subscriber subscribes and then tells the publisher it’s ready via another socket.
发布者启动并等待所有订阅者连接。这是节点协调部分。每个订阅者订阅后，通过另一个套接字告诉发布者它已准备好。
When the publisher has all subscribers connected, it starts to publish data.
当发布者所有订阅者都连接后，它开始发布数据。

In this case, we’ll use a REQ-REP socket flow to synchronize subscribers and publisher. Here is the publisher:
在这种情况下，我们将使用 REQ-REP 套接字流程来同步订阅者和发布者。以下是发布者：

syncpub: Synchronized publisher in C++
syncpub：C++中的同步发布者

//
//  Synchronized publisher in C++
//

#include "zhelpers.hpp"

//  We wait for 10 subscribers
#define SUBSCRIBERS_EXPECTED  10

int main () {
	zmq::context_t context(1);

    //  Socket to talk to clients
    zmq::socket_t publisher (context, ZMQ_PUB);

    int sndhwm = 0;
    publisher.setsockopt (ZMQ_SNDHWM, &sndhwm, sizeof (sndhwm));

    publisher.bind("tcp://*:5561");

    //  Socket to receive signals
    zmq::socket_t syncservice (context, ZMQ_REP);
    syncservice.bind("tcp://*:5562");

    //  Get synchronization from subscribers
    int subscribers = 0;
    while (subscribers < SUBSCRIBERS_EXPECTED) {
        
		//  - wait for synchronization request
		s_recv (syncservice);
       
		//  - send synchronization reply
		s_send (syncservice, std::string(""));


        subscribers++;
    }
    
    //  Now broadcast exactly 1M updates followed by END
    int update_nbr;
    for (update_nbr = 0; update_nbr < 1000000; update_nbr++) {	
		s_send (publisher, std::string("Rhubarb"));
	}
	
    s_send (publisher, std::string("END"));

    sleep (1);              //  Give 0MQ time to flush output
    return 0;
}

And here is the subscriber:
下面是订阅者：

syncsub: Synchronized subscriber in C++
syncsub：用 C++ 编写的同步订阅者

//
//  Synchronized subscriber in C++
//

#include "zhelpers.hpp"

int main (int argc, char *argv[])
{
   zmq::context_t context(1);

    //  First, connect our subscriber socket
    zmq::socket_t subscriber (context, ZMQ_SUB);
    subscriber.connect("tcp://localhost:5561");
    subscriber.set(zmq::sockopt::subscribe, "");

    //  Second, synchronize with publisher
    zmq::socket_t syncclient (context, ZMQ_REQ);
    syncclient.connect("tcp://localhost:5562");

    //  - send a synchronization request
    s_send (syncclient, std::string(""));

    //  - wait for synchronization reply
    s_recv (syncclient);

    //  Third, get our updates and report how many we got
    int update_nbr = 0;
    while (1) {

        if (s_recv (subscriber).compare("END") == 0) {
            break;
        }

        update_nbr++;
    }
    std::cout << "Received " << update_nbr << " updates" << std::endl;

    return 0;
}

This Bash shell script will start ten subscribers and then the publisher:
这个 Bash shell 脚本将启动十个订阅者，然后启动发布者：

echo "Starting subscribers..."
for ((a=0; a<10; a++)); do
    syncsub &
done
echo "Starting publisher..."
syncpub

Which gives us this satisfying output:
这给了我们这个令人满意的输出：

Starting subscribers...
Starting publisher...
Received 1000000 updates
Received 1000000 updates
...
Received 1000000 updates
Received 1000000 updates

We can’t assume that the SUB connect will be finished by the time the REQ/REP dialog is complete. There are no guarantees that outbound connects will finish in any order whatsoever, if you’re using any transport except inproc. So, the example does a brute force sleep of one second between subscribing, and sending the REQ/REP synchronization.
我们不能假设在 REQ/REP 对话完成时，SUB 的连接已经完成。除非使用 inproc 传输，否则无法保证出站连接会以任何顺序完成。因此，示例在订阅和发送 REQ/REP 同步之间强制暂停了一秒钟。

A more robust model could be:
一个更健壮的模型可以是：

Publisher opens PUB socket and starts sending “Hello” messages (not data).
发布者打开 PUB 套接字并开始发送“Hello”消息（不是数据）。
Subscribers connect SUB socket and when they receive a Hello message they tell the publisher via a REQ/REP socket pair.
订阅者连接 SUB 套接字，当他们收到 Hello 消息时，通过 REQ/REP 套接字对告诉发布者。
When the publisher has had all the necessary confirmations, it starts to send real data.
当发布者获得所有必要的确认后，它开始发送真实数据。

Zero-Copy 零拷贝#

ZeroMQ’s message API lets you send and receive messages directly from and to application buffers without copying data. We call this zero-copy, and it can improve performance in some applications.
ZeroMQ 的消息 API 允许你直接从应用程序缓冲区发送和接收消息，而无需复制数据。我们称之为零拷贝，这在某些应用中可以提升性能。

You should think about using zero-copy in the specific case where you are sending large blocks of memory (thousands of bytes), at a high frequency. For short messages, or for lower message rates, using zero-copy will make your code messier and more complex with no measurable benefit. Like all optimizations, use this when you know it helps, and measure before and after.
你应该在发送大块内存（数千字节）且频率较高的特定情况下考虑使用零拷贝。对于短消息或较低的消息速率，使用零拷贝会使代码变得更混乱、更复杂，而没有明显的好处。像所有优化一样，只有在确定它有帮助时才使用，并且要在使用前后进行测量。

To do zero-copy, you use zmq_msg_init_data() to create a message that refers to a block of data already allocated with malloc() or some other allocator, and then you pass that to zmq_msg_send(). When you create the message, you also pass a function that ZeroMQ will call to free the block of data, when it has finished sending the message. This is the simplest example, assuming buffer is a block of 1,000 bytes allocated on the heap:
要实现零拷贝，你使用 zmq_msg_init_data() 创建一个消息，该消息引用已经通过 malloc() 或其他分配器分配的数据块，然后将其传递给 zmq_msg_send() 。创建消息时，你还需要传递一个函数，ZeroMQ 会在发送完消息后调用该函数来释放数据块。以下是最简单的示例，假设 buffer 是堆上分配的 1000 字节数据块：


void my_free (void *data, void *hint) {
    free (data);
}
//  Send message from buffer, which we allocate and ZeroMQ will free for us
zmq_msg_t message;
zmq_msg_init_data (&message, buffer, 1000, my_free, NULL);
zmq_msg_send (&message, socket, 0);

Note that you don’t call zmq_msg_close() after sending a message–libzmq will do this automatically when it’s actually done sending the message.
请注意，发送消息后无需调用 zmq_msg_close() —— libzmq 会在消息实际发送完成时自动执行此操作。

There is no way to do zero-copy on receive: ZeroMQ delivers you a buffer that you can store as long as you wish, but it will not write data directly into application buffers.
接收时无法实现零拷贝：ZeroMQ 会交付一个缓冲区，你可以根据需要保存它，但它不会将数据直接写入应用程序缓冲区。

On writing, ZeroMQ’s multipart messages work nicely together with zero-copy. In traditional messaging, you need to marshal different buffers together into one buffer that you can send. That means copying data. With ZeroMQ, you can send multiple buffers coming from different sources as individual message frames. Send each field as a length-delimited frame. To the application, it looks like a series of send and receive calls. But internally, the multiple parts get written to the network and read back with single system calls, so it’s very efficient.
在写入时，ZeroMQ 的多部分消息与零拷贝配合得很好。在传统消息传递中，你需要将不同的缓冲区合并成一个缓冲区进行发送，这意味着数据拷贝。而使用 ZeroMQ，你可以将来自不同来源的多个缓冲区作为独立的消息帧发送。将每个字段作为一个长度限定的帧发送。对应用程序来说，这看起来像是一系列的发送和接收调用。但在内部，多个部分通过单个系统调用写入网络并读取回来，因此效率非常高。

Pub-Sub Message Envelopes
发布-订阅消息信封#

In the pub-sub pattern, we can split the key into a separate message frame that we call an envelope. If you want to use pub-sub envelopes, make them yourself. It’s optional, and in previous pub-sub examples we didn’t do this. Using a pub-sub envelope is a little more work for simple cases, but it’s cleaner especially for real cases, where the key and the data are naturally separate things.
在发布-订阅模式中，我们可以将键拆分成一个单独的消息帧，称为信封。如果你想使用发布-订阅信封，可以自己实现。这是可选的，在之前的发布-订阅示例中我们没有这样做。对于简单情况，使用发布-订阅信封稍微麻烦一些，但对于实际情况来说更清晰，因为键和数据本质上是两个独立的东西。

Figure 23 - Pub-Sub Envelope with Separate Key
图 23 - 带有独立键的发布-订阅信封

Subscriptions do a prefix match. That is, they look for “all messages starting with XYZ”. The obvious question is: how to delimit keys from data so that the prefix match doesn’t accidentally match data. The best answer is to use an envelope because the match won’t cross a frame boundary. Here is a minimalist example of how pub-sub envelopes look in code. This publisher sends messages of two types, A and B.
订阅执行前缀匹配。也就是说，它们查找“所有以 XYZ 开头的消息”。显而易见的问题是：如何区分键和数据，以防前缀匹配意外匹配到数据。最好的答案是使用信封，因为匹配不会跨越帧边界。下面是一个极简示例，展示了发布-订阅信封在代码中的样子。该发布者发送两种类型的消息，A 和 B。

The envelope holds the message type:
信封包含消息类型：

psenvpub: Pub-Sub envelope publisher in C++
psenvpub：C++ 中的发布-订阅信封发布者

//
//  Pubsub envelope publisher
//  Note that the zhelpers.h file also provides s_sendmore
//

#include "zhelpers.hpp"

int main () {
    //  Prepare our context and publisher
    zmq::context_t context(1);
    zmq::socket_t publisher(context, ZMQ_PUB);
    publisher.bind("tcp://*:5563");

    while (1) {
        //  Write two messages, each with an envelope and content
        s_sendmore (publisher, std::string("A"));
        s_send (publisher, std::string("We don't want to see this"));
        s_sendmore (publisher, std::string("B"));
        s_send (publisher, std::string("We would like to see this"));
        sleep (1);
    }
    return 0;
}

The subscriber wants only messages of type B:
订阅者只想要类型为 B 的消息：

psenvsub: Pub-Sub envelope subscriber in C++
psenvsub：C++ 中的发布-订阅信封订阅者

//
//  Pubsub envelope subscriber
//

#include "zhelpers.hpp"

int main () {
    //  Prepare our context and subscriber
    zmq::context_t context(1);
    zmq::socket_t subscriber (context, ZMQ_SUB);
    subscriber.connect("tcp://localhost:5563");
    subscriber.set( zmq::sockopt::subscribe, "B");

    while (1) {
 
		//  Read envelope with address
		std::string address = s_recv (subscriber);
		//  Read message contents
		std::string contents = s_recv (subscriber);
		
        std::cout << "[" << address << "] " << contents << std::endl;
    }
    return 0;
}

When you run the two programs, the subscriber should show you this:
当你运行这两个程序时，订阅者应该会显示如下内容：

[B] We would like to see this
[B] We would like to see this
[B] We would like to see this
...

This example shows that the subscription filter rejects or accepts the entire multipart message (key plus data). You won’t get part of a multipart message, ever. If you subscribe to multiple publishers and you want to know their address so that you can send them data via another socket (and this is a typical use case), create a three-part message.
这个例子表明订阅过滤器会拒绝或接受整个多部分消息（键加数据）。你永远不会只收到多部分消息的一部分。如果你订阅多个发布者，并且想知道它们的地址以便通过另一个套接字向它们发送数据（这是一个典型用例），请创建一个三部分消息。

Figure 24 - Pub-Sub Envelope with Sender Address
图 24 - 带发送者地址的发布-订阅信封

High-Water Marks 高水位标记#

When you can send messages rapidly from process to process, you soon discover that memory is a precious resource, and one that can be trivially filled up. A few seconds of delay somewhere in a process can turn into a backlog that blows up a server unless you understand the problem and take precautions.
当你能够快速地从一个进程向另一个进程发送消息时，你很快会发现内存是一种宝贵的资源，而且很容易被填满。某个进程中几秒钟的延迟可能会变成积压，导致服务器崩溃，除非你理解问题并采取预防措施。

The problem is this: imagine you have process A sending messages at high frequency to process B, which is processing them. Suddenly B gets very busy (garbage collection, CPU overload, whatever), and can’t process the messages for a short period. It could be a few seconds for some heavy garbage collection, or it could be much longer, if there’s a more serious problem. What happens to the messages that process A is still trying to send frantically? Some will sit in B’s network buffers. Some will sit on the Ethernet wire itself. Some will sit in A’s network buffers. And the rest will accumulate in A’s memory, as rapidly as the application behind A sends them. If you don’t take some precaution, A can easily run out of memory and crash.
问题是这样的：假设你有进程 A 以高频率向进程 B 发送消息，B 正在处理这些消息。突然 B 变得非常忙碌（垃圾回收、CPU 过载等原因），短时间内无法处理消息。可能是几秒钟的重度垃圾回收，也可能更长时间，如果出现更严重的问题。此时，进程 A 仍在疯狂地尝试发送消息，这些消息会发生什么？部分消息会停留在 B 的网络缓冲区，部分会停留在以太网线路上，部分会停留在 A 的网络缓冲区，其余的则会随着 A 后端应用发送的速度迅速积累在 A 的内存中。如果不采取任何预防措施，A 很容易耗尽内存并崩溃。

It is a consistent, classic problem with message brokers. What makes it hurt more is that it’s B’s fault, superficially, and B is typically a user-written application which A has no control over.
这是消息代理中一个一贯且经典的问题。更让人头疼的是，表面上看是 B 的错，而 B 通常是用户编写的应用程序，A 无法控制它。

What are the answers? One is to pass the problem upstream. A is getting the messages from somewhere else. So tell that process, “Stop!” And so on. This is called flow control. It sounds plausible, but what if you’re sending out a Twitter feed? Do you tell the whole world to stop tweeting while B gets its act together?
解决方案是什么？其中一个是将问题传递给上游。A 是从别处接收消息的，所以告诉那个过程，“停！”等等。这就是所谓的流量控制。听起来合理，但如果你正在发送 Twitter 推文呢？你会告诉全世界在 B 调整好之前停止发推吗？

Flow control works in some cases, but not in others. The transport layer can’t tell the application layer to “stop” any more than a subway system can tell a large business, “please keep your staff at work for another half an hour. I’m too busy”. The answer for messaging is to set limits on the size of buffers, and then when we reach those limits, to take some sensible action. In some cases (not for a subway system, though), the answer is to throw away messages. In others, the best strategy is to wait.
流量控制在某些情况下有效，但在其他情况下无效。传输层不能像地铁系统不能告诉大型企业“请让员工多工作半小时，我太忙了”一样，告诉应用层“停”。消息传递的解决方案是设置缓冲区大小限制，当达到限制时采取合理的措施。在某些情况下（地铁系统除外），答案是丢弃消息。在其他情况下，最佳策略是等待。

ZeroMQ uses the concept of HWM (high-water mark) to define the capacity of its internal pipes. Each connection out of a socket or into a socket has its own pipe, and HWM for sending, and/or receiving, depending on the socket type. Some sockets (PUB, PUSH) only have send buffers. Some (SUB, PULL, REQ, REP) only have receive buffers. Some (DEALER, ROUTER, PAIR) have both send and receive buffers.
ZeroMQ 使用 HWM（高水位标记）的概念来定义其内部管道的容量。每个从套接字发出的连接或进入套接字的连接都有自己的管道，并且根据套接字类型具有发送和/或接收的 HWM。一些套接字（PUB、PUSH）只有发送缓冲区。一些（SUB、PULL、REQ、REP）只有接收缓冲区。一些（DEALER、ROUTER、PAIR）则同时具有发送和接收缓冲区。

In ZeroMQ v2.x, the HWM was infinite by default. This was easy but also typically fatal for high-volume publishers. In ZeroMQ v3.x, it’s set to 1,000 by default, which is more sensible. If you’re still using ZeroMQ v2.x, you should always set a HWM on your sockets, be it 1,000 to match ZeroMQ v3.x or another figure that takes into account your message sizes and expected subscriber performance.
在 ZeroMQ v2.x 中，HWM 默认是无限的。这虽然简单，但对于高流量的发布者来说通常是致命的。在 ZeroMQ v3.x 中，默认设置为 1000，这更合理。如果你仍在使用 ZeroMQ v2.x，应该始终为你的套接字设置 HWM，无论是设置为 1000 以匹配 ZeroMQ v3.x，还是根据你的消息大小和预期的订阅者性能设置其他数值。

When your socket reaches its HWM, it will either block or drop data depending on the socket type. PUB and ROUTER sockets will drop data if they reach their HWM, while other socket types will block. Over the inproc transport, the sender and receiver share the same buffers, so the real HWM is the sum of the HWM set by both sides.
当你的套接字达到其 HWM 时，会根据套接字类型阻塞或丢弃数据。PUB 和 ROUTER 套接字在达到 HWM 时会丢弃数据，而其他套接字类型则会阻塞。在 inproc 传输上，发送方和接收方共享相同的缓冲区，因此实际的 HWM 是双方设置的 HWM 之和。

Lastly, the HWMs are not exact; while you may get up to 1,000 messages by default, the real buffer size may be much lower (as little as half), due to the way libzmq implements its queues.
最后，HWM 不是精确的；虽然默认情况下您可能会收到多达 1,000 条消息，但由于 libzmq 实现其队列的方式，实际缓冲区大小可能会低得多（可能只有一半）。

Missing Message Problem Solver
丢失消息问题解决方案#

As you build applications with ZeroMQ, you will come across this problem more than once: losing messages that you expect to receive. We have put together a diagram that walks through the most common causes for this.
在使用 ZeroMQ 构建应用程序时，您会多次遇到这样的问题：丢失了预期接收的消息。我们整理了一张图表，详细说明了最常见的原因。

Figure 25 - Missing Message Problem Solver
图 25 - 丢失消息问题解决方案

Here’s a summary of what the graphic says:
以下是图示内容的总结：

On SUB sockets, set a subscription using zmq_setsockopt() with ZMQ_SUBSCRIBE, or you won’t get messages. Because you subscribe to messages by prefix, if you subscribe to "” (an empty subscription), you will get everything.
在 SUB 套接字上，使用 zmq_setsockopt() 和 ZMQ_SUBSCRIBE 设置订阅，否则你将收不到消息。因为你是通过前缀订阅消息的，如果你订阅了“”（空订阅），你将收到所有消息。
If you start the SUB socket (i.e., establish a connection to a PUB socket) after the PUB socket has started sending out data, you will lose whatever it published before the connection was made. If this is a problem, set up your architecture so the SUB socket starts first, then the PUB socket starts publishing.
如果你在 PUB 套接字开始发送数据之后才启动 SUB 套接字（即建立与 PUB 套接字的连接），你将丢失连接建立之前发布的所有消息。如果这是个问题，请将架构设置为先启动 SUB 套接字，然后再启动 PUB 套接字进行发布。
Even if you synchronize a SUB and PUB socket, you may still lose messages. It’s due to the fact that internal queues aren’t created until a connection is actually created. If you can switch the bind/connect direction so the SUB socket binds, and the PUB socket connects, you may find it works more as you’d expect.
即使你同步了 SUB 和 PUB 套接字，你仍然可能丢失消息。这是因为内部队列直到连接真正建立后才会创建。如果你能调整绑定/连接方向，让 SUB 套接字绑定，PUB 套接字连接，你可能会发现它的行为更符合预期。
If you’re using REP and REQ sockets, and you’re not sticking to the synchronous send/recv/send/recv order, ZeroMQ will report errors, which you might ignore. Then, it would look like you’re losing messages. If you use REQ or REP, stick to the send/recv order, and always, in real code, check for errors on ZeroMQ calls.
如果你使用 REP 和 REQ 套接字，并且没有遵循同步的 send/recv/send/recv 顺序，ZeroMQ 会报告错误，而你可能会忽略它们。这样看起来就像你丢失了消息。如果使用 REQ 或 REP，请坚持 send/recv 顺序，并且在实际代码中始终检查 ZeroMQ 调用的错误。
If you’re using PUSH sockets, you’ll find that the first PULL socket to connect will grab an unfair share of messages. The accurate rotation of messages only happens when all PULL sockets are successfully connected, which can take some milliseconds. As an alternative to PUSH/PULL, for lower data rates, consider using ROUTER/DEALER and the load balancing pattern.
如果你使用的是 PUSH 套接字，你会发现第一个连接的 PULL 套接字会获得不公平的消息份额。只有当所有 PULL 套接字都成功连接后，消息的准确轮转才会发生，这可能需要几毫秒。作为 PUSH/PULL 的替代方案，对于较低的数据速率，可以考虑使用 ROUTER/DEALER 和负载均衡模式。
If you’re sharing sockets across threads, don’t. It will lead to random weirdness, and crashes.
如果你在多个线程间共享套接字，千万别这么做。这会导致随机的异常行为和崩溃。
If you’re using inproc, make sure both sockets are in the same context. Otherwise the connecting side will in fact fail. Also, bind first, then connect. inproc is not a disconnected transport like tcp.
如果你使用的是 inproc ，确保两个套接字在同一个上下文中。否则，连接方实际上会失败。另外，先绑定，再连接。 inproc 不是像 tcp 那样的断开传输。
If you’re using ROUTER sockets, it’s remarkably easy to lose messages by accident, by sending malformed identity frames (or forgetting to send an identity frame). In general setting the ZMQ_ROUTER_MANDATORY option on ROUTER sockets is a good idea, but do also check the return code on every send call.
如果你使用的是 ROUTER 套接字，通过发送格式错误的身份帧（或忘记发送身份帧）意外丢失消息是非常容易的。通常在 ROUTER 套接字上设置 ZMQ_ROUTER_MANDATORY 选项是个好主意，但也要检查每次发送调用的返回码。
Lastly, if you really can’t figure out what’s going wrong, make a minimal test case that reproduces the problem, and ask for help from the ZeroMQ community.
最后，如果你实在无法弄清楚问题出在哪里，制作一个能重现问题的最小测试用例，并向 ZeroMQ 社区寻求帮助。

Chapter 2 - Sockets and Patterns 第 2 章 - 套接字与模式#

The Socket API 套接字 API#

Plugging Sockets into the Topology 将套接字插入拓扑结构#

Sending and Receiving Messages 发送和接收消息#

Unicast Transports 单播传输#

ZeroMQ is Not a Neutral Carrier ZeroMQ 不是中立的载体#

I/O Threads I/O 线程#

Messaging Patterns 消息传递模式#

High-Level Messaging Patterns 高级消息传递模式#

Working with Messages 消息处理#

Handling Multiple Sockets 处理多个套接字#

Multipart Messages 多部分消息#

Intermediaries and Proxies 中间件和代理#

The Dynamic Discovery Problem 动态发现问题#

Shared Queue (DEALER and ROUTER sockets) 共享队列（DEALER 和 ROUTER 套接字）#

ZeroMQ’s Built-In Proxy Function ZeroMQ 内置代理功能#