整体架构与高可用

一句话

一台 Agent。双 Master 各 2C2G，跑 10s 小时长稳；DB 连接稳定不爬升，高可用不靠堆机器，而是无状态设计和路由黏性。

主要使用者痛点

• 监控程序必须保证：Agent 端在 Master 故障后不丢数据、不中断采集。
• 同一台 Agent 必须始终路由到同一台 Master否则指标被切碎导致告警关联错误、趋势对比失真。
• Master 故障时需要秒级无感切换，让业务持续运行。
• 避免因缓存分叉导致状态冲突； 单机 Master 的“一机全失”风险不可接受。

架构概览

Agent × ↓ 上报Nginx 四层 :
↓Master- / Master- :
↓MySQL
↑Nginx 七层 :
↑server-api : × + 前端 Vue

Keepalived VIP：组播坑 & 单播方法

问题：

• VRRP 默认使用组播心跳。在桥接网卡上容易被交换机丢弃，引发脑裂。
• 必须同时检测 Nginx 与 Master 状态，否则 VIP 会漂移到业务已挂的节点。

• 显式配置 unicast_peer 指定对端 IP，将心跳改为单播。
• track_script 同时探测 Nginx 与 Master；任一脚本失败即降低优先级，使 VIP 自动漂移到健康节点。
• User Pain Point Addressed： 保证业务在 Master 故障时自动切换，无需人工干预且不会出现流量乱流。

Nginx 双栈：七层给人、四层给机

Nginx 同时承担两种职责：

• 七层 ：Web 页面 + API 请求 upstream api_backend { ... } round-robin

四层 ：Agent 上报 hash $remote_addr consistent

User Pain Point Addressed： Agent 必须黏性路由到同一主机，否则指标会被切碎；四层保持 mTLS 原样传递，避免证书链被吞噬。

为什么不用七层？老实说，从两大理由来看，

1. Nginx TLS 终止会吞掉客户端证书链；mTLS 必须在后端完成才能验证 CA 与吊销列表。四层只做 TCP 转发，可直接透传 mTLS 会话。 话说回来，
2. Nginx 七层解析 HTTP 协议产生额外 CPU 与延迟。而 Agent 上报频率仅每10s一次对 CPU 要求更低。老实说，四层节省资源并提高性能。
3. 一致性哈希  确保在节点增删时只影响约1/N 的 Agent，从而减少重哈希造成的数据迁移。

关键技术细节：The use of consistent hashing dramatically reduces data reshuffling during node changes and ensures that when a master fails,only affected agents are redirected—ors remain on ir current master.

双 Master 无状态：状态放 DB，自然一致化

User Pain Point Addressed： No state migration required on failover – eliminates “data loss” risk.

• No inter‑master HTTP sync. Masters only read/write shared MySQL tables – configuration,alerts,agent info are persisted centrally.

A dedicated /health check loop every 30s writes a snapshot to . Includes DB ping,worker count,queue length,goroutine count and GC frequency – single source of truth for health status displayed on API dashboard.

The alert debounce state is stored in DB so that after a restart it resumes without triggering a flood of alerts.

When a master dies or instantly takes over because all state resides in MySQL – no session transfer or cache invalidation needed. The one-time read from MySQL happens at most every few seconds which is fully acceptable in monitoring scenarios where latency tolerance is high. This design directly addresses core user pain point that “if I lose my main server I don’t want to lose any collected metrics.” It also mitigates anor hidden risk – “ system can’t write new data even though no master has failed”。which was exposed only under load testing. By putting all mutable state into MySQL we guarantee consistency across both nodes without complex replication logic. If you think you’re ready for production but haven’t considered this subtlety you’ll hit trouble when your worker pool saturates under heavy load or when your network hiccups during an outage. In short,making your masters stateless isn’t just a design choice – it’s how you avoid silent data loss while keeping uptime high.

- 验证 -

- 压测来自 docs/reports/压测报告-2核2G支撑8004Agent长稳.md 再看阶梯加压，

阶段	Agent 数	时长	DB 连接	现象
基线800——18正常长稳80048h+ -20不爬升一分钟增量 行，零积压零丢失中压10004~4h24-37仍稳定瞬时200042min30-33正常瞬时360043min33分钟增量卡在预期，Worker 池到顶

Agent 数翻 倍，DB 连接不到翻倍——攒批生效；时瓶颈在应用层 Worker 池，不在架构层、不在 MySQL。高可用架构在 8h 长稳 + 瞬时下没有一处崩溃点。

说到故障切换验证，Keepalived 健康检查探到 Master 异常 → 降优先级 → VIP 漂移 → Agent 四层 hash 仍路由到 VIP → 落到另一台 Master。因为 Master 无状态，切换后无需任何状态迁移；Agent侧唯一感知是本次上报可能失败一次 走离线缓存补发兜住。

- 回看 -

- 高可用这块做对的是“无状态 + 黏性路由”的组合：无状态让切换变得简单，黏性让数据不切碎。

做错或者说结果发现—— 高可用解决了“Master 挂了怎么办”。但没解决 “Master 没挂却写不动”，这是压测才暴露的。

从另一个回看来看。双 Master 没有发挥“负载分担”的价值——两个 2C2G 各自独立处理全部 Agent，单 Master 也有 Agent 的拐点。双 Master 的价值是可用性，不是性能。如果当初明白这点，压测时的注意力会早一点放到 Worker 池上。

---