savemempool怎样保存内存池？

节点维护前，人们常把savemempool理解成“保存所有待确认交易”。这个说法少了三个限定：保存的是本节点此刻接受的交易集合；写入的是本地持久化文件；下次启动仍要重新加载并按当前环境继续处理。它是一项恢复优化，不是链上承诺。

先画出四个状态，而不是只看一次成功

savemempool把当前mempool转储到磁盘，并返回实际保存文件的filename。

正确的状态机包括运行中内存池、正在写盘、节点启动加载、加载后重新核验。RPC返回filename时，只能把“写盘动作完成”标为成功。随后还要确认文件位于预期数据目录或容器卷、修改时间合理，并在重启后观察loaded。

运行中样本 → savemempool → 文件落盘
                         ↓
节点重启   → 加载进行中 → loaded=true → 重新抽查交易

如果运维平台把HTTP 200直接翻译为“内存池已恢复”，它会跳过最容易出问题的两个阶段：文件是否真正落在持久卷，以及启动时是否已完成加载。

如果上一次内存池转储尚未完全加载，savemempool会失败，不能把失败重试写成无条件循环。

这类失败不是增加重试频率就能解决。节点正在读取旧快照时又要求写新快照，正确处置是记录错误、观察加载状态、检查启动日志和资源压力；只有状态稳定后才重新发起。紧密循环会制造更多RPC负载，也会掩盖真正的磁盘或启动问题。

getmempoolinfo的loaded字段用于判断mempool是否已从磁盘完成加载。

采集器应保存loaded、size、bytes、usage、mempoolminfee和节点启动标识。重启前后对比时，不要要求交易数量完全相等：写盘到停机之间可能继续收到交易，启动加载后也可能因确认、冲突或策略变化移除条目。重点是解释差异，而不是追求看起来漂亮的相等。

抽样至少覆盖三类交易：本钱包刚广播的交易、带未确认父交易的包、接近节点最低费率的交易。对每笔保存txid和getmempoolentry结果；若启动后找不到，再依次检查是否已确认、被替换、父交易缺失或不再符合策略。

filename是节点进程看到的路径，不一定等于宿主机路径。Docker或其他容器环境中，要从挂载配置证明该目录映射到持久卷；仅进入容器看到文件存在，无法证明容器重建后仍保留。验收可以在测试实例执行一次受控重建，随后重新核对loaded与抽样交易。

不要在运行节点时直接复制正在变化的数据目录作为一致性备份。mempool.dat本身也不是钱包备份、区块数据库备份或灾难恢复的全部。节点配置、钱包文件、索引和底层卷需要各自的恢复方案。

mempool.dat是节点本地策略视图的快照，落盘不等于交易已确认，也不保证重启后每笔交易仍符合当时策略。

内存池取决于节点的连接、策略和观察时点。另一台节点可能没有同一笔交易，矿工也没有义务按照你的本地快照选包。对用户展示时应把“本地节点仍可见”“已广播到多个节点”“已进入区块”“达到确认门槛”拆成不同标签。

如果维护窗口较长，恢复后还要复查链高度、网络、最低中继费和交易确认状态。盲目重新广播所有快照交易可能制造重复日志或替换冲突；应根据原始签名交易和nonce逐笔判断。

记录节点版本、链、数据目录、转储开始与完成时间、filename、文件元数据、重启时点、loaded变为true的时点、前后内存池摘要和抽样交易结果。发生失败时保留原始RPC错误，不要只写“保存失败”。第二位运维人员仅凭这份记录，也应能判断问题位于写盘、持久卷、启动加载还是交易状态变化。

把返回文件、loaded状态、重启前后样本和节点版本放进同一份变更记录。只要交易尚未进入规范链，就仍应按未确认交易管理，不能因为快照落盘而降低风控。

资料访问时间为2026-08-07。当前仍需按部署核验：文件原子替换、数据目录备份和容器卷策略取决于部署环境，文章不承诺跨版本直接复制mempool.dat。

相关站内主题：内存池祖先与后代、getmempoolinfo、getmempoolentry。本文用于技术教育与节点运维参考，不构成投资、收益或资产安全承诺。