11、系统高可用设计：冗余架构、灾备方案、负载均衡、故障切换机制

做市商系统，说白了就是一台印钞机——前提是它得一直转。我见过太多团队，策略再牛，系统一挂全白搭。今天咱们聊聊怎么让这台机器7x24小时不熄火。

11.1 冗余架构：别把所有鸡蛋放一个篮子里

冗余不是简单的堆机器。我习惯把冗余分成三个层次：

• 硬件冗余：双电源、RAID磁盘、多网卡绑定
• 服务冗余：每个关键服务至少部署2个实例
• 数据冗余：主从复制、多副本存储

举个例子，我们的订单管理服务，曾经因为一台机器的网卡松动，导致整个交易链路中断了3分钟。后来我强制要求：所有核心服务必须跨机柜部署，物理隔离。

11.2 灾备方案：异地多活 vs 冷备

灾备方案的选择，取决于你能接受多少损失。我个人把灾备分为三级：

级别	RTO（恢复时间）	RPO（数据丢失）	成本
冷备	小时级	分钟级	低
温备	分钟级	秒级	中
热备（多活）	秒级	毫秒级	高

做市商系统，我建议至少做到温备。为什么？因为冷备恢复期间，行情波动可能让你亏掉半年的利润。我曾经帮一个客户做灾备演练，冷备恢复花了4个小时，期间市场剧烈波动，直接亏了200万。嗯，从那以后他再也不敢用冷备了。

11.3 负载均衡：流量分发与健康检查

负载均衡不只是把请求分一分那么简单。我常用的策略有：

• 轮询：简单均匀，适合无状态服务
• 最少连接：适合长连接场景，比如WebSocket
• 一致性哈希：适合需要会话保持的场景

这里有个细节很多人忽略——健康检查。你想想看，如果负载均衡器把请求发到一个已经挂掉的服务上，那跟没有负载均衡有什么区别？

# Nginx健康检查配置示例
upstream order_services {
    server 10.0.1.1:8080 max_fails=3 fail_timeout=30s;
    server 10.0.1.2:8080 max_fails=3 fail_timeout=30s;
    
    check interval=3000 rise=2 fall=5 timeout=1000 type=http;
    check_http_send "GET /health HTTP/1.0\r\n\r\n";
    check_http_expect_alive http_2xx http_3xx;
}

我个人习惯把健康检查的阈值设得严格一些。连续失败3次就摘掉节点，连续成功2次才重新加入。这样能避免服务抖动带来的影响。

11.4 故障切换机制：自动 vs 手动

故障切换，核心就两个问题：怎么发现故障？怎么切换？

我常用的检测手段：

• 心跳检测：每秒钟发一次心跳，连续3次无响应则判定故障
• 业务探针：模拟一笔小额交易，验证全链路是否正常
• 指标监控：延迟突增、错误率飙升，都是故障的前兆

切换方式上，我建议：

• 核心链路：自动切换，但保留手动干预入口
• 非核心链路：半自动，告警后人工确认再切换

11.5 整体架构图

下面这张图，是我做做市商系统高可用设计的核心思路。你看一眼就能明白各组件之间的关系。

这张图里，你注意看几个关键点：

• 负载均衡器后面挂了两个订单服务实例，一主一备
• Redis用了哨兵模式，主挂了自动切备
• MySQL主备之间是异步复制，备库用虚线表示
• 监控系统独立部署，实时检测各组件健康状态

11.6 实战经验总结

做了这么多年量化系统，我总结了几条铁律：

1. 不要相信任何单点——哪怕它号称99.999%可用
2. 故障一定会发生——不是如果，是何时
3. 演练比方案重要——纸上谈兵没用，真刀真枪练一次
4. 监控要分层——基础设施、中间件、业务指标，缺一不可

---