Day06｜用生产硬核笔记逆向解构《DDIA》：数据分区与高并发局部战争的路由抽象
文章目录
- Day06｜Partitioning：数据分区不是切分表，而是高并发下的局部战争与路由失配
- 0. 本篇边界：哪些内容必须砍掉？
- 本篇保留
- 本篇不写成
- 1. 案例原文 / 关联原文链接映射
- 2. Day06 总纲：分区不是切表，而是切负载、状态和故障半径
- 3. 第一刀：砍掉“哈希分片包治百病”的乌托邦
- 3.1 教科书式幻觉
- 3.2 名人效应：哈希无法拯救 Hot Key
- 3.3 热点不是数据倾斜，而是请求倾斜
- 3.4 打破确定性：人为把一个逻辑 Key 撕成多个物理 Key
- 3.5 反证思维：热点 Key 能否完全靠数据库自动处理？
- 4. 第二刀：砍掉二级索引的平庸对比
- 4.1 教科书式幻觉
- 4.2 场景一：本地二级索引的 Scatter-Gather 尾延时屠杀
- 4.3 Scatter-Gather 的隐藏成本
- 4.4 场景二：全局二级索引的分布式事务暗箭
- 4.5 反证思维：全局索引是不是 Scatter-Gather 的完美解？
- 5. 第三刀：砍掉“自动化再平衡”的运维幻觉
- 5.1 教科书式幻觉
- 5.2 死亡之风：自动再平衡如何放大故障
- 5.3 自动化的边界：自动路由可以，自动迁移要谨慎
- 5.4 再平衡不是扩容，是状态债务转移
- 5.5 反证思维：自动再平衡越快越好吗？
- 6. 路由失配：分区以后，最难的是客户端如何找到正确分区
- 6.1 分区让路由成为系统核心
- 6.2 路由缓存陈旧：客户端找到旧分区
- 6.3 路由失配与 K8s 辅助类比
- 6.4 架构治理机制
- 7. Day06 提炼出的新分区模板
- 示例一：热点商品 Key 打爆单分区
- 示例二：本地二级索引导致 Scatter-Gather P999 飙升
- 示例三：全局二级索引异步更新导致搜索幻觉
- 示例四：自动再平衡诱发集群雪崩
- 8. Day06 最终收束
- 9. Day07 预告：第七章 Transactions
Day06｜Partitioning：数据分区不是切分表，而是高并发下的局部战争与路由失配
Day01 讨论故障传播、负载放大、状态不可见。
Day02 讨论数据模型如何决定系统能看见什么关系。
Day03 讨论存储结构如何决定状态复制、状态迁移和恢复边界。
Day04 讨论编码演进如何保证新旧组件共同理解同一份状态。
Day05 讨论 Replication 如何把一致性问题包装成副本时空错乱。
Day06 进入 DDIA 第六章：Partitioning。
这一章不能写成“分库分表中间件配置手册”。
分区的本质从来不是把大表切小，而是：在物理世界的无序中，强行划分负载、状态和权力的边界。
0. 本篇边界：哪些内容必须砍掉？
为了不把 Day06 写成普通分库分表教程，先明确本篇边界。
本篇保留
1. 热点 Key： 为什么哈希只能打散 Key，不能打散流量。 2. 二级索引： 为什么本地二级索引会制造 Scatter-Gather 尾延时地狱； 为什么全局二级索引会把单机写入逼成分布式事务。 3. 再平衡： 为什么自动化迁移状态可能把局部故障放大成全集群雪崩。 4. 路由失配： 为什么分区之后最难的不是数据切开，而是客户端、代理、控制面如何找到正确分区。本篇不写成
一致性哈希概念介绍； 范围分片 vs 哈希分片优缺点表； 分库分表中间件功能说明； 数据库扩容操作手册； K8s 调度理论混入数据分区主线。K8s Zone、Pod Pending、PVC 绑定、节点标签、网络路径可以作为“位置约束失配”的辅助类比，但不能喧宾夺主。
Day06 的主角仍然是数据分区。
1. 案例原文 / 关联原文链接映射
| 正文案例 | 原文 / 关联原文链接 | 说明 |
|---|---|---|
| 技术笔记总入口 | 喝醉酒的小白 CSDN 主页 | 公开主页 |
| OceanBase 备份与高可用 | OceanBase 数据库备份与高可用全面解析：策略、架构与实践 | 分布式数据库、多副本、备份恢复 |
| 平台备份 / NFS / S3 | QFusion 数据库私有云平台研究报告 | 备份存储、NFS、对象存储 |
| K8s 高可用 / 动态演进 | Kubernetes 高可用与动态演进技术笔记（最终版） | 调度、PDB、HPA/VPA、节点状态 |
| CNI / CSI / CRI | Kubernetes CNI、CSI 和 CRI 深度解析：技术实施与架构设计 | 网络、存储、运行时接口 |
| 网络路径 / VIP / 多网卡 | 业务流量进出路径：来包由谁决定，回包由谁决定 | 路由、网络路径、回包 |
| TiDB Shard Row ID Bits | TiDB Shard Row ID Bits | 写入热点打散 |
| TiDB Hotspot | Troubleshoot Hotspot Issues | 热点问题定位 |
| TiDB Placement Rules | Placement Rules in SQL | 数据位置约束 |
| Vitess Vindex | Vitess Vindexes | 分片路由、索引到 keyspace id |
| Cassandra Partition | Apache Cassandra Data Partitioning | Partition key、token、Dynamo 风格 |
| Dynamo Paper | Dynamo: Amazon’s Highly Available Key-value Store | partition、preference list、hinted handoff |
| 热点 Key / 秒杀商品 | 内部案例，暂无公开原文 | 单 Key 流量超过单分区能力 |
| 本地二级索引 Scatter-Gather | 内部案例，暂无公开原文 | 搜索条件与分区键不一致 |
| 全局二级索引异步更新 | 内部案例，暂无公开原文 | 搜索到对象但对象不存在 |
| 自动再平衡诱发雪崩 | 内部案例，暂无公开原文 | 状态迁移抢占网络 / I/O |
| K8s Zone / PVC / Pod Pending | 内部案例，暂无公开原文 | 位置约束、调度、存储绑定失配 |
| 平台实例迁移 / 分片路由 | 内部案例，暂无公开原文 | 分区映射、路由缓存、迁移窗口 |
2. Day06 总纲：分区不是切表，而是切负载、状态和故障半径
DDIA 第六章讲 Partitioning。
普通读法会把它读成：
范围分区； 哈希分区； 一致性哈希； 二级索引； 再平衡； 请求路由；这些概念都对，但如果只停在这里，就会变成面试题。
Partitioning 真正要回答的是：
当单台机器无法承载全部数据和全部流量时， 系统如何把状态切成多个局部战场？分区的表面目标是：
数据变小； 查询变快； 容量变大； 集群可扩展；但它的真实代价是：
热点 Key 会把局部战场烧穿； 二级索引会把一次查询扩散到全局； 全局索引会把一次写入拖进分布式事务；