1 拯救世界（Fixing the World）
如何解释ZeroMQ？
- 用它可以完成的精彩的事情来解释：ZeroMQ是打了激素的套接字（It's sockets on steroids）；ZeroMQ是带有路由的邮箱。
- 用人们对它的评价来解释：ZeroMQ很快；复杂性不见了，ZeroMQ让事情变得简单；ZeroMQ解放了思维。
- 通过比较来解释：ZeroMQ更小、更简单。
而文档作者带领大家回忆为什么创造ZeroMQ，因为当时作者所处的境况跟读者今天的境况非常相似。
要拯救这个世界，需要做两件事：
- 解决“如何在任何地点连接任何代码到任何代码（how to connect any code to any code, anywhere）”的问题
- 将解决方法封装到尽可能简单的建造块中，让人们容易理解和使用
2 获取示例代码
git clone --depth=1 https://github.com/imatix/zguide.git3 请求-回应模式
3.1 服务器代码
#include <zmq.h>
#include <zmq_helpers.h>
#include <stdio.h>
#pragma comment(lib,"libzmq-v100-mt.lib")
int main(void){
}
3.2 客户端代码
#include <zmq.h>
#include <zmq_helpers.h>
#include <stdio.h>
#pragma comment(lib,"libzmq-v100-mt.lib")
int main(void){
}
3.3 关于字符串
zmq_send (requester, "Hello", 6, 0);socket.send ("Hello")static char *s_recv (void *socket) {
}
static int s_send (void *socket, char *string) {
}
3.4 报告ZeroMQ版本(c语言版本)
#include <zmq.h>
int main (void)
{
int major, minor, patch;
zmq_version (&major, &minor, &patch);
printf ("Current 0MQ version is %d.%d.%d\n", major, minor, patch);
return 0;
}4 发布-订阅模式
4.1 服务器代码
#include <zmq.h>
#include <zmq_helpers.h>
#include <stdio.h>
#pragma comment(lib,"libzmq-v100-mt.lib")
int main(void){
}
4.2 客户端代码
#define _CRT_SECURE_NO_WARNINGS
#include <zmq.h>
#include <zmq_helpers.h>
#include <stdio.h>
#pragma comment(lib,"libzmq-v100-mt.lib")
int main(int argc,char* argv[]){
}
4.3 注解
- 订阅
- 必须使用zmq_setsockopt在订阅套接字上设置订阅，否则收不到任何消息
- 可以在订阅套接字上设置多个订阅，套接字会接收满足任何一个订阅条件的消息
- 可以分别取消各个订阅
- 异步
- 发布-订阅套接字对是异步的
- 在订阅套接字上发送消息（调用zmq_send)会导致错误
- 在发布套接字上接收消息（调用zmq_recv)会导致错误
- 绑定和连接
- 理论上说，哪一端调用connect，哪一端调用bind是没有关系的。但是对于发布-订阅套接字，最好是对发布套接字调用bind；对订阅套接字调用connect。否则订阅套接字可能收到较早的消息，也就是订阅套接字启动之前的消息。
- 订阅者总是会错过发布者发送的第一个消息
- 因为不知道订阅者开始获取消息的精确时间。即使是先启动订阅者，等待一会儿再启动发布者，订阅者也总是会错过发布者发布的第一个消息。因为订阅者连接到发布者是需要时间的，而发布者可能已经在发送消息了。这种“慢加入（slow joiner）”特征不容易理解。假设有两个节点执行下述动作：
- 订阅者连接到某端点，接收并计数消息
- 发布者绑定到某端点并且立即发送1000条消息
- 这种情况下订阅者很可能接收不不到任何消息。
- 建立TCP连接所需的握手需要毫秒级的时间。建立连接期间ZeroMQ可以发送很多消息。为便于讨论，假设建立连接需要5毫秒，而链路每秒可以处理100万条消息。在订阅者连接到发布者的5毫秒时间内，发布者只用1毫秒的时间就可以发送完1000条消息（而此时订阅者还没有连接上，所以这1000条消息被丢弃）。
- 第二章会解释如何同步发布者和订阅者，以便只有在订阅者连接上并且准备好之后，发布者才开始发布消息。有一种简单而愚蠢的延迟发布的方法，就是sleep。最好不要使用这种方法，因为它很脆弱，也不雅观，还很慢。当然现在可以使用sleep，到第二章再看怎么正确地同步。
- 另一种替代的同步方法是，将发布的数据流看做是无限的，没有起点，没有终点。本节的例子就是这么做的：可以任意启动、停止、重启服务器，而客户端程序不管这些，它只是在收集到1000条更新消息后，计算平均值，输出，然后退出。
- 因为不知道订阅者开始获取消息的精确时间。即使是先启动订阅者，等待一会儿再启动发布者，订阅者也总是会错过发布者发布的第一个消息。因为订阅者连接到发布者是需要时间的，而发布者可能已经在发送消息了。这种“慢加入（slow joiner）”特征不容易理解。假设有两个节点执行下述动作：
- 发布-订阅模式的一些特征
- 订阅者可以连接到多个发布者，只要多次调用connect就可以了。数据会交错地到达，一个发布者发布的数据不会淹没其他发布者的数据。
- 如果没有订阅者连接，发布者会简单地丢弃所有消息。
- 如果使用TCP，并且订阅者较慢，则消息会在发布者那边排队。后面会介绍如何使用“高水位标记”来阻止发布者对消息进行排队。
- 当前版本的ZeroMQ中，消息过滤发生在订阅者那一端，而不是在发布者这边。也就是说，在TCP中，发布者会发送所有消息到所有订阅者中，而订阅者会丢弃不想要的消息。
5 管线模式
- 一个设备生成可以并行执行的任务
- 很多工作者可以处理这些任务
- 一个汇聚点(sink)从工作者进程收集任务执行结果
5.1 任务发生器
#include <zmq.h>
#include <zmq_helpers.h>
#include <stdio.h>
#pragma comment(lib,"libzmq-v100-mt.lib")
int main(void){
}
5.2 工作者
#include <zmq.h>
#include <zmq_helpers.h>
#include <stdio.h>
#pragma comment(lib,"libzmq-v100-mt.lib")
int main(void){
}
5.3 汇聚点
#include <zmq.h>
#include <zmq_helpers.h>
#include <stdio.h>
#pragma comment(lib,"libzmq-v100-mt.lib")
int main(void){
}
5.4 注解
- 工作者上面连接到任务发生器，下面连接到汇聚点。可以任意添加工作者。任务发生器和汇聚点是这个体系的“静态”组件，而工作者是“动态”组件。
- 必须同步工作者的启动和运行。这种情况在ZeroMQ中很常见，而且没有容易的解决方案。连接需要一定的时间才能完成。一系列工作者连接到任务发生器的时候，第一个连接上的工作者将在其他工作者还在连接中的这个较短时间内处理所有的工作负载。如果不能同步工作者的启动，系统可能不会并行地运行。
- 任务发生器的PUSH套接字将任务平等地分发给工作者，这就是负载均衡。后面会详细讨论负载均衡。
- 汇聚点的PULL套接字从工作者平等地收集结果，这叫做公平排队。
管道线模式也存在“慢加入（slow joiner）”的问题，这会让PUSH套接字不能正确地进行负载均衡。
6 ZeroMQ编程
请注意
- 一步一步地学习ZeroMQ。简单的API隐藏了很多可能性。请慢慢学习，掌握每种可能性。
- 编写优雅的代码。龌龊的代码会隐藏问题，让别人很难帮助你。
- 边编程边测试。程序出现问题的时候，你应该能定位问题到5行代码之内。
- 程序不能正确工作时，切分代码，分别测试，看是哪一部分有问题。
- 必要的时候才进行抽象（类、方法等等）。复制/粘贴大量代码的时候会同时复制/粘贴错误。
- 最好不要在线程间传递套接字。从ZeroMQ 2.1版本开始，线程间传递套接字是合法的了，但是还是很危险，除非使用“全内存护栏（full memory barrier）”。
6.1 正确获取上下文
- 调用zmq_ctx_new创建上下文
- 一个进程只应该创建和使用一个上下文对象
- 虽然可以创建多个上下文，但是两个及更多个上下文被看做是单独的ZeroMQ实例
- 在main函数开始处调用zmq_ctx_new，结尾处调用zmq_ctx_destroy
- 使用fork()创建子进程的时候，每个子进程需要有自己的上下文。如果在主进程中调用fork()之前调用zmq_ctx_new，则子进程可以继承上下文，而不用再调用zmq_ctx_new。
6.2 干净地退出
- 使用Python等具有自动垃圾收集功能的语言时不用关注资源的释放，但是使用C/C++的时候就要注意了，要在使用完资源后正确地释放，否则可能导致内存泄露、程序不稳定等问题。
- ZeroMQ对于程序的退出要求非常严格。如果调用zmq_ctx_destroy的时候还有打开的套接字，则调用会永远挂起。即使关闭了所有套接字，如果还有未决的connect或者send调用，zmq_ctx_destroy还是会无限等待，除非关闭套接字前将其LINGER选项设置为0了。
- 只需要关注三种ZeroMQ对象：消息、套接字和上下文。简单程序中的处理规则比较简单：
- 使用完消息之后总是调用zmq_msg_close来关闭
- 如果打开和关闭很多套接字，则你可能需要重新设计你的应用程序
- 退出程序的时候，关闭套接字，然后调用zmq_ctx_destroy，这会销毁上下文
- 如果使用多线程，则会复杂得多。简单地说，一般要遵循的规则是：
- 不要企图在多个线程中使用同一个套接字
- 设置所有套接字的LINGER选项为0(relingerfy)，关闭所有套接字，在主线程中销毁上下文
- 这会使得附着线程（共享相同上下文的线程）中任何阻塞的receive或者poll或者send操作返回错误。请捕捉这个错误，在附着线程中重新设置LINGER选项(relingerize），关闭套接字。
- 不要两次销毁同一个上下文。主线程中的zmq_ctx_destroy会阻塞直到它所知道的所有套接字安全地关闭了。
6.3 为什么需要ZeroMQ
6.3.1 可重用的消息层
- 如何处理IO？是阻塞地处理，还是在后台处理？这是一个主要的设计决策。阻塞IO让体系难以扩展，而后台IO很难做对。
- 如何处理动态组件，比如说，临时离开的部分？是不是正式地划分“客户端”和“服务器”组件，并且强制要求服务器不会离线？如果服务器要连接到服务器该怎么办？是不是每隔几秒尝试重连？
- 如何在线路中表示消息？如何对消息分帧以便于写入和读取，并且不会缓冲区溢出，而且对小的消息高效，又能处理很大的视频数据？
- 如何处理不能立即发送的消息？特别是，是不是要等待组件重新上线？是丢弃消息，放入到数据库中，还是放入内存队列中？
- 在哪里存放消息队列？如果组件从队列中读取消息很慢，队列填满时会发生什么？我们的策略是？
- 如何处理消息丢失？是等待新的数据，还是请求重发，或者创建某种类型的可靠层，保证消息不会丢失？如果可靠层本身崩溃了怎么办？
- 需要不同的网络传输端点时怎么办？比如说，需要用多播代替TCP单播？或者要使用IPv6？我们是要重写应用程序，还是将传输端点抽象到某层中？
- 如何路由消息？能不能把相同的消息发送给多个端点？能把回应发送给原始的请求者吗？
- 如何编写其他语言的API？是重新实现线路层协议，还是重新封装库？如果使用前者，如何保证协议栈的稳定和高效？如果是后者，如何保证互操作性？
- 如何表示数据，以便可以在多种体系结构中正确读取？是否强制要求对数据类型使用某种特定的编码？这是消息传递系统的任务，还是更高层的任务？
- 如何处理网络错误？是等待然后重试，还是沉默地忽略错误，还是终止程序(abort)？
6.3.2 ZeroMQ的特征
- 在后台线程中异步地处理IO。后台线程使用无需锁的数据结构与应用线程通信，所以ZeroMQ应用程序不需要锁、信号量，或者其他等待状态。
- 组件可以动态地加入和退出，ZeroMQ会自动重新连接。这意味着可以以任何次序启动组件。可以创建“面向服务架构（service-oriented architectures)”，其中的服务可以在任何时候加入或者退出网络。
- 在需要的时候自动对消息排队。这种处理是智能的，在排队前会尽量让消息靠近接收者。
- 有处理队列溢出的方法（“高水位标记”）。队列满的时候，ZeroMQ会自动阻塞发送者，或者丢弃消息，取决于你正在使用的消息传递类型（模式）。
- ZeroMQ让应用程序可以使用传输端点相互交流：TCP、多播、进程内、进程间。使用不同的传输端点时不用修改代码。
- 根据消息传递模式的不同，使用不同的策略来安全地处理慢速/阻塞的接收者。
- 使用请求-应答、发布-订阅等多种模式来路由消息。这些模式定义了如何创建网络拓扑结构。
- 需要降低互联的各部分间的复杂性的时候，可以在网络中放置模式扩展的“设备”（小的代理）。
- 通过在线路中使用简单的帧，可以精确地传递整个消息。发送10K的消息，则会收到10K的消息。
- 不对消息格式做任何假定。消息是从零到数G字节的块。需要在高层使用其他产品来表示数据，如Google的Protocol Buffers、XDR等等。
- 智能地处理网络错误。有时候重试，有时候告诉你操作失败。
- 降低能耗。使用较少的CPU时间来做更多事情意味着使用更少的能源，而且较老的机器可以使用更长的时间。
6.4 问题解决
- 创建原型，让自己学习和测试设计得各个方面。增加压力直到崩溃，以了解设计的强壮程度。
- 进行测试。创建测试框架，确保能够使用真实的环境，进行认真的测试。最好是一个团队写代码，另一个团队企图让它崩溃。
- 联系iMatix，看看它能给你什么帮助。
扫一扫
901
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
