多台 LND 共用一本账：集群模式、etcd 选主与 90 秒会话

一台机器一个账本，是嵌入式设计给的天花板

LND 默认把通道状态、路由记账这些关键数据写进嵌入式数据库 bbolt，官方文档对这套方式的定性是：从手机端到大节点各种环境都久经考验。但嵌入式存储的账本天然属于一台机器——想热迁移、想在机房故障时快速接管、想做不停机更新，就得先把状态搬出去。v0.19.0-beta 的官方文档 docs/leader_election.md 给出的答案是把关键状态放进 etcd 这份复制型存储，然后让多台 LND 组成一个集群，靠选主协议决定谁有读写权。

选主：只有一个实例碰得到账本

文档对运行模型的表述很直白：多台机器上各跑一个 LND 进程，其中只有当选的 leader 能读取和修改数据库；leader 宕机或被下线，follower 中的某一个会被选为新 leader 并迅速接管，把停机时间压到最短。选举本身也依赖 etcd——同一个 etcd 集群既当存储又当裁判，这是这套方案的简化前提，文档明确写了当前选主功能依赖 etcd 工作。

编译、启动与参数账本

这套功能不在默认二进制里。文档给的编译命令是 make tags="kvdb_etcd"；运行侧先要把存储换掉：db.backend 设为 etcd，配 db.etcd.host、证书与私钥路径等连接参数。选主参数集中在 cluster 段：--cluster.enable-leader-election 打开选主；--cluster.leader-elector 目前唯一合法值是 etcd；--cluster.etcd-election-prefix 决定选举键前缀，源码 lncfg/cluster.go 里的默认值是 /leader/；--cluster.id 是这台实例在集群里的身份标识，默认取主机名；--cluster.leader-session-ttl 以秒为单位规定 leader 会话的续租时限，源码默认 90。文档还附了一份本地测试用 etcd 启动参数，把 max-txn-ops 抬到 16384、max-request-bytes 抬到 104857600，并特意注明这两个大数值是当前建议、未来未必必要——照抄前先看你自己的 etcd 版本。

部署时真正要过问的几件事

配置面里有几处细节不能含糊：--cluster.id 默认取主机名，而主机名在克隆出来的虚拟机镜像里是成批重名的，标识唯一这条纪律要靠命名规范兜住；选举前缀是独立命名空间，两套业务节点若误共用同一个前缀，会互相踩对方的锁；etcd 的连接参数是分散的——地址、证书、私钥各占一格，从测试切到生产要整套搬参数而不是换一个连接串，部署模板要一次性覆盖全。这些都不是协议问题，而是多挂一套分布式协调组件的固有运维成本，也是”高可用”账单上最容易被漏写的部分。

高可用的账，不是白算的

第一，leader 唯一意味着其余实例在待机，资源不是零成本；failover 的时间尺度受 session TTL 与 etcd 健康检查支配，90 秒的默认续租不是毫秒级切换。第二，存储从本地文件变成需要 TLS、鉴权、备份的分布式服务，etcd 本身怎么高可用又成了新的运维课题——裁判挂了，选手再健康也开不了赛。第三，bbolt 时代的备份直觉要重造：数据在 etcd 里，备份策略、版本回滚、容量规划都跟着 etcd 走；同时通道静态备份依旧是独立的逃生绳，两者不能互相替代。第四，同一集群里所有实例必须指向同一份链后端与钱包语义，错接成两套账比不集群更糟。

什么人值得上

文档描绘的受益者是规模化运营场景：需要频繁维护、对可用性敏感、愿意为自动化付出运维成本的节点。个人跑一两条通道，嵌入式 bbolt 加定期备份的朴素组合，往往比一套三节点 etcd 更不容易出事。上集群前先把监控、告警、演练脚本补齐，比先把副本数堆上去更重要。另留意文档给出的边界：选主目前依赖 etcd 这一种选举器，眼下没有替换件，对别家强一致存储有偏好的团队只能再等版本演进。

风险提示：本文以 LND v0.19.0-beta 源码与发布文档为准，集群参数与依赖建议随版本演进，部署前请核对你所用版本的一手文档；节点故障与切换处理不当可能造成资金占用或通道损失，本文不构成任何投资建议。