冗余设计

冗余的基本原则

冗余设计的核心思想是消除单点故障（Single Point of Failure, SPOF）。任何可能成为系统瓶颈的组件都需要进行冗余部署。冗余不等于简单的数量增加，需要考虑故障检测、自动切换、数据一致性等问题。

// 无状态服务的冗余部署示例
@Component
public class OrderService {
    // 无状态设计：不保存会话状态
    // 所有状态存储在外部（Redis、数据库等）
    
    public Order createOrder(CreateOrderRequest request) {
        String sessionId = request.getSessionId();
        // 从外部存储获取会话状态
        Cart cart = redisTemplate.opsForHash()
            .entries("cart:" + sessionId);
        
        Order order = buildOrder(cart);
        // 写入数据库（支持多副本）
        orderRepository.save(order);
        return order;
    }
}

N+1 冗余策略

N+1 冗余是指在满足业务需求的 N 个实例基础上，额外增加 1 个备用实例。当某个实例故障时，备用实例接管其工作。

正常状态：
┌─────────┐ ┌─────────┐ ┌─────────┐
│ Node 1  │ │ Node 2  │ │ Node 3  │  ← 3个节点处理请求
│ Active  │ │ Active  │ │ Active  │
└─────────┘ └─────────┘ └─────────┘
     ↑           ↑           ↑
     └───────────┴───────────┘
              请求分发

故障状态：
┌─────────┐ ┌─────────┐ ┌─────────┐
│ Node 1  │ │ Node 2  │ │ Node 3  │
│ Active  │ │ Active  │ │  Failed │
└─────────┘ └─────────┘ └─────────┘
     ↑           ↑           
     └───────────┴───── 节点1、2接管所有请求

热备、温备、冷备

备份类型	实时同步	启动时间	数据延迟	适用场景
热备	是	秒级	接近零	核心交易系统
温备	半实时	分钟级	分钟级	重要业务系统
冷备	定期	小时级	小时级	非实时系统

# Kubernetes 有状态服务冗余配置
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: mysql
spec:
  serviceName: mysql
  replicas: 3
  selector:
    matchLabels:
      app: mysql
  template:
    spec:
      containers:
        - name: mysql
          image: mysql:8.0
          volumeMounts:
            - name: data
              mountPath: /var/lib/mysql
  volumeClaimTemplates:
    - metadata:
        name: data
      spec:
        accessModes: ["ReadWriteOnce"]
        storageClassName: fast-ssd
        resources:
          requests:
            storage: 100Gi

冗余与一致性

冗余设计需要权衡可用性和一致性。根据 CAP 定理，分布式系统在网络分区时只能在一致性和可用性之间选择。实际应用中通常采用最终一致性模型，在保证高可用的前提下逐步同步数据。