轮询之痛：外部软件怎么知道”有新块了”
Bitcoin Core 的设计是它愿意从外部网络接收数据、维护账本、响应 RPC 查询，但对”发生了什么”这件事，它长期只支持一种模式：外面的人不断来问。收单服务、区块浏览器后端、对账脚本为了知道一笔交易进没进块，只能定时轮询 RPC，间隔短了浪费资源，间隔长了延迟难看。ZMQ 功能就是为补上这块拼图而加进来的：让节点在新区块到达、新交易进入内存池等事件发生时，主动向订阅者推送一条消息。
它推送什么、不承诺什么
官方文档把边界写得很清楚：这是一个发布通知，不是认证过的协议。ZMQ 通道上没有身份验证，也没有双向握手，节点把自己本地视角的事件原样发出去，就完事了。文档明确建议订阅者把收到的数据当作未经确认的线索——可能过期、可能不完整、甚至可能无效，收到之后要自己回查核验。换句话说，ZMQ 适合当”门铃”，不适合当”公证”。推送里带的是原始区块或原始交易的序列化数据，收到后仍需通过本地校验逻辑才能入库。
典型接法与配置思路
节点侧通过启动参数打开不同的发布端点，分别对应原始区块、原始交易等几类数据流；外部程序用任意 ZeroMQ 客户端库订阅这些 TCP 端点即可。最常见的生产形态是”一台受信全节点 + 一堆消费者进程”：节点只在本机或内网暴露端点，索引器、商户后台、监控脚本各取所需，全部从事件驱动出发，替代低效的轮询。getzmqnotifications RPC 可以查看当前节点实际开启了哪些发布端点，部署完成后先跑一遍这个命令确认配置生效，是省时的自检习惯。
风险清单：谁在听、信不信、丢了怎么办
三个问题必须提前想清楚。第一是暴露面：ZMQ 端点一旦监听在可达网络上，等于向对方持续播报你的节点看到了哪些交易和区块，虽然信息本来就是网络公开信息，但时序信息会泄露你的网络行为，默认只应绑定回环地址或可信内网。第二是信任模型：订阅者无法验证发布进程没被篡改，所以凡是涉及资金决策的数据，都要回到节点 RPC 或本地账本复核，不能拿推送内容直接记账。第三是可靠性：ZeroMQ 的发布订阅模式在订阅者掉线期间的消息不会补发，重启后的消费者必须自己做一次全量对账，把断档期间漏掉的事件补回来，否则账本会静默地落后。
什么时候不值得开
个人钱包用户、低频查询的研究场景，直接用 RPC 轮询完全够，开 ZMQ 只会增加暴露面和维护成本。真正适合它的是每秒在意多笔状态变化的服务侧进程。把 ZMQ 理解为”节点到自家后院的专线门铃”，而不是”比特币网络的订阅服务”，就基本不会用错。
一次最小可运行的验证回路
上手 ZMQ 最省事的验证方法是双终端实验：一个终端跑 bitcoin-cli -zmqpubrawblock=tcp://127.0.0.1:28332 -zmqpubrawtx=tcp://127.0.0.1:28333 启动节点（测试网更省资源），另一个终端用任意语言的 ZeroMQ 订阅库连上端点，然后在第一个终端用 sendtoaddress 向自己的地址发一笔小额测试交易，观察订阅端是否在几秒内收到 rawtx 消息、进块后是否收到 rawblock 消息。这个回路能一次性确认三件事：端点配置生效、事件与你预期的时序一致、序列化数据的长度字段解析正确。跑通之后再谈接进生产脚本。另外提醒一个容易踩的坑：rawblock 与 hashblock 两类主题的数据体积相差几个数量级，订阅区块的消费者若按 hash 主题编写却订阅了 raw 主题，内存与带宽都会瞬间失控——主题选型要跟着用途走，而不是照抄别人的配置。
风险提示：本文仅为节点软件功能说明，不构成投资建议；配置任何对外端口前请评估网络暴露风险。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。