@umacloud/knowledge 1.0.1

package/development/05-cases/case-database-scaling.md

@@ -0,0 +1,500 @@
+---
+id: case-database-scaling
+title: 案例研究：数据库从单实例到读写分离到分库分表的演进
+domain: development
+category: 05-cases
+difficulty: intermediate
+tags: [agent, case, checklist, database, development, scaling, 元数据]
+quality_score: 70
+last_updated: 2026-06-15
+---
+# 案例研究：数据库从单实例到读写分离到分库分表的演进
+
+## 元数据
+
+| 字段 | 值 |
+|------|------|
+| 行业 | 社交电商平台 |
+| 系统规模 | 注册用户 3000 万，日活 400 万 |
+| 数据库 | MySQL 8.0 |
+| 数据规模 | 总数据量 4.2TB，核心表 8 亿行 |
+| 团队规模 | 后端 20 人，DBA 3 人 |
+| 演进周期 | 3 年（2022-01 至 2024-12） |
+
+---
+
+## 一、背景
+
+### 1.1 业务概述
+
+某社交电商平台，核心业务为用户分享商品赚取佣金。主要数据实体：
+
+- **用户表（users）**：3000 万行，年增长 800 万
+- **订单表（orders）**：8 亿行，日增 150 万
+- **商品表（products）**：500 万行，日增 2000
+- **佣金表（commissions）**：6 亿行，日增 120 万
+- **关系表（user_relations）**：1.2 亿行（用户邀请链路）
+
+### 1.2 演进三阶段概览
+
+```
+阶段一（2022 Q1）: 单实例 → 主从复制（读写分离）
+  触发条件：读 QPS 达到 8000，主库 CPU 85%+
+
+阶段二（2023 Q2）: 主从 → 垂直拆分（按业务拆库）
+  触发条件：单库连接数达上限，慢查询频发
+
+阶段三（2024 Q1）: 垂直拆分 → 水平分片（分库分表）
+  触发条件：订单表 8 亿行，单表查询超时
+```
+
+---
+
+## 二、阶段一：单实例到读写分离
+
+### 2.1 触发问题
+
+2022 年初，业务快速增长，数据库出现严重瓶颈：
+
+| 指标 | 阈值 | 实际值 |
+|------|------|--------|
+| 读 QPS | 建议 < 5000 | 8,200 |
+| 写 QPS | 建议 < 2000 | 1,800 |
+| 主库 CPU | 建议 < 70% | 85-92% |
+| 慢查询/分钟 | 建议 < 5 | 35 |
+| 连接数 | 上限 1000 | 890 |
+
+### 2.2 方案设计
+
+```
+架构变更：
+Before:  App → MySQL (Single Instance, 64C 256G)
+After:   App → ProxySQL → MySQL Master (写)
+                        → MySQL Slave-1 (读)
+                        → MySQL Slave-2 (读)
+                        → MySQL Slave-3 (读，报表专用)
+```
+
+### 2.3 关键实施细节
+
+#### 中间件选择
+
+| 方案 | 优势 | 劣势 | 选择 |
+|------|------|------|------|
+| 应用层读写分离 | 无中间件依赖 | 代码侵入大 | 否 |
+| ProxySQL | 透明代理，路由灵活 | 运维复杂度 | **是** |
+| MySQL Router | 官方出品 | 功能较弱 | 否 |
+| ShardingSphere-Proxy | 功能全面 | 太重 | 否 |
+
+#### ProxySQL 路由规则
+
+```sql
+-- 写操作路由到 Master
+INSERT INTO mysql_query_rules (rule_id, match_pattern, destination_hostgroup)
+VALUES (1, '^(INSERT|UPDATE|DELETE|REPLACE)', 10);
+
+-- 读操作路由到 Slave
+INSERT INTO mysql_query_rules (rule_id, match_pattern, destination_hostgroup)
+VALUES (2, '^SELECT', 20);
+
+-- 事务内读操作路由到 Master（保证读已之写一致性）
+INSERT INTO mysql_query_rules (rule_id, match_pattern, destination_hostgroup, flagIN)
+VALUES (3, '^SELECT', 10, 1);
+
+-- 报表查询路由到专用从库
+INSERT INTO mysql_query_rules (rule_id, match_pattern, destination_hostgroup, schemaname)
+VALUES (4, '^SELECT.*report_', 30, 'analytics');
+```
+
+#### 主从一致性处理
+
+核心问题：从库有复制延迟（通常 100-500ms），某些场景需要读到最新数据。
+
+```
+策略分类：
+1. 强一致读（写后立即读）→ 路由到 Master
+   场景：下单后查看订单详情、修改资料后查看
+
+2. 会话一致读 → 3 秒内路由到 Master，之后路由到 Slave
+   场景：用户操作后的页面刷新
+
+3. 最终一致读 → 路由到 Slave
+   场景：商品列表、排行榜、搜索结果
+```
+
+应用层实现：
+
+```python
+# 装饰器标记强一致读
+@route_to_master(duration=3)  # 3 秒内读 Master
+def create_order(order_data):
+    db.master.insert(order_data)
+    return db.query("SELECT * FROM orders WHERE id = %s", order_data.id)
+```
+
+### 2.4 阶段一结果
+
+| 指标 | 改造前 | 改造后 |
+|------|--------|--------|
+| 主库读 QPS | 8,200 | 1,800（仅写 + 强一致读） |
+| 主库 CPU | 85-92% | 35-45% |
+| 慢查询/分钟 | 35 | 3 |
+| 读延迟 P99 | 450ms | 85ms |
+| 系统可支撑 QPS | 10,000 | 35,000 |
+
+**实施周期**：3 周（含压测和灰度）
+
+---
+
+## 三、阶段二：读写分离到垂直拆分
+
+### 3.1 触发问题
+
+2023 年中，随着业务复杂度提升，主从架构再次出现瓶颈：
+
+| 指标 | 问题描述 |
+|------|----------|
+| 连接数 | 主库连接数达 800+（上限 1000），每个业务模块占用独立连接池 |
+| 锁竞争 | 订单表和佣金表写入高并发，行锁等待严重 |
+| DDL 风险 | 8 亿行大表加字段需要 4 小时，业务窗口不够 |
+| 耦合性 | 所有业务共享一个数据库，一个慢查询影响全局 |
+| 备份时间 | 全量备份 6 小时，影响从库性能 |
+
+### 3.2 垂直拆分方案
+
+按业务域拆分为 4 个独立数据库：
+
+```
+拆分前（单库 all_in_one）:
+├── users, user_profiles, user_settings
+├── orders, order_items, order_logs
+├── products, categories, product_images
+├── commissions, commission_rules, withdrawals
+└── user_relations, invite_rewards
+
+拆分后：
+├── user_db:      users, user_profiles, user_settings, user_relations
+├── order_db:     orders, order_items, order_logs
+├── product_db:   products, categories, product_images
+├── finance_db:   commissions, commission_rules, withdrawals, invite_rewards
+```
+
+每个库独立的主从架构：
+
+```
+user_db:    Master + 2 Slave （读多写少）
+order_db:   Master + 2 Slave （读写均高）
+product_db: Master + 1 Slave （读多写少）
+finance_db: Master + 2 Slave （写多，一致性要求高）
+```
+
+### 3.3 核心挑战：跨库 JOIN 改造
+
+**问题**：拆分前有 34 处跨业务域的 JOIN 查询。
+
+**改造策略**：
+
+```
+策略 1: 冗余字段（12 处）
+  订单表冗余 user_name、product_name
+  避免高频查询需要跨库
+
+策略 2: 应用层聚合（15 处）
+  先查订单列表 → 批量查用户信息 → 内存中组装
+  使用并行查询减少延迟
+
+策略 3: 数据同步到宽表（5 处）
+  通过 binlog 同步到 ClickHouse 宽表
+  报表和复杂分析查询走 ClickHouse
+
+策略 4: 消除不必要的 JOIN（2 处）
+  重新审视业务需求，发现 2 处 JOIN 已无业务意义
+```
+
+### 3.4 跨库事务处理
+
+**问题**：下单流程涉及 order_db（创建订单）+ finance_db（计算佣金）+ product_db（扣减库存）
+
+**方案**：基于消息队列的最终一致性
+
+```
+下单流程：
+1. order_db:   创建订单（PENDING）← 本地事务
+2. MQ:         发送"订单已创建"消息
+3. product_db: 扣减库存 ← 消费消息，本地事务
+4. finance_db: 计算佣金 ← 消费消息，本地事务
+5. order_db:   更新订单状态（CONFIRMED）← 消费确认消息
+
+补偿机制：
+- 库存扣减失败 → 发送补偿消息 → 取消订单
+- 佣金计算失败 → 异步重试 3 次 → 失败进入人工处理队列
+- 定时对账任务：每小时扫描 PENDING 超时订单
+```
+
+### 3.5 数据迁移过程
+
+```
+Phase 1: 双写准备（1 周）
+  - 新建 4 个独立数据库实例
+  - 通过 DTS（数据传输服务）全量同步 + 增量追赶
+
+Phase 2: 双写验证（2 周）
+  - 应用层双写：先写旧库，再写新库
+  - 对账任务：每分钟比对新旧库数据一致性
+  - 不一致记录写入修复队列
+
+Phase 3: 切读（1 周）
+  - 读流量逐步切到新库：10% → 50% → 100%
+  - 对比新旧库返回结果
+
+Phase 4: 切写（3 天）
+  - 写流量切到新库
+  - 旧库保持只读同步，作为回滚兜底
+  - 观察 7 天后下线旧库
+```
+
+### 3.6 阶段二结果
+
+| 指标 | 改造前 | 改造后 |
+|------|--------|--------|
+| 单库连接数 | 800+ | 每库 200 以内 |
+| 订单写入延迟 P99 | 380ms | 45ms |
+| DDL 变更时间 | 4 小时 | 15 分钟（表更小） |
+| 全量备份时间 | 6 小时 | 每库 45 分钟 |
+| 故障影响范围 | 全部业务 | 仅单个业务域 |
+
+**实施周期**：8 周
+
+---
+
+## 四、阶段三：垂直拆分到水平分片
+
+### 4.1 触发问题
+
+2024 年初，order_db 成为新的瓶颈：
+
+| 指标 | 问题描述 |
+|------|----------|
+| orders 表行数 | 8 亿行，单表 380GB |
+| 写入 QPS | 峰值 4,500 |
+| 查询延迟 | 按用户查询 P99 = 1.2s |
+| 索引大小 | 120GB，超过内存，频繁磁盘 IO |
+| DDL | 加索引预估 8 小时，无法执行 |
+
+同时 finance_db 的 commissions 表也达到 6 亿行。
+
+### 4.2 分片策略设计
+
+#### 分片键选择
+
+| 候选分片键 | 优势 | 劣势 | 评估 |
+|------------|------|------|------|
+| order_id | 数据均匀 | 按用户查询需要扇出全部分片 | 否 |
+| user_id | 用户维度查询无需跨片 | 大卖家数据倾斜 | **是** |
+| created_at | 范围查询友好 | 热点集中在最新分片 | 否 |
+| user_id + 月份 | 均匀 + 范围友好 | 复杂度高 | 备选 |
+
+最终选择 **user_id** 作为分片键，理由：
+1. 95% 的查询带有 user_id 条件
+2. 订单详情通过 order_id 查询时，order_id 编码中包含 user_id（雪花算法自定义段）
+3. 大卖家数据倾斜问题通过 1024 个虚拟分片缓解
+
+#### 分片规模
+
+```
+orders 表分片：
+  物理库：4 个（order_db_0 ~ order_db_3）
+  每库表：256 个（orders_0000 ~ orders_0255）
+  总分片：1024 个虚拟分片
+  路由规则：shard_id = user_id % 1024
+  物理库映射：db_id = shard_id / 256
+
+commissions 表分片：
+  同 orders 表策略，按 user_id 分片到同一组库
+  保证同一用户的订单和佣金在同一物理库（支持本地 JOIN）
+```
+
+### 4.3 分片中间件选择
+
+| 方案 | 优势 | 劣势 | 选择 |
+|------|------|------|------|
+| ShardingSphere-JDBC | Java 原生，性能好 | 仅 Java | 否（Go技术栈） |
+| Vitess | YouTube 验证 | 运维复杂度极高 | 否 |
+| 自研路由层 | 完全可控 | 开发维护成本 | **是** |
+| CockroachDB | 自动分片 | 换数据库风险大 | 否 |
+
+选择自研轻量路由层（Go middleware），理由：
+1. 团队 Go 技术栈，中间件生态不如 Java 成熟
+2. 分片规则相对简单（单键取模），无需重量级中间件
+3. 自研可完全控制路由逻辑和异常处理
+
+#### 路由层核心代码设计
+
+```go
+type ShardRouter struct {
+    shardCount int           // 1024
+    dbCount    int           // 4
+    dbPool     []*sql.DB     // 4 个物理库连接池
+}
+
+func (r *ShardRouter) Route(userID int64) (db *sql.DB, tableName string) {
+    shardID := userID % int64(r.shardCount)
+    dbIndex := shardID / int64(r.shardCount/r.dbCount)
+    tableIndex := shardID % int64(r.shardCount/r.dbCount)
+    return r.dbPool[dbIndex], fmt.Sprintf("orders_%04d", tableIndex)
+}
+
+func (r *ShardRouter) ScatterQuery(ctx context.Context, query string) ([]Row, error) {
+    // 无分片键的查询：并行查询所有分片，合并结果
+    g, ctx := errgroup.WithContext(ctx)
+    results := make([][]Row, r.dbCount)
+    for i := 0; i < r.dbCount; i++ {
+        i := i
+        g.Go(func() error {
+            // 每个库内 256 个表用 UNION ALL
+            rows, err := r.dbPool[i].QueryContext(ctx, query)
+            results[i] = rows
+            return err
+        })
+    }
+    if err := g.Wait(); err != nil { return nil, err }
+    return mergeResults(results), nil
+}
+```
+
+### 4.4 全局唯一 ID 方案
+
+分片后无法依赖数据库自增 ID，采用自定义雪花算法：
+
+```
+Order ID 结构（64 bit）：
+┌─────────┬──────────┬───────────┬──────────┐
+│ 1 bit   │ 41 bit   │ 10 bit    │ 12 bit   │
+│ 符号位  │ 时间戳   │ user_id   │ 序列号   │
+│         │ (毫秒)   │ 后10位    │          │
+└─────────┴──────────┴───────────┴──────────┘
+
+优势：
+- 从 order_id 可直接提取 user_id 后 10 位 → 快速路由
+- 时间有序 → B+ Tree 索引友好
+- 每毫秒每用户可生成 4096 个订单 → 容量充足
+```
+
+### 4.5 数据迁移
+
+```
+Phase 1: 新集群搭建（1 周）
+  - 4 个 MySQL 实例，每个 32C 128G
+  - 预创建 1024 个分片表
+
+Phase 2: 全量迁移（3 天）
+  - 使用自研迁移工具，按 user_id 读取旧表 → 计算分片 → 写入新表
+  - 8 亿行数据，16 线程并行，速度 300 万行/分钟
+  - 总耗时约 4.5 小时
+
+Phase 3: 增量追赶（2 天）
+  - 基于 binlog 增量同步
+  - 追赶完成后，新旧数据延迟 < 1 秒
+
+Phase 4: 双写切换（1 周）
+  - 先切读（灰度 10% → 100%）
+  - 再切写（灰度 1% → 100%）
+  - 对账任务持续运行
+
+Phase 5: 旧库下线（2 周后）
+  - 观察稳定后下线旧 order_db
+```
+
+### 4.6 阶段三结果
+
+| 指标 | 分片前 | 分片后 |
+|------|--------|--------|
+| 单表行数 | 8 亿 | 平均 78 万（最大 120 万） |
+| 单表大小 | 380GB | 平均 370MB |
+| 写入 QPS 承载 | 4,500 | 20,000+ |
+| 按用户查询 P99 | 1.2s | 15ms |
+| 索引大小 | 120GB | 每表 < 500MB（全部 in memory） |
+| DDL 执行时间 | 8 小时 | 每表 < 3 秒 |
+
+**实施周期**：6 周
+
+---
+
+## 五、三阶段总结
+
+### 5.1 全局对比
+
+| 指标 | 2022 初（单实例） | 2022 Q2（读写分离） | 2023 Q4（垂直拆分） | 2024 Q2（水平分片） |
+|------|-------------------|---------------------|---------------------|---------------------|
+| 承载 QPS | 10,000 | 35,000 | 60,000 | 150,000+ |
+| 数据库实例数 | 1 | 4 | 12 | 20 |
+| 运维复杂度 | 低 | 中 | 中高 | 高 |
+| 查询 P99 | 450ms | 85ms | 45ms | 15ms |
+| 硬件成本/月 | 2 万 | 4.5 万 | 12 万 | 18 万 |
+| 可用性 | 99.5% | 99.9% | 99.95% | 99.99% |
+
+### 5.2 成本效益分析
+
+```
+数据库成本增长：2 万 → 18 万/月（9 倍）
+业务规模增长：日活 50 万 → 400 万（8 倍）
+单用户数据库成本：0.04 元 → 0.045 元（基本持平）
+```
+
+---
+
+## 六、经验教训
+
+### 6.1 做对的事
+
+1. **渐进式演进**：每次只解决当前最紧迫的问题，不过度设计。初期如果直接上分库分表，团队能力和业务规模都不匹配
+2. **数据迁移零丢失**：三次数据迁移均通过双写 + 对账机制保证零数据丢失
+3. **分片键深思熟虑**：user_id 作为分片键覆盖了 95% 的查询场景，避免了大量跨片查询
+4. **ID 设计前瞻性**：自定义雪花算法在 ID 中编码了路由信息，简化了查询路由
+
+### 6.2 做错的事
+
+1. **跨库 JOIN 改造低估工期**：预估 2 周，实际花了 4 周，因为隐藏的跨库依赖比预期多 60%
+2. **监控滞后**：垂直拆分后没有及时建立跨库的统一监控，问题定位效率下降
+3. **分片后的运维工具缺失**：分片后才发现缺少批量 DDL 工具、跨片数据查询工具，临时开发耽误 2 周
+4. **测试覆盖不足**：分片后的边界场景（分片键为 0、极大值、NULL）在初期测试中遗漏
+
+### 6.3 关键认知
+
+- 数据库扩展不是一步到位的，应该跟随业务增长节奏渐进演进
+- 每次架构升级都增加运维复杂度，必须同步提升运维工具和团队能力
+- 分片是最后手段，在此之前应充分利用缓存、读写分离、垂直拆分
+- 数据迁移的风险远大于代码变更，必须有完善的对账和回滚机制
+
+---
+
+## Agent Checklist
+
+在 AI Agent 辅助执行数据库扩展任务时，应逐项确认：
+
+### 读写分离
+- [ ] **复制延迟**：是否评估了主从复制延迟对业务的影响
+- [ ] **路由策略**：是否明确了哪些查询走主库、哪些走从库
+- [ ] **一致性方案**：写后读场景是否有主库路由或延迟感知机制
+- [ ] **故障切换**：从库故障时是否能自动摘除，主库故障时是否有自动切换
+
+### 垂直拆分
+- [ ] **拆分边界**：是否按业务域划分了清晰的数据库边界
+- [ ] **跨库依赖**：是否梳理并处理了所有跨库 JOIN 和事务
+- [ ] **数据冗余**：高频跨库查询是否通过冗余字段解决
+- [ ] **分布式事务**：跨库写操作是否有一致性保障方案
+
+### 水平分片
+- [ ] **分片键选择**：分片键是否覆盖了大部分查询条件
+- [ ] **数据均匀性**：分片后数据分布是否均匀，是否有热点分片
+- [ ] **全局 ID**：是否设计了分布式唯一 ID 方案
+- [ ] **跨片查询**：无分片键的查询是否有处理方案（扇出 / 宽表 / ES）
+- [ ] **DDL 工具**：是否有批量执行 DDL 的工具
+- [ ] **扩容方案**：未来分片数不够时，是否有扩容方案（一致性哈希/虚拟分片）
+
+### 通用
+- [ ] **数据迁移**：是否有双写 + 对账 + 回滚的完整迁移方案
+- [ ] **压测验证**：迁移后是否通过压测验证了性能和容量
+- [ ] **监控覆盖**：是否建立了跨实例/跨库的统一监控看板
+- [ ] **备份策略**：拆分/分片后的备份策略是否调整
+- [ ] **回滚预案**：每个阶段是否有明确的回滚步骤和触发条件