4. 高可用设计原则：冗余部署、故障转移、无状态化、数据持久化策略
在分布式追踪系统中，高可用（High Availability, HA）并非单一技术点，而是由冗余部署、故障转移、无状态化和数据持久化四大支柱共同支撑的设计范式。本章将逐一拆解这些原则在值班台场景中的落地方式，并给出可量化的部署指标。
4.1 冗余部署：消除单点故障
冗余部署是HA的物理基础。核心思想是：任何单一组件失效都不应导致系统整体不可用。在分布式追踪架构中，需要针对以下关键组件实施冗余：
| 组件层 | 冗余策略 | 推荐副本数 | 部署拓扑 |
|---|---|---|---|
| Agent（采集端） | DaemonSet / Sidecar 多副本 | 每节点至少1个 | 与业务容器同节点部署 |
| Collector（收集器） | 无状态水平扩展 + 负载均衡 | ≥3（生产环境） | 跨可用区部署 |
| Storage（存储层） | 主从复制 / 分片集群 | ≥3（含仲裁节点） | 跨机房/跨区域 |
| Query（查询服务） | 无状态水平扩展 | ≥2 | 与Collector同集群 |
关键指标： 生产环境 Collector 和 Storage 的冗余度必须满足 N+2 原则，即至少比峰值需求多2个副本，以应对滚动更新和突发故障。
4.2 故障转移：自动恢复与流量切换
冗余部署提供了“备用资源”，而故障转移机制则负责在故障发生时自动将流量从失效节点切换到健康节点。值班台追踪系统通常采用以下两种故障转移模式：
- 主动探测 + 健康检查： 负载均衡器（如 Envoy / Nginx）定期对 Collector 和 Query 节点发送 HTTP/TCP 健康检查。连续3次失败则标记为“不健康”，自动从上游池中摘除。
- 客户端侧故障转移： Agent 或 SDK 内置重试与 fallback 逻辑。当主 Collector 超时或返回5xx错误时，自动切换到备用 Collector 地址列表。
避坑提示： 故障转移必须配合优雅关闭（Graceful Shutdown）机制。节点下线前应等待正在处理的 Span 发送完毕（通常设置 30s 宽限期），避免数据丢失。
4.3 无状态化：水平扩展的基石
无状态化是指服务实例不存储任何与请求相关的本地状态，所有状态信息要么随请求传递，要么存储在外部共享存储中。在值班台追踪系统中，Collector 和 Query 服务必须严格遵循无状态设计：
- Collector 无状态化： 不缓存 Span 数据，接收后立即写入后端存储（如 Kafka / Elasticsearch）。实例重启或扩缩容不影响数据完整性。
- Query 无状态化： 查询请求中携带 TraceID 和时间范围，Query 服务从存储层读取数据并聚合返回。不维护本地缓存或会话。
- Session 外部化： 如果 Web 控制台需要用户登录态，必须使用 Redis 或 JWT 等外部会话存储，禁止本地 Session。
反模式警示： 不要在 Collector 中实现“本地批处理 + 延迟写入”逻辑。这会导致实例故障时丢失未刷入存储的 Span 数据，破坏无状态承诺。
4.4 数据持久化策略：不丢不重
分布式追踪数据是诊断故障的核心依据，必须保证高可靠写入和可恢复存储。以下是值班台场景下的持久化策略矩阵：
| 数据流阶段 | 持久化手段 | 可靠性等级 | 恢复方式 |
|---|---|---|---|
| Agent → Collector | 内存缓冲 + 本地文件回退（File Fallback） | 高（至少一次语义） | Agent 重启后重发本地文件 |
| Collector → 消息队列 | Kafka 生产者 ACK=all + 幂等写入 | 极高（精确一次语义） | Kafka 副本恢复 |
| 消息队列 → 存储 | 消费者手动提交 Offset + 批量写入 | 高（至少一次语义） | 重置 Offset 重新消费 |
| 存储层（ES/ClickHouse） | 副本分片 + 跨集群复制（CCR） | 极高（RPO≈0） | 从副本或远程集群恢复 |
生产建议： 存储层建议采用 3副本 + 跨可用区部署。对于 Elasticsearch，设置
index.number_of_replicas: 2 并启用 translog.durability: async 以平衡写入性能与可靠性。
4.5 四大原则的协同关系
上述四项原则并非孤立存在，而是相互依赖、共同构成高可用闭环：
- 无状态化 使 冗余部署 成为可能——无状态实例可以随意增加或移除，无需担心数据迁移。
- 故障转移 依赖 冗余部署 提供的备用资源，同时依赖 无状态化 确保切换后请求能被正确处理。
- 数据持久化 为所有层提供“后悔药”，即使故障转移过程中发生数据重复或丢失，也能从持久化存储中恢复。
设计检查清单： 在评审值班台追踪系统架构时，请逐项确认：① 每个组件是否有至少2个副本？② 故障转移是否经过自动化测试？③ 所有服务是否可安全重启而不丢数据？④ 存储层是否满足 RPO < 1s 的要求？