我来帮你捋清楚这个问题——你遇到的高水位标记（HWM）不生效的情况，其实是ZMQ使用中很容易踩的一个细节坑，结合你的代码和场景，咱们一步步解决：

核心问题：HWM设置时机错误 #

ZMQ的绝大多数socket选项（包括HWM）必须在socket执行bind()或connect()之前设置，否则设置不会生效。你的代码里是先绑定/连接，再设置HWM，这直接导致配置被忽略了。

修正后的代码示例 #

发布端（修正HWM设置顺序）

import zmq
import time
port = "5556"
context = zmq.Context()
socket = context.socket(zmq.PUB)

# 关键：先设置socket选项，再执行bind
socket.setsockopt(zmq.SNDHWM, 10)
# 可选：禁用操作系统缓冲区，让ZMQ完全接管缓冲区管理
socket.setsockopt(zmq.SNDBUF, 0)

socket.bind("tcp://*:%s" % port)
while True:
    data = int(time.time())
    print(data)
    socket.send(str(data).encode('utf-8'))  # Python3建议显式编码为bytes
    time.sleep(1)

订阅端（修正HWM设置顺序+Python3兼容）

import zmq
import time
port = "5556"
context = zmq.Context()
socket = context.socket(zmq.SUB)

# 关键：先设置选项，再执行connect
socket.setsockopt(zmq.SUBSCRIBE, b'')  # Python3需传入bytes类型的订阅前缀
socket.setsockopt(zmq.RCVHWM, 10)
# 可选：禁用操作系统缓冲区
socket.setsockopt(zmq.RCVBUF, 0)

socket.connect("tcp://localhost:%s" % port)
while True:
    time.sleep(2)
    data = socket.recv().decode('utf-8')
    print(data)

额外补充说明 #

1. Pub/Sub模式下的HWM逻辑

   • 发布端的SNDHWM是针对每个订阅者连接的队列上限，也就是说每个订阅者的消息队列最多保留10条最新消息
   • 订阅端的RCVHWM是自身接收队列的上限，当队列满时，ZMQ会自动丢弃旧消息，只保留最新的条目，这样就不会收到积压的旧数据了

2. 为什么要禁用操作系统缓冲区？
   操作系统本身会有一层socket缓冲区，如果不设置SNDBUF/RCVBUF为0，可能会和ZMQ的HWM逻辑冲突，导致实际缓冲区大小超出预期。禁用后让ZMQ完全管理缓冲区，能保证HWM设置的准确性。

3. Python3的字节编码注意事项
   ZMQ在Python3中要求发送/接收的是bytes类型，所以代码里我加了encode和decode操作，避免潜在的类型错误。

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