第2章：高可用设计原则

各位同学，今天我们来聊聊高可用设计的几个核心原则。说实话，这些原则我早年做项目时也没太当回事，直到线上出了几次大故障，才真正体会到它们的价值。

高可用设计，说白了就是让系统在各种异常情况下还能继续提供服务。我把它拆解成五个关键原则：冗余、消除单点故障、优雅降级、故障隔离、幂等性设计。咱们一个一个来看。

2.1 冗余：别把所有鸡蛋放一个篮子里

冗余这个概念，大家应该不陌生。简单说就是「多准备几份」。我在项目中遇到过最典型的例子——某次双十一大促，核心数据库单节点扛不住流量，直接挂了。幸好我们提前做了主从复制，从库顶上去，业务没中断。

冗余的常见形式：

• 计算冗余：多台服务器同时提供服务，比如Nginx后面挂多个Tomcat实例
• 数据冗余：数据多副本存储，比如MySQL主从、Redis哨兵模式
• 网络冗余：多条链路、多个DNS解析、多线路接入
• 地域冗余：多机房、多云部署

2.2 消除单点故障：找到那个「致命弱点」

单点故障（SPOF）是系统里最危险的东西。我习惯在架构设计阶段就做一次SPOF分析，把每个组件都问一遍：「如果它挂了，系统还能跑吗？」

常见的单点及解决方案：

单点类型	风险	消除方案
单台数据库	宕机后数据不可用	主从复制 + 自动故障切换
单台负载均衡	入口流量全部中断	主备模式或DNS轮询
单台应用服务器	请求无法处理	水平扩展 + 健康检查
单一云厂商	云服务整体故障	多云部署

2.3 优雅降级：有总比没有好

优雅降级，说白了就是「保底策略」。当系统资源不足或部分功能异常时，主动放弃非核心功能，保证核心功能可用。

我举个例子：电商网站的「商品详情页」包含商品信息、用户评论、推荐商品、广告位。如果推荐系统挂了，你完全可以降级——不展示推荐商品，但商品信息和评论必须正常显示。

降级策略分类：

• 功能降级：关闭非核心功能，比如关闭日志上报、关闭个性化推荐
• 数据降级：使用缓存数据代替实时数据，比如展示30分钟前的库存数据
• 流量降级：限制并发请求数，比如只允许50%的请求通过
• 服务降级：调用备用服务，比如从调用推荐服务改为调用静态推荐列表

2.4 故障隔离：别让一个坏苹果坏了一筐

故障隔离的核心思想是「限制爆炸半径」。一个服务出问题，不应该拖垮整个系统。

常见的隔离手段：

• 线程池隔离：不同服务使用不同的线程池，A服务线程池满了，不影响B服务
• 进程隔离：把服务拆分成独立进程，一个进程崩溃不会影响其他进程
• 容器隔离：使用Docker容器，每个服务运行在独立容器中
• 机房隔离：不同业务部署在不同机房，一个机房故障不影响其他机房

我记得有一次线上事故，某个业务模块的内存泄漏导致整个JVM OOM。因为没有做进程隔离，所有服务都挂在一个JVM里，结果全部宕机。这就是典型的「没有故障隔离」的教训。

2.5 幂等性设计：重复执行也不怕

幂等性，听起来有点学术。其实很简单——同一个操作，执行一次和执行多次，结果是一样的。

为什么需要幂等性？因为在分布式系统中，网络超时、重试、消息重复是家常便饭。如果没有幂等性，用户点一次「提交订单」，结果系统处理了两次，那就出大问题了。

幂等性设计的常见方案：

• 唯一ID去重：每次请求携带唯一ID，服务端记录已处理的ID，重复请求直接忽略
• 状态机校验：订单状态从「待支付」到「已支付」只能转换一次
• 数据库唯一约束：利用数据库的唯一索引防止重复插入
• 乐观锁：使用版本号控制更新操作，防止并发覆盖

// 幂等性设计示例：使用唯一ID去重
public boolean processPayment(String orderId, String paymentId) {
    // 先检查paymentId是否已经处理过
    if (redis.exists("payment:" + paymentId)) {
        return true; // 已处理，直接返回成功
    }
    
    // 执行支付逻辑
    boolean result = doPayment(orderId);
    
    if (result) {
        // 记录已处理的paymentId，设置过期时间防止无限增长
        redis.setex("payment:" + paymentId, 3600, "done");
    }
    
    return result;
}

小结

这五个原则，我建议你在设计系统时反复对照检查：

1. 冗余：关键组件有没有多副本？
2. 消除单点：有没有哪个节点挂了会导致全系统瘫痪？
3. 优雅降级：非核心功能挂了，核心功能还能跑吗？
4. 故障隔离：一个服务出问题，会不会拖垮其他服务？
5. 幂等性：重复请求会不会造成数据不一致？

下一章，我们会把这些原则应用到多云架构中，看看具体怎么落地。你想想看，如果把这些原则都做到位了，系统想不「高可用」都难。