getzmqnotifications如何检查订阅？

Bitcoin Core已经配置ZMQ发布地址，消费者进程也显示在线，但索引仍少了一个区块。问题在于“配置存在”“TCP或IPC可连”“消息没有丢”“业务已处理”是四个层级。getzmqnotifications只直接回答第一层，却能为后续核对提供运行时基线。

先把type、address和hwm做成配置快照

getzmqnotifications返回已启用通知的数组，每项包含type、address和hwm。

对返回数组排序后保存，不依赖启动参数的人工抄录。type对应通知主题，address是发布端看到的端点，hwm是出站消息高水位。若期望类型不在数组中，先修复节点配置和重启流程；此时继续调消费者没有意义。

address描述发布端点，hwm是出站消息高水位；配置存在不证明订阅者已连接或消费及时。

高水位约束发送侧排队，慢消费者、网络抖动和处理暂停都可能让消息无法按预期送达。具体行为还受libzmq和socket配置影响。监控记录hwm，但不把它换算成“可容忍N秒停机”，除非在本环境测得消息速率与行为。

增大hwm会增加缓冲，却不能替代持久队列，也可能把问题推迟到内存压力阶段。容量调整必须和消费者吞吐、峰值事件率、故障恢复目标一起压测。

Bitcoin Core可发布rawblock、rawtx、hashblock、hashtx和sequence等通知，类型和启动参数应逐项匹配。

hashblock与hashtx提供哈希，rawblock与rawtx携带原始对象，sequence适合跟踪内存池与链事件序列。消费者订阅哪些主题取决于用途：只要区块提示就不必传完整原始交易；需要精确重放时，也不能只依赖一个缺少持久性的实时主题。

升级Bitcoin Core前比较支持的通知、消息帧和序列语义。解析器对未知类型显式告警，而不是错误套用旧结构。所有业务事件以network、节点、topic和接收时点建立主键上下文。

ZMQ通知不是持久消息队列，消费者断线或落后时应由RPC或本地索引补洞，不能假设自动重放。

ZMQ通知不是具备消费位点和持久日志的消息系统。进程退出、订阅建立过晚或处理速度不足时，中间消息可能不可恢复。消费者需要保存最后处理的区块哈希、高度或sequence，并在重连后从Bitcoin Core RPC核对链头与缺失范围。

回补按区块和交易的业务主键幂等写入。实时消息与回补任务可能同时到达，同一对象只能产生一次最终状态变更；链重组又要求已确认状态可以撤回和重放。简单的“见过hash就永不处理”会在重组中出错。

在测试节点记录正常事件率，然后暂停消费者或限制处理速度，让缓冲接近压力区；恢复后比较接收序列、节点链头、索引数据库和RPC回补结果。演练目标不是证明永不丢消息，而是证明系统能发现缺口并收敛到正确状态。

同时测试节点重启、消费者先启动、消费者后启动和地址不可达。每种情形记录告警触发时间、回补区间、重复消息数和最终一致时长。没有隔离环境时，不在生产链路故意制造拥塞。

节点返回的是发布者配置的地址。容器内127.0.0.1、IPC路径或内部主机名对另一个容器未必可达。通过网络拓扑和挂载证明消费者实际访问同一端点，不要看到字符串相等就结束检查。跨主机暴露时再评估加密、访问控制和防火墙，因为ZMQ端点本身不是公开API认证方案。

最终看板同时显示配置快照、消费者连接、最后事件时间、最后区块高度、与节点链头的差距、序列缺口和回补任务状态。这样值班人员能判断该修配置、网络、消费性能还是索引一致性。

ZMQ负责低延迟事件，RPC或本地索引负责重放和核对。只要消费者无法证明序列连续，就把区间标为待回补；不要让一条绿色连接状态掩盖静默缺口。

资料访问时间为2026-08-07。当前仍需按部署核验：网络缓冲、libzmq版本和消费者处理能力决定具体丢包阈值，文章不提供通用hwm数值。

相关站内主题：getnetworkinfo、waitfornewblock、getnettotals。本文用于技术教育与节点运维参考，不构成投资、收益或资产安全承诺。