关键指标详解

可用性对照表 — "几个9" 意味着什么？

冗余策略

故障转移 (Failover)

健康检查与熔断器 (Circuit Breaker)

熔断器的思想来源于电路中的保险丝：当下游服务异常率超过阈值时，自动"断开"，避免级联故障。

限流算法 (Rate Limiting)

优雅降级策略

负载均衡算法对比

L4 vs L7 负载均衡

Nginx 配置示例

# Nginx upstream 配置 - Weighted Round Robin
upstream backend {
    server 10.0.0.1:8080 weight=5;  # 高配服务器，分配更多流量
    server 10.0.0.2:8080 weight=3;
    server 10.0.0.3:8080 weight=2;  # 低配服务器

    # 健康检查（开源版需第三方模块）
    # max_fails=3 fail_timeout=30s

    # 保持长连接
    keepalive 32;
}

server {
    listen 80;
    location / {
        proxy_pass http://backend;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }

    # IP Hash 会话保持
    # location /api/ {
    #     ip_hash;
    #     proxy_pass http://backend;
    # }
}

CAP 定理

BASE 理论

一致性模型

2PC — 两阶段提交

TCC — Try-Confirm-Cancel

Saga 模式

本地消息表 + MQ

分布式事务方案对比

缓存模式 (Cache Patterns)

缓存失效策略

缓存三大问题

热点 Key 处理

读写分离

分库分表

分片键 (Sharding Key) 选择

分布式 ID 生成 — 雪花算法 (Snowflake)

Step 1: 需求澄清

Step 2: 容量估算

# 假设: 5 条产线 × 20 设备 × 30 采集点 = 3000 个数据点/秒
# 写入 QPS: 3000 点/秒 × 1KB/点 ≈ 3 MB/s ≈ 260 GB/天
# 7 天原始数据: ~1.8 TB
# 200 并发用户, 每人每 5 秒刷新一次 → 读 QPS ≈ 40

# 结论:
# - 写入压力大 (3K QPS), 需要时序数据库
# - 读取压力小 (40 QPS), 普通缓存即可
# - 存储量中等, SSD 够用

Step 3: 系统架构

Step 4: 技术选型与理由

Step 5: 数据流详解

# 完整数据流:
PLC 设备
  → MQTT 上报 (每秒)
    → EMQX 接收
      → Kafka (topic: raw-telemetry)
        → Flink 消费
          → 计算 OEE = 可用率 × 性能率 × 质量率
          → 结果写入 TimescaleDB (持久化)
          → 结果写入 Redis (实时缓存)
          → 通过 WebSocket 推送到前端看板
          → 告警判断 → 企业微信通知

# OEE 计算公式:
# 可用率 = 实际运行时间 / 计划运行时间
# 性能率 = 实际产量 / 理论产量
# 质量率 = 良品数 / 总产量
# OEE = 可用率 × 性能率 × 质量率 (0~100%)

Step 6: 扩展性设计