本文转载 https://blog.csdn.net/yahohi/article/details/76231389
发布/订阅模式详解
特点：
1.一个发布者，多个订阅者的关系，1：n；
2.当发布者数据变化时发布数据，所有订阅者均能够接收到数据并处理。
这就是发布/订阅模式。
1. PUB-SUB模式是异步的
订阅者调用zmq_send()来发送消息是会报错的，同样发布者使用zmq_recv()来接收消息也会报错。
2.PUB和SUB谁bind谁connect并无严格要求（虽本质并无区别），但仍建议PUB使用bind，SUB使用connect
3.”slow joiner”可能导致发布者的第一笔消息总是丢失
由于套接字建立连接需要时间，如果在发布者已经发出消息，但订阅者仍未就绪的情况下就可能出现订阅者无法收到消息的情况。为了解决这个问题，需要做发布者订阅者的同步机制。
同步机制探讨：1.通过delay或sleep延迟启动：这不是一个好方法，由于不同机器性能不同，可能导致需要延迟的时间不同， 无法根本解决这个问题，同时这种编码方式也过于粗暴；
2.在丢失的消息不影响程序正确性的基础上，可以不用考虑同步。
为了进一步探讨同步机制，可参考：http://zguide.zeromq.org/page:all#sockets-and-patterns
4.一个订阅者（subcriber）可以链接超过一个发布者（publisher）。数据到达后将交叉存取（公平队列），以保证发布者之间的数据不会淹没。
5.如果一个发布者（publisher）没有任何订阅者（subcriber）连接，则发布者会简单的丢弃所有的消息。
6.如果使用TCP同时订阅者（subcriber）很慢，这会导致消息在发布者（publisher）端排队，造成消息堆积影响程序性能，为了解决这个问题，需要合理设置high-water mark（高水位线）。
| 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. 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. |
要注意的是，PUB、ROUTER套接字在到达HWM后会丢弃数据，其他的会阻塞。另外，inproc的transport，发送端和接收端共享同一个缓存，因此实际HWM是两者HWM之和。
下面是对必须处理未知订阅方的发布方来说的一个更明智的“最佳实践”：
| 总是给套接字设置一个基于期望的订阅方数量的最大值，你打算用于队列的内存的数量，和一个消息平均大小的高水位线。例如，如果你希望有5000个订阅方，有1G的内存可有，消息平均200字节，那么一个安全的高水位线应该是（1000000000/200/5000）=1000. |