ZeroMQ PUB/SUB模式基于TCP传输层的异常行为排查咨询

我明白你现在的处境：用Protobuf v3定义了TcpGraphes消息，还把它拆成多部分消息来实现客户端过滤，但在基于TCP传输层的ZeroMQ PUB/SUB模式下碰到了异常行为。下面是几个可以优先排查的方向和常见问题的解决思路：

1. 多部分消息的PUB/SUB过滤逻辑验证 #

ZeroMQ的PUB/SUB过滤是基于前缀匹配的，默认情况下过滤逻辑在SUB端实现（如果没用到XPUB/XSUB代理的话）。你需要确认：

• 多部分消息的第一帧是不是你设定的过滤前缀，SUB端有没有正确订阅这个前缀
• 注意：SUB端默认是接收所有消息的，如果你手动设置了订阅前缀，一定要保证前缀的编码和PUB端发送的第一帧编码完全一致（比如UTF-8编码的字符串和原始字节流的区别）

2. Protobuf序列化/反序列化一致性检查 #

用Protobuf很容易出现两端配置不一致的问题，这会直接导致消息解析失败：

• 检查两端是不是都用了Protobuf v3，有没有混用v2的语法或者库版本
• 确认repeated字段的序列化格式：Protobuf默认是打包（packed）格式，但如果一端开启了打包、另一端没开，就会出现解析错误
• 可以用Protobuf自带的工具验证传输的字节流：把收到的消息字节流保存到文件，然后用下面的命令解码，看看结构是否符合预期：

  protoc --decode_raw < tcp_graphes.bin
  

3. ZeroMQ TCP传输层的配置与稳定性排查 #

ZeroMQ的TCP模式有几个容易踩的坑：

• 高吞吐量下的消息丢失：你的TcpGraphes里每个repeated字段最多有3600个元素，单条消息可能不小。要检查PUB端的ZMQ_SNDHWM和SUB端的ZMQ_RCVHWM设置，默认的高水位线可能扛不住大流量，会导致消息被丢弃
• TCP连接稳定性：用tcpdump或者Wireshark抓包，看看TCP连接有没有异常断开、重传或者延迟的情况——底层TCP不稳定的话，ZeroMQ很可能出现消息乱序或丢失
• 多部分消息的边界标记：ZeroMQ的多部分消息是靠ZMQ_SNDMORE标志来区分的，PUB端发送时，除了最后一帧，其他所有帧都要设置这个标志。如果标志设错了，SUB端会把多部分消息当成单条消息解析，直接导致Protobuf解析失败

4. 客户端过滤逻辑的实现问题 #

你提到用多部分消息实现客户端过滤，这里可能的问题点：

• 如果是用XPUB/XSUB代理在PUB端做过滤，要确保代理正确转发订阅请求，没有误过滤应该发送的消息
• 如果是在SUB端做过滤，要先判断第一帧的过滤前缀，再决定是否接收后续的Protobuf消息帧，避免做无用的解析工作

内容的提问来源于stack exchange，提问作者dchagniot