高可用架构设计：从单点到百万 QPS 的演进

// 一台服务器搞定一切

用户 → [Nginx] → [Tomcat（Spring Boot）] → [MySQL]
                          ↓
                    所有代码都在这里

// 配置：4C8G，MySQL 在同一台机器
// 能承载：~100 QPS
// 瓶颈：CPU、内存、磁盘 IO 都是上限

优化方式：
  垂直扩展（Scale Up）→ 升级到 16C64G
  → 加 SSD → 加内存
  → 单机上限大约 1000-2000 QPS
  → // 但单机扩展有天花板，且是单点故障

轮询（Round Robin）
  → 依次分发到后端服务器
  → 适合所有服务器配置相同的情况

加权轮询（Weighted Round Robin）
  → 根据服务器权重分发（权重高的多分配）
  → 适合服务器配置不同的情况

最少连接（Least Connections）
  → 分发给当前连接数最少的服务器
  → 适合长连接场景

IP Hash
  → 根据客户端 IP 哈希到固定服务器
  → 保证同一个客户端的请求始终到同一台服务器
  → 适合有 Session 的场景（但不推荐，应用层应无状态）

一致性哈希
  → 基于请求特征（如 userId）做一致性哈希
  → 服务器增减时只影响少量请求的映射

主从延迟问题：
  写完主库后立即读从库 → 可能读到旧数据
  // 解决方案：
  // 1. 关键业务强制读主库（@Master）
  // 2. 写后短暂延迟再读
  // 3. 写后把数据写入缓存，读缓存兜底

分库分表策略：
  // 水平分表：同一张表按规则拆到多个库
  user_id % 4 → 4 个库，每个库存 1/4 的用户
  // 垂直分表：大字段拆到扩展表
  user_base (id, name, age) + user_detail (id, avatar, bio)

分库分表的坑：
  跨库 JOIN → 改为应用层关联
  分布式事务 → 需要分布式事务方案（Seata/TCC）
  全局排序/分页 → 二次排序或游标分页
  全局唯一 ID → 雪花算法（Snowflake）/ Leaf

Cache Aside（旁路缓存）—— 最常用
  读：先查缓存 → 命中则返回 → 未命中则查 DB → 写入缓存
  写：先更新 DB → 再删除缓存（不是更新缓存！）
  // 为什么删除而不是更新？避免并发写导致的不一致

Write Through（写穿透）
  写操作同时更新缓存和 DB（由缓存中间件代理）
  → 保证缓存和 DB 的一致性
  → 但写入延迟增加

Write Behind（写回）
  写操作只更新缓存，异步批量刷新到 DB
  → 写入性能最高
  → 但宕机可能丢数据（Redis 持久化问题）

// 工程实践中 Cache Aside + 延迟双删 最常用：
// 1. 删除缓存 → 2. 更新 DB → 3. 延迟 500ms → 4. 再删缓存
// 步骤 4 兜底解决步骤 2 和 3 之间的并发读导致的脏缓存

RocketMQ（阿里开源）
  特点：事务消息、延迟消息、死信队列
  适合：电商交易、金融场景
  单机吞吐：10 万级 TPS

Kafka（LinkedIn 开源）
  特点：超高吞吐、分区消费、日志存储
  适合：日志采集、大数据管道、实时流处理
  单机吞吐：100 万级 TPS

RabbitMQ（Pivotal）
  特点：灵活路由（Exchange）、消息确认机制
  适合：复杂业务路由、企业应用集成
  单机吞吐：万级 TPS

// 电商系统通常选 RocketMQ（事务消息 + 业务功能丰富）
// 大数据/日志系统通常选 Kafka（超高吞吐）

注册中心：Nacos / Consul / ZooKeeper
  → 服务注册与发现

配置中心：Nacos / Apollo / Spring Cloud Config
  → 动态配置推送

API 网关：Spring Cloud Gateway / Kong / APISIX
  → 路由、鉴权、限流、日志

RPC 框架：Dubbo / gRPC / OpenFeign
  → 服务间通信

链路追踪：SkyWalking / Jaeger / Zipkin
  → 分布式调用链追踪，定位慢请求

日志聚合：ELK（Elasticsearch + Logstash + Kibana）
  → 集中式日志查询

监控告警：Prometheus + Grafana
  → 系统指标采集 + 可视化 + 告警

// 场景：日活 1000 万用户的电商大促

日均 QPS：
  1000万 用户 × 50 请求/人 ÷ 86400 秒 ≈ 5800 QPS

峰值 QPS（大促零点）：
  5800 × 5（峰值系数）≈ 29000 QPS

所需服务器：
  单机 QPS = 500（Spring Boot + Redis + MySQL）
  29000 ÷ 500 × 1.5（冗余）≈ 87 台应用服务器

数据库规划：
  主库写入 QPS = 29000 × 10%（写比例）= 2900
  分 4 个库 → 每个库 725 写入 QPS（可承受）
  从库 8 个 → 每个从库 3200 读取 QPS

Redis 规划：
  缓存命中率 95% → 只有 5% 穿透到 DB
  Redis 集群 6 节点（3 主 3 从）→ 单节点 10 万 QPS

同城双活：
  两个机房在同一城市，延迟 < 2ms
  → 数据库主从部署在两个机房
  → 应用层同时对外服务
  → 通过 DNS 权重分配流量
  // 优点：机房级容灾，RPO ≈ 0

异地多活：
  多个机房分布在不同城市/国家
  → 每个机房独立处理请求
  → 数据通过 MQ 异步同步
  → 通过 GSLB（全局负载均衡）分配流量到最近机房
  // 优点：城市级容灾，延迟最优
  // 难点：数据冲突解决（如两个机房同时修改同一用户信息）

两地三中心：
  同城双活 + 异地灾备
  → 同城两个机房做主从同步（保证数据一致）
  → 异地机房做冷备（极端灾难恢复）
  // 银行、金融行业的标配架构

容灾指标：
  RPO（Recovery Point Objective）：能容忍丢多少数据
  RTO（Recovery Time Objective）：多久恢复服务
  同城双活：RPO ≈ 0，RTO < 1 分钟
  异地多活：RPO ≈ 秒级，RTO ≈ 分钟级

// 高可用架构需要全链路压测来验证

核心原则：
  在生产环境模拟真实流量，验证系统在高负载下的表现
  → 发现瓶颈点（哪个服务先扛不住）
  → 验证限流、熔断、降级是否按预期工作
  → 验证容量规划是否准确

流量染色：
  压测请求添加特殊 Header（如 x-test: true）
  → 压测数据写入影子库/影子表
  → 不影响线上真实数据

常见压测工具：
  JMeter — 功能全面，支持多种协议
  Gatling — Scala 编写，性能优异
  自研压测平台 — 大厂通常自建（如阿里 PTS）