钱包节点热备切换时的会话保持方案，核心思路是在切换前完成状态同步，切换时通过VIP漂移和连接级会话保持让客户端无感，切换后靠业务层重试兜底，三者缺一不可。很多团队做热备只盯着主备节点的数据一致性，结果切换一发生，客户端全部掉线，交易直接中断，真正的会话保持，要在网络层、节点状态、业务逻辑三个层面同时设计。
为什么你的钱包节点热备切换总会断线
先搞清楚问题出在哪,钱包节点和普通Web服务不一样，它维护的不只是HTTP连接，还有长连接、交易上下文、甚至内存里的UTXO缓存，热备切换时，客户端感知的断线通常来自三个层面。
TCP连接被重置
主节点宕机，备节点接管IP，但原本建立在主节点上的TCP连接早就没了，客户端发下一笔交易时，发现连接无响应，然后报错，这个问题的本质是备节点无法继承主节点的连接状态，业内专家指出，解决思路不是强行复制连接，而是让客户端在切换后快速重连，重连逻辑要足够平滑。
节点内部状态不一致
钱包节点维护着区块头缓存、交易内存池、甚至HD钱包的派生索引，主节点挂了，备节点如果只同步了区块数据，没同步内存池和会话token，切换后客户端带着旧token来请求，备节点根本不认，这类问题比TCP断连更隐蔽，排查起来也更费劲。
客户端没有重试机制
很多自研钱包客户端压根没写重试逻辑，连接断了就直接抛异常给用户，钱包节点热备切换时，不管方案多完美，几十毫秒的切换窗口一定存在，客户端不重试，会话保持就是空谈。
钱包节点热备切换方案的技术选型对比
针对上面的问题,主流的方案有三类，各有各的适用场景，钱包节点高可用部署到底怎么选，得看你的业务规模和容错要求。
Keepalived做VIP漂移
这是最基础的做法，主备节点通过VRRP协议共享一个虚拟IP，主节点挂了，备节点自动接管IP，优点是配置简单，秒级切换，对客户端基本透明，缺点是只解决IP层面的漂移，节点内部状态同步得靠上层自己做，适合小规模钱包服务，或者对交易连续性要求不高的场景。
连接级会话保持
在VIP漂移的基础上，引入连接代理层，客户端先连代理，代理再转发到真实节点，主节点故障时，代理维持与客户端的连接不动，只把后端连接切到备节点，这个方案技术上最优雅，能真正实现客户端无感切换，但代价是引入额外组件，代理层本身也要做高可用，不然代理挂了照样全挂。
无状态化改造
把钱包节点的会话信息全部外置，比如存Redis或者数据库，节点本身不保存任何会话状态，客户端请求带完整上下文，任意节点都能处理，这是最彻底的方案，切换时直接换节点，根本不需要会话保持，但对钱包这类低延迟高吞吐的业务来说，外置存储会引入额外时延，得权衡。
| 方案 | 切换时间 | 客户端感知 | 运维复杂度 | 适用场景 |
|---|---|---|---|---|
| VIP漂移 | 秒级 | 明显感知 | 低 | 小规模、可容忍短暂中断 |
| 连接级会话保持 | 毫秒级 | 基本无感 | 高 | 中大规模、交易频繁 |
| 无状态化改造 | 即时 | 完全无感 | 极高 | 高并发、分布式架构 |
会话状态同步是热备切换成功的关键
不管你选哪套方案,会话状态同步逃不掉，钱包节点的会话状态主要分三块，每一块都要单独处理。
交易上下文同步
客户端发起的交易，可能已经进入签名流程，或者已经广播到网络，主节点挂了，这笔交易的状态丢了，备节点不知道这笔交易是否已经处理过，实际做法是，主节点每收到一笔交易，立刻把交易哈希和原始报文同步给备节点，备节点存到本地队列，切换后先处理队列里的交易，再处理新请求，这样做的代价是性能损耗，一般控制在百分之五以内，近年来，不少钱包服务商为了省这点性能，直接用共享存储层来解决。
内存池和区块缓存同步
这点容易被忽略，钱包节点内存里缓存了最近几百个区块的头部信息，以及未确认交易的内存池，切换后如果备节点没有这些数据，客户端查询余额或交易状态，备节点得重新扫链，响应速度会慢好几拍，实践里的做法是在主节点内存数据变更时，做一次增量快照同步到备节点，快照间隔通常设为500毫秒，这里有一个度的问题，间隔太短性能开销大，间隔太长切换丢数据。
客户端会话Token的处理
钱包客户端一般会带着JWT或session标识来调用节点接口，主节点签发的token，备节点得能验证，最简单的方案是备节点共享同一把密钥，token本身无状态，验证一下签名就行，如果token方案不行，就得做会话存储同步，把会话记录实时复制到备节点，行业共识认为，能用无状态token就别做有状态会话同步，省掉一堆麻烦。
客户端会话保持的具体实现路径
会话保持不只是节点侧的事,客户端配合也必不可少，你在部署钱包节点热备切换的时候，客户端也得做针对性改造。
连接池的自动重连机制
节点切换导致IP漂移或连接断开，客户端必须能感知并自动重连，以Java客户端为例，用okhttp或者netty，要配置连接失败自动重试的拦截器，重试次数建议设为至少三次，间隔递增大约在200毫秒到2秒之间，重连时要重新发起握手，钱包协议如果有版本号，得确保重连时带上最新版本。
请求幂等设计
连接断开后重试，最怕的是同一笔交易被提交两次，钱包客户端发送交易请求时，要给每个请求生成全局唯一的requestId，节点处理完把requestId存起来，重试时带上同一个requestId，节点查重，重复请求直接返回上一次的结果，这个机制还能顺带解决热备切换时交易状态丢失的问题，切换后的钱包节点高可用配置里，做幂等是基本功，不做幂等的重试就是埋雷。
延迟切换策略
因为主备节点状态同步存在时间差，直接切换会导致部分数据丢失，实践里，备节点接管前会先等一个同步确认，确保主备两边状态差距在可接受范围内，具体操作是主备之间记录各自的最新同步点，备节点在切换时，先追平同步点，再对外提供服务，钱包节点双机热备的切换时间本来就该包含这个等待过程，不追求零宕机，更应追求零误判。
热备切换失败的常见场景和排查路径
方案做得再完善,真到切换的时候还是可能翻车，根据实际运维经验，钱包节点热备切换时的会话保持坑主要在下面几个地方。
VIP漂移成功，但新节点未就绪
这是最常见的坑，VIP切过去了，但备节点还在做状态恢复，端口都还没监听，客户端连接直接拒绝，解决方法是给备节点加就绪检查，端口监听、状态同步追平都完成之后，才允许VIP漂移，配合健康检查脚本，探测备节点的实际服务状态，而不是只看进程在不在。
会话同步机制拖慢了主节点
同步交易上下文和内存池的时间，如果卡在交易处理链路里，对主节点的延迟影响会比较明显，遇到这种情况，可以把同步改成异步队列方式，不让同步逻辑阻塞主流程，再就是压缩同步数据的体积，只同步必要字段，别一整套对象序列化扔过去，钱包钱包节点宕机无感切换这个需求，逼着团队去优化同步协议，这是好事，性能往往就是这么磨出来的。
客户端缓存了旧节点地址
有些钱包客户端做了DNS缓存，或者干脆写死了节点IP，VIP漂移改了映射关系，客户端还是往老IP发请求，这就要在客户端侧解决，轮询节点地址列表，检测到连接失败就切换下一个地址，服务端这边，确保所有节点都能通过同一个入口访问，别让客户端感知到后端换了机器。
钱包节点热备切换的日常演练要点
方案不是写出来就完事了,得靠演练验证，钱包节点双机热备切换测试要常态化，建议每季度至少做一次主动切换演练。
- 演练前记录当前节点的连接数、内存使用量、交易处理延迟
- 手动杀掉主节点进程,观察备节点接管耗时和客户端重连情况
- 演练期间让测试客户端持续发交易,验证交易不中断或中断在可接受范围
- 切换完成后检查交易记录完整性,确认没有丢单和重复入账
- 回切操作同样要演练,反向切换的坑往往和正向不一样
钱包节点热备切换时的会话保持,本质上就是让故障切换对用户不可见，VIP漂移只是入场券，状态同步是安全网，客户端重试是兜底，三层都做实了，切换才算稳。
Q&A：钱包节点热备切换的常见问题
热备切换时未确认的交易会丢吗
未确认交易存在内存池里,如果主节点没有实时同步内存池，切换后这些交易就会丢失，解决方法是主节点每收到一笔新交易就立即同步给备节点，备节点接管后先把这些交易重新广播到网络，如果连这个同步都没做，那未确认交易只能等客户端重新发起，钱包节点热备切换时的会话保持也就没那么完整了，采用异步同步加上客户端重试机制，大多数情况下未确认交易都能恢复。
备节点接管后，原有客户端连接如何处理
核心思路是尽量在客户端侧实现透明重连，而不是试图保留旧连接，TCP状态在节点切换时已经失效，强行保持没有意义，正确路线是客户端检测连接失败，自动重新建立连接到新节点，同时带上最新的会话token和requestId，这里的关键在于客户端重连逻辑的完善度，而不是服务端对旧连接的兼容。
怎么判断会话保持方案是否达标
唯一标准是切换期间业务是否连续，实际操作中，用交易成功率来度量，在切换前后各统计五分钟，对比交易成功率变化，切换窗口内成功率不能低于99.9%，否则会影响用户体验，达到这个标准，说明状态同步、VIP漂移、客户端重试三个层面都配合到位了，整个方案才算真正过关。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/644987.html
