Sanquan · HA Decision Brief

“备用服务器自动接管”不是做不到，
是当前方案还没闭环

给项目负责人、研发、交付和客户基础设施人员的统一判断与今日回复口径。

待共同确认　更新时间：2026-07-22 16:49 +0800　·　未实施、未验收

先给结论

客户的理解是对的两台应用服务器的目标应是任一台故障后，另一台自动承接业务。技术上可以做，但必须按端到端链路完成。
当前还不能这样承诺现方案仍把本地文件和部分定时任务固定在 App01，只能算“部分自动切换”，不能算“全功能立刻接管”。

差的不是一台机器，而是两种共享状态

链路当前状态要补的闭环
入口与普通 HTTP已按双节点设计业务健康检查、超时、重试、双向故障演练
MySQL / Redis / EMQX已有独立 HA 方案完成真实切换、旧主隔离、应用重连和 RTO/RPO 实测
上传 / 生成 / 下载文件App01 单点高可用共享存储；两台 App 使用同一逻辑路径
cron / staffPower / aizhcttimeApp01 单点两台都部署；Redis 原子租约；幂等与防重复验证
监控与切换告警原计划延期至少补 HA 健康、切换、存储和任务重复/漏跑告警

推荐方案

共享文件。优先复用客户已有高可用 NAS/NFS/分布式存储；没有则新增冗余存储资源。单台 NFS 或定时 rsync 不能包装成零单点。
原子单例。cron 和常驻单例任务在两台 App 都安装，通过 Redis SET key token NX PX ttl 抢租约；释放时校验 token，并给业务结果加幂等保护。
真实健康。Nginx 根据业务健康接口摘除故障节点，不只检查 TCP 端口；客户端配置有限超时和重连。
双向演练。分别停 App01、App02，验证登录、交易、文件、报表、任务执行一次、节点恢复和重新入池。

今天给客户的回复

建议原文：
您提出的疑问合理。两台应用服务器的目标就是任一台故障后，另一台能够自动承接业务。刚才“实现不了”的表述不准确，准确情况是：当前方案的入口、普通在线业务、数据库、缓存和消息链路已按自动切换设计，但上传/下载文件和部分定时任务还需要补共享存储及双机防重复机制，因此目前尚未达到“全功能自动接管”的验收条件。我们已经把这两项列为上线前必须关闭项；完成后会分别模拟 App01、App02 故障，实测切换时间、数据一致性、文件可用性和任务不重复，演练通过后再请贵方确认。在演练通过前，我们不会把它表述为已经实现。

决策门禁

必须确认Owner通过条件
是否有高可用共享存储客户基础设施负责人协议、容量、权限、冗余、挂载和故障演练均可验证
合同/投标/蓝图中的高可用承诺商务 + 产品明确必须全功能自动接管，或由客户书面接受降级边界
单例任务改造研发锁、TTL、续租/超时、幂等、失败恢复和测试全部通过
量化验收目标客户 + 产品 + 研发 + 交付确认 RTO/RPO、功能矩阵、演练步骤、签字人

候选目标：App 单节点故障 RTO ≤ 60 秒、已确认写入 RPO 0、单例任务每周期恰好 1 次。以上均为待确认目标，必须以现场演练实测为准。

人工 Review

兰海军
客户口径与商务边界
柴玉龙
现系统能力与技术缺口
后端负责人
任务锁、幂等和回归范围
客户基础设施
共享存储和虚拟化条件