简介面向Windows平台下使用VS2008学习ZeroMQ发布/订阅通信的初学者这份教程与实例围绕库文件编译和最小可运行工程展开可用于快速搭建消息收发环境、理解发布端与订阅端的连接方式和基本调用流程适合零基础入门或课堂演示。包内共31个文件以头文件、源码、动态库、导入库和工程说明为主另有项目文件、解决方案及操作文档压缩包约4.25MB这些内容覆盖从库编译到服务端、客户端示例的完整流程目录按工程与库文件组织便于对照搭建、编译和调试。已有490人学习下载。读者可参考随附使用说明完成环境配置借助服务端与客户端两个项目观察订阅发布关系并通过库文件与工程配置说明排查头文件路径、链接依赖等常见问题文档文字简洁、示例规模较小适合作为入门练习和课堂示例的起步材料也可为后续扩展消息通信打下基础。1. 从一次两端都跑起来却收不到消息说起有个做产线数据采集的同行拿了一份 Windows 下 VS2008 使用 ZeroMQ 做订阅发布的实例来问编译零警告发布端、订阅端两个进程都起来了订阅端一条消息都收不到也没有任何报错。这种代码看着对、数据不落地的情况在 VS2008 ZeroMQ 这套组合上出现频率很高——编译器是 VC9库得自己编运行时库、导出宏、订阅过滤的注册时机任何一环对不上都是静默失败没有异常、没有崩溃就是不给你数据。这套东西今天还在不少上位机和老工控软件里服役工程文件是 vcproj升级编译器牵一发动全身但裸 socket 的粘包、断线重连、多路复用又实在不想再写一遍。ZeroMQ 的 PUB/SUB 恰好是这类一路广播、多路接收场景里最省事的一层。下面按我实际复现的顺序走一遍编库、写两端、调过滤、排坑。2. 在 VS2008 里把 libzmq 编成静态库从源码到能链接的 .lib2.1 为什么这个场景建议自己编而不是抓一个现成 DLL网上能找到的预编译二进制多数是用更新的 MSVC 工具链出的运行时库是 MSVCR100 往上。VS2008 默认链的是 MSVCR90把两套 CRT 混在一个进程里最容易出现的不是编译错误而是运行时堆操作跨了 CRT 边界——内存在 A 里分配、在 B 里释放Debug 下直接断言Release 下偶发崩溃查起来极其难受。这是我建议自己编的第一条理由库和宿主程序用同一个编译器、同一套运行时库边界问题从源头消失。第二条是部署。静态库编完就是一个 .lib最终 exe 拷到现场机器上就能跑不用再操心 libzmq.dll 的位数、版本、搜索路径。工控现场的机器往往不让随便装东西少一个依赖就少一次电话支持。代价也要说清楚换分支要重编全量编译在这台老机器上大概几分钟调试时如果库里的断言触发栈会跑到库里得把 pdb 一起留着。所以我的习惯是 Debug 和 Release 各编一份命名区分开工程里用宏切换。方式现场部署CRT 冲突风险断点进库适合谁预编译 DLL要带 dll且位数/版本必须匹配高工具链不一致不能只做验证、不改库自己编静态库单 exe零额外文件无同工具链能需保留 pdb长期维护的老工程自己编 DLL要带 dll但可多程序共用无能多个进程共用一份库2.2 工程参数逐项对齐错一项就前功尽弃源码树里一般已经带了 msvc 目录和对应年代的工程文件能直接用就别自己造。没有的话新建一个Win32 静态库工程把 src 下参与编译的 .cpp 全加进去。有几个文件在 Windows 上是给别的平台准备的选中后从工程里排除epoll、kqueue、devpoll 这几组事件引擎Windows 走的是 select 或完成端口。这一步不做编译期就会撞上一堆 unistd.h 找不到。下面这张表是我每次建工程都会逐项对一遍的配置比记在脑子里靠谱配置项取值为什么配置类型静态库 (.lib)产出单一 .lib不生成 dll平台Win32与宿主 exe 位数必须一致字符集使用多字节字符集库是窄字符 API减少转换噪音运行时库/MTd 或 /MDDebug/Release 各自成对与最终 exe 完全一致否则 LNK2005预处理器定义ZMQ_STATIC;WIN32;_LIB;_CRT_SECURE_NO_WARNINGSZMQ_STATIC 关掉 dllimport 修饰附加包含目录....\include找到 zmq.h附加依赖项ws2_32.lib;iphlpapi.lib套接字与网卡枚举ZMQ_STATIC这个宏是最容易被忽略的。头文件里对函数声明做了条件修饰没定义时按 dllimport 处理静态链接阶段链接器会去找__imp_zmq_send这类带导入前缀的符号然后报 LNK2019 找不到外部符号。第一次踩这个坑的人往往会以为库编坏了其实是宏没定义。命令行编译的写法注意先切到 VS2008 自己的环境别在普通 cmd 窗口里直接调:: 先加载 VC9 的环境变量vsvars32.bat 在 VS2008 安装目录的 Common7\Tools 下 call %VS90COMNTOOLS%vsvars32.bat :: 进入源码的 msvc 目录按实际路径改 cd /d D:\src\libzmq\builds\msvc :: Release 配置编译/nologo 去掉版权横幅失败时看最后 20 行就够 vcbuild /nologo libzmq.vcproj Release|Win32vcbuild的第二个参数是配置|平台必须和工程里定义的配置名一字不差写成Release会提示找不到配置。编译时间比想象中长因为库里有几个大文件比如上下文、连接管理那几块中途没输出是正常的别急着 CtrlC。2.3 产物校验先写一个十行的探针别急着上业务代码拿到 .lib 之后不要直接往业务工程里塞。写一个最小的控制台程序只做两件事打印版本号创建一个上下文再销毁。这一步过了说明头文件、lib、CRT 三者是对齐的后面出问题就只会在业务逻辑层排查范围一下缩小一半。// probe.cpp —— 只为验证 libzmq 能不能链接、能不能跑 #include zmq.h #include stdio.h int main(void) { int major 0, minor 0, patch 0; zmq_version(major, minor, patch); // 版本号是三个 int 出参 printf(libzmq version: %d.%d.%d\n, major, minor, patch); void *ctx zmq_ctx_new(); // 3.x 起的上下文接口 if (!ctx) { printf(ctx create failed, errno%d\n, zmq_errno()); return 1; } printf(ctx ok, addr%p\n, ctx); zmq_ctx_destroy(ctx); return 0; }zmq_version的三个参数是出参传地址进去不用初始化也能被覆盖但我习惯置 0方便看出哪个字段没被写。zmq_ctx_new/zmq_ctx_destroy是 3.2 之后的名字如果你手上是更早的分支对应的是zmq_init/zmq_term语义一样混用会编译不过看到未声明的标识符先确认分支年代别怀疑库没编好。链接器里把libzmq.lib加进附加依赖项附加库目录指向产物所在文件夹。Debug 版和 Release 版建议用不同文件名比如加_d后缀工程里按_DEBUG宏自动切换省得某天手滑把 Debug 库链进发布版本然后在客户现场看到一个莫名其妙的断言框。3. 发布端与订阅端的最小实例C 代码逐行拆开看3.1 发布端绑定、分帧、控制节奏发布端的骨架非常短建上下文、建 PUB 套接字、绑端口、循环发。真正需要想清楚的是一条消息怎么组织。PUB/SUB 模式下订阅过滤是按消息的第一帧前缀做的所以惯例是把主题放第一帧、负载放第二帧用多帧消息发出去接收端就能按主题筛选不用自己解析字符串头。// publisher.cpp —— VS2008 / Win32 / 静态链接 libzmq #include zmq.h #include stdio.h #include string.h #include windows.h int main(void) { void *ctx zmq_ctx_new(); void *pub zmq_socket(ctx, ZMQ_PUB); if (!pub) { printf(socket failed: %s\n, zmq_strerror(zmq_errno())); return 1; } // 发送队列水位超过后 PUB 端直接丢弃不阻塞 int sndhwm 1000; zmq_setsockopt(pub, ZMQ_SNDHWM, sndhwm, sizeof(sndhwm)); // 绑到所有网卡现场多机采集时别只绑 127.0.0.1 if (zmq_bind(pub, tcp://*:5556) ! 0) { printf(bind failed: %s\n, zmq_strerror(zmq_errno())); zmq_close(pub); zmq_ctx_destroy(ctx); return 1; } int i; for (i 0; i 600; i) { char topic[32]; char body[128]; // VS2008 没有 snprintf用 _snprintf 并手动补结束符 _snprintf(topic, sizeof(topic) - 1, TICK.%s, EURUSD); topic[sizeof(topic) - 1] \0; _snprintf(body, sizeof(body) - 1, {\seq\:%d,\px\:%d}, i, 10800 i % 50); body[sizeof(body) - 1] \0; // 第一帧主题ZMQ_SNDMORE 表示后面还有一帧 zmq_send(pub, topic, strlen(topic), ZMQ_SNDMORE); // 第二帧负载不带标志位即整条消息结束 zmq_send(pub, body, strlen(body), 0); Sleep(100); // 10Hz先用慢速确认链路通再提速压测 } zmq_close(pub); zmq_ctx_destroy(ctx); // 必须在所有 socket 关闭之后调用 return 0; }逻辑上有三个点值得单独说。zmq_send的第三个参数是长度千万别用sizeof(topic)那样会把 32 字节连同后面的\0一起发出去订阅端拿到的字符串末尾带一串垃圾判断主题时永远匹配不上。第二ZMQ_SNDMORE只加在非末帧上末帧一定要传 0否则接收端会一直等下一帧表现为收到了第一帧但收不到完整消息。第三zmq_ctx_destroy必须在zmq_close之后顺序反了在某些分支上会直接卡住不返回看起来像程序挂死。ZMQ_SNDHWM这个水位参数在 PUB 端的含义和别人理解的不太一样它不是攒够 1000 条再发而是对某个订阅者的待发队列最多留 1000 条超了就丢最老的。所以调大它并不能解决丢消息只能延后丢的时间点。3.2 订阅端连接、注册过滤、循环收帧订阅端最容易翻车的地方是订阅过滤SUB 套接字默认不订阅任何东西一条消息都不会给你而且不报错。很多人zmq_connect写完就进循环然后对着空屏幕发呆一晚上。// subscriber.cpp —— VS2008 / Win32 #include zmq.h #include stdio.h #include string.h int main(void) { void *ctx zmq_ctx_new(); void *sub zmq_socket(ctx, ZMQ_SUB); if (!sub) { printf(socket failed\n); return 1; } int rcvhwm 1000; zmq_setsockopt(sub, ZMQ_RCVHWM, rcvhwm, sizeof(rcvhwm)); // 关键注册前缀。传空串 表示全收这里只收 TICK. 开头的 const char *filter TICK.; if (zmq_setsockopt(sub, ZMQ_SUBSCRIBE, filter, strlen(filter)) ! 0) { printf(subscribe failed: %s\n, zmq_strerror(zmq_errno())); return 1; } if (zmq_connect(sub, tcp://127.0.0.1:5556) ! 0) { printf(connect failed: %s\n, zmq_strerror(zmq_errno())); return 1; } while (1) { zmq_msg_t part; zmq_msg_init(part); // 阻塞收第一帧-1 表示出错用 zmq_errno 区分 EINTR int n zmq_msg_recv(part, sub, 0); if (n 0) { printf(recv failed: %s\n, zmq_strerror(zmq_errno())); zmq_msg_close(part); break; } printf([topic] %.*s\n, (int)zmq_msg_size(part), (char *)zmq_msg_data(part)); // 只要还有后续帧就继续收直到整条消息结束 while (zmq_msg_more(part)) { zmq_msg_close(part); zmq_msg_init(part); n zmq_msg_recv(part, sub, 0); if (n 0) break; printf([body ] %.*s\n, (int)zmq_msg_size(part), (char *)zmq_msg_data(part)); } zmq_msg_close(part); } zmq_close(sub); zmq_ctx_destroy(ctx); return 0; }%.*s这个写法是为了配合zmq_msg_sizeZeroMQ 收到的数据不保证以\0结尾直接printf(%s, data)有越界读的风险打印出来还可能带一串随机字符。多帧循环里每次都zmq_msg_close再zmq_msg_init漏掉 close 就是内存泄漏跑上几小时内存曲线一路向上。还有一点3.x 之后 SUB 端设置的过滤条件会作为订阅信息反向送到 PUB 端由发布端做匹配。这意味着过滤不是在本地做的订阅条件变更会有网络往返延迟。想在本地自己再过滤一遍也可以但那是额外一层别把它当成默认行为。3.3 联调先确认有没有再确认对不对两个进程分开跑。先启动订阅端再启动发布端——顺序其实不重要ZeroMQ 会自动重连但先起订阅端能让你在发布端一起来就看到数据心理上舒服些。发布端每 100ms 发一条订阅端应该稳定打印一 topic 一 body 两块。如果没有输出按这个顺序排查别乱猜发布端zmq_bind的返回值和zmq_strerror打印了什么端口被占用是最常见的失败原因。订阅端的zmq_setsockopt(ZMQ_SUBSCRIBE)有没有真的执行返回值是不是 0。过滤前缀和实际发出的主题是否严格前缀匹配TICK. 和 TICK 差一个点就是全不匹配。用netstat -ano | findstr 5556看端口有没有真正在监听防火墙有没有拦。把订阅前缀临时改成空串做全收验证如果这样能收到问题百分百出在前缀上。第 5 条是我最常用的手段能一刀把问题切成链路问题和过滤问题两半省掉大量瞎试。4. 订阅过滤、多帧边界与高频下的参数调法4.1 前缀匹配的机制决定了你不能按中间字段过滤SUB 端的过滤是前缀匹配不是包含、不是正则。想按 EURUSD 过滤主题第一帧就得是EURUSD开头如果主题写成TICK.EURUSD你只能订阅TICK.拿全量再到本地筛或者把主题设计成EURUSD.TICK让品种在前。这是设计阶段就该定下来的事代码写完了再改主题格式所有订阅端都得跟着改。常见做法是把主题设计成层级式用点分隔从粗到细市场.品种.类型。订阅方按自己需要的粒度取前缀粗粒度订阅市场.细粒度订阅市场.品种.。这样一套发布逻辑能服务多个不同粒度的订阅者不用为每个消费者单独开一路。前缀匹配还带来一个隐性成本订阅者数量多的时候发布端要为每个订阅者维护一份过滤表并逐条比对。订阅者上百、消息频率上千的时候这部分开销不可忽略。我一般会在压测时观察发布端的 CPU如果明显高于预期就把主题层级压平减少前缀长度。4.2 多帧消息的边界比字符串拼接可靠得多有人为了省事把主题和负载拼成一个字符串中间加个分隔符接收端再 split。这在负载本身含分隔符时会直接崩掉——JSON 里带个冒号再正常不过。多帧消息把边界交给协议层接收端用zmq_msg_more判断永远不会错位。// 发送端三个字段拆三帧帧边界即字段边界 zmq_send(pub, TICK, 4, ZMQ_SNDMORE); zmq_send(pub, EURUSD, 6, ZMQ_SNDMORE); zmq_send(pub, payload, payload_len, 0); // 末帧不带标志// 接收端按帧读读到 more 为 0 为止 int idx 0; do { zmq_msg_t f; zmq_msg_init(f); if (zmq_msg_recv(f, sub, 0) 0) { zmq_msg_close(f); break; } // 第 0 帧是主题第 1 帧是品种第 2 帧才是业务负载 handle_frame(idx, zmq_msg_data(f), zmq_msg_size(f)); int more zmq_msg_more(f); zmq_msg_close(f); if (!more) break; } while (1);这里要注意zmq_msg_more必须在zmq_msg_close之前调用close 之后消息句柄就失效了再去问还有没有后续帧是未定义行为。我见过有人把顺序写反在 Release 下能跑、Debug 下偶尔读到垃圾值典型的黑匣子问题。多帧消息还有一个特性整条消息是原子的。接收端要么拿到全部帧要么一帧都拿不到不会出现收到前两帧、第三帧丢了的情况。这个保证在传输大块数据时很有用但也意味着单条消息越大占用的内存越多别把几十兆的二进制塞进一条消息里。4.3 高频发布下的 HWM 与丢失参数只能缓解不能根治PUB/SUB 的默认行为是订阅者跟不上发布端就丢。这不是 bug是设计取舍——广播场景下为了一个慢消费者拖住所有人不划算。理解这一点参数调起来才有方向。参数作用端默认量级调大的后果调小的后果ZMQ_SNDHWM发布端1000 条内存上涨断线后堆积更多更容易丢但内存平稳ZMQ_RCVHWM订阅端1000 条突发流量能缓冲住处理慢就丢ZMQ_LINGER两端不设则阻塞关闭时等对端可能卡住设 0 立即丢弃未发数据我在采集程序里的做法是发布端 SNDHWM 设 2000订阅端 RCVHWM 设 5000ZMQ_LINGER显式设 0。理由分别是——发布端不需要堆太多丢了对业务影响可控订阅端处理有抖动多留点缓冲linger 设 0 是为了让程序退出时干脆利落不会因为对端没响应卡在zmq_ctx_destroy里。int linger 0; zmq_setsockopt(pub, ZMQ_LINGER, linger, sizeof(linger));这个三行设置救过我一次现场程序需要定时重启没设 linger 时偶尔卡在退出阶段运维只能强杀进程设成 0 之后再没出现过。5. 避坑与排查VS2008 ZeroMQ 联调里最常见的五个翻车现场5.1 现象链接报 LNK2019找不到__imp_zmq_send原因静态库工程编出来了但宿主工程没定义ZMQ_STATIC头文件按动态库方式声明函数链接器去找带__imp_前缀的导入符号静态库里当然没有。解决宿主工程的预处理器定义里加上ZMQ_STATIC清理后重新生成。别只改一个配置Debug 和 Release 都要加VS2008 的配置是分开存的。5.2 现象LNK2005 一堆 CRT 函数重复定义原因库用 /MT 编的宿主工程用的 /MD或者反过来也可能是 Debug 工程链了 Release 库。解决打开库工程的代码生成页看一眼运行时库和宿主工程逐字对齐。Debug 对 Debug/MTd 对 /MTdRelease 对 Release。库和宿主分属不同人维护时这条几乎必踩。5.3 现象订阅端一条消息都收不到也不报错原因三种可能按概率排序——没调zmq_setsockopt(ZMQ_SUBSCRIBE)过滤前缀和实际主题不匹配发布端根本没绑成功返回值被忽略了。解决先把订阅前缀改成空串验证链路能收到就是前缀问题再检查zmq_setsockopt的返回值最后看发布端zmq_bind的错误码端口占用会返回EADDRINUSE。5.4 现象程序退出时卡死任务管理器才能杀掉原因zmq_ctx_destroy在还有 socket 没关闭时被调用或者 linger 默认值让上下文一直等未发完的数据。解决严格按zmq_close→zmq_ctx_destroy的顺序并且给每个 socket 显式设ZMQ_LINGER 0。多线程场景下确保所有工作线程都退出了再销毁上下文。5.5 现象本机能收另一台机器收不到原因发布端绑的是tcp://127.0.0.1:5556只监听回环口或者现场机器的防火墙拦了入站。解决绑tcp://*:5556监听所有网卡然后在本机用netstat -ano确认监听地址是0.0.0.0。防火墙这条没得绕得让现场把端口放行测试阶段可以临时关掉验证。6. 让订阅端稳住的进阶手法慢消费者检测与优雅退出跑通之后真正让人睡不着的是运行几小时后订阅端悄悄不更新了。PUB/SUB 没有心跳发布端不知道订阅端是死了还是只是慢订阅端也不知道发布端还在不在。我的做法是在业务层加一条带时间戳的心跳主题比如SYS.HB每秒发一次订阅端超过三秒没收到就主动重连。// 订阅端用一个非阻塞 recv 加超时判断避免心跳线程干扰主循环 int timeout 500; // 毫秒 zmq_setsockopt(sub, ZMQ_RCVTIMEO, timeout, sizeof(timeout)); // 主循环里区分超时和真错误 int n zmq_msg_recv(part, sub, 0); if (n 0) { if (zmq_errno() EAGAIN) { // 500ms 没数据累计超过 3 秒就认为链路异常 if (idle_ticks 6) { reconnect(sub); idle_ticks 0; } continue; } // 其它错误才真的退出 }ZMQ_RCVTIMEO设上之后zmq_msg_recv从阻塞变成带超时返回超时错误码是EAGAINWindows 上叫WSAEWOULDBLOCK的场景在 ZeroMQ 这层被统一成了EAGAIN直接用zmq_errno()判断即可别去比对WSAGetLastError。这个改动让订阅端从被动等变成主动探链路断了能自己恢复不用人工重启。收尾阶段还有一个我踩过的坑多个线程共用一个上下文、各自持有 socket 时退出顺序必须是从工作线程往主线程收。我当时的写法是主线程直接zmq_ctx_destroy工作线程还在zmq_msg_recv上阻塞结果进程卡住不退出现场只能强杀。后来改成给每个工作线程设一个原子退出标志、配合ZMQ_RCVTIMEO让其自然醒来主线程 join 完所有线程再销毁上下文问题消失。从那以后我每次接这类老工程都会先写一个十行的版本探针程序把库验通再往上堆业务逻辑绝不跳过这一步。老工具链上的问题从来不是难是藏得深、报得少先把地基验一遍后面能省掉大半天。希望帮到你。本文还有配套的精品资源点击获取