「1024 TiDB AIGC 黑客松」Region 的一生
【作品名称】Region 的一生
【选择的创作方向】产品特性解读 / 技术概念可视化
【作品形式】AI 漫画 / 条漫（6 格，一张总图）+ 技术短文
【作品介绍/描述】用六格漫画把 TiDB 的数据分片写成一段 Region 的一生：建表时独自诞生，长大后分裂，三副本投票写入，热点时被压垮，再由 PD 调度搬家。第一人称讲清 Multi-Raft 与弹性扩展。
【使用的 AIGC 工具】Cursor（选题、分镜、文案与技术校对）；图像生成模型（六格漫画，画面内不放中文，文案全部后制）
【是否有传播到社媒】暂无
作品展示
活动对漫画的硬性要求是「系列漫画，不少于 4 格」，没有规定必须一张还是分张。发帖时先上传总图 region-life-strip.png（一张里能数出 6 格），分页可选。
总图用于一眼看完整故事。下面 6 张分页补对白和技术说明；画面内不放汉字，避免生成乱码。
第 1 格｜我诞生那天，整张表只有我一个
Region： 一张新表刚建出来。按默认行为，行数据往往先落在一个 Region 里。那时候公路很空，机架很远，我一个人站在整条 Key 空间的入口。
业务侧只看见 CREATE TABLE 成功了。没有人会想起我。
第 2 格｜我长到边界，就被一劈为二
Region： 连续的 Key 会堆在一起。体积过了分裂阈值，我就得把自己让出去。左边一段 [StartKey, SplitKey)，右边一段 [SplitKey, EndKey)。
这不是故障，这是长大。TiKV 把一张无限大的有序 Map，切成可以搬家的小块。默认大小随版本和配置变化：早期常见约 96 MiB，较新集群也可以配到约 256 MiB。
第 3 格｜我不是一个人住：两票，字才能落下
Region： 我有几个副本，默认常常是三个，各自待在不同的 TiKV 节点上。我们组成一个 Raft Group。其中一个是 Leader，读写默认找它；另外的是 Follower，跟着复制日志。
写请求不是喊一声就结束。多数副本确认，这次变更才算安全落下。一台机器暗下去，只要多数还在，字还在。这就是 Multi-Raft：不是整个集群共用一个 Raft，而是每个 Region 自己有一组票。集群变大，投票单元也跟着变多，而不是把所有数据绑死在同一组副本上。
第 4 格｜有一次，所有流量都砸在我头上
Region： 那天不是我太大，是我太热。
自增主键、单调时间戳、新建表后立刻高并发写入——请求都挤进同一段 Key。PD 可以把我从这台机器搬到那台机器，可调度的最小单位就是我。一个热点 Region 被搬走，火也跟着走，只是换了一台机器接着烧。
远处那些空闲的兄弟帮不上忙。它们不在我的 Key 范围里。
第 5 格｜楼上有人看全局：叫 PD
Region： 我看不见全图。看见全图的是 PD。
TiKV 节点用心跳汇报磁盘、Region 数量、是否过载；每个 Raft Group 的 Leader 也汇报自己在哪、副本在哪、读写有多快。PD 拿这些信息做调度，常用动作其实就几类：
- 副本不够，补一个；副本太多，删一个
- Leader 扎堆，把 Leader 转走
- 节点要下线，先把我搬空
- 我太大，建议分裂；我太小，可能合并
调度会占网络、磁盘和 CPU，所以速度被故意按住。扩容不是“加一台立刻均分”，而是 PD 按心跳把 Region 一批一批迁过去。
面对我这种单点热点，光搬家不够。还需要把我切开：自动的 Load Base Split，或建表时的 SHARD_ROW_ID_BITS / AUTO_RANDOM / PRE_SPLIT_REGIONS，以及手动的 SPLIT TABLE。切开以后，流量才有机会落到不同的 Leader 上。
第 6 格｜他们只看见：成功
Region： 手机亮了一下。对用户来说，这是一笔订单。对 SQL 来说，这是一次提交。对我来说，这是 Leader 收下提案，多数副本写下日志。
他们不会念我的 Region ID。
他们也不需要念。
复杂留在地下。地面上只需要一次成功。
创作说明
很多人第一次接触平凯数据库 / TiDB，会把它理解成「能水平扩展的 MySQL」。这句话能上手，但解释不了监控里为什么会出现几万个 Region，也解释不了为什么加了 TiKV，写入却还打在少数几台机器上。
我把底层三件套画成一个人的一生：
| 格子 | 产品能力 | 想让读者带走的一句 |
|---|---|---|
| 诞生 | 按 Key 范围切分 | 表是 SQL 的单位，Region 才是存储和调度的单位 |
| 分裂 | 水平扩展的基本动作 | 数据不是「一块盘」，是可以搬家的一段区间 |
| 投票 | Multi-Raft 多副本 | 写入看多数派，不是看集群里有多少台机器 |
| 热点 | 单 Region 瓶颈 | 搬节点搬不散一把火，得把这段 Key 切开 |
| 调度 | PD Placement Driver | 心跳收集全局，再建议 Leader 执行 Add/Remove/Transfer/Split |
| 地面 | 对业务的意义 | 用户看见成功，是因为地下还在投票、分裂和搬家 |
几个容易混的点，单独写清
1. Region 和表不是一回事。
一张表可以对应很多 Region；一个 Region 只覆盖一段连续 Key。索引通常还有自己的 Key 空间，也会形成 Region。所以「这张表很热」有时其实是「某段主键或某段索引很热」。
2. 副本数和 TiKV 台数不是一回事。
默认三副本时，一个 Region 只需要三份。集群从 3 台扩到 30 台，每个 Region 仍然是三副本，只是这些副本可以被调度到更多节点上。扩展的是容量和并行度，不是把每条记录复制 30 份。
3. PD 的指令是建议，不是魔法。
调度通过 Region Leader 的心跳带回操作。Leader 会按自身状态决定何时执行。所以你在监控里看到 operator，不代表下一秒拓扑已经变完。
4. 下线有中间态。
心跳丢失先会 Disconnect；超过 max-store-down-time（常见默认 30 分钟）才进入 Down，并开始补副本。手动下线则走 Offline：先把 Region 搬空，再进入 Tombstone。没搬空就关机器，等于主动制造缺副本。
5. 热点有两类，解法不同。
- 许多热 Region 堆在少数 Store 上：PD 可以把它们打散。
- 极少数 Region 自己就热：必须分裂、打散写入键，或改表设计。Load Base Split 会在读 QPS / 流量 / 读线程 CPU 持续超阈值后尝试找一个更均衡的切点；它对「单行被疯狂点查」这类切不开的热点，帮助有限。
为什么用第一人称，而不是架构图
架构图能把 TiDB、PD、TiKV 画全，但读者的眼睛会停在框上。Region 才是那条每天都在发生的生产线：诞生、长大、投票、过热、搬家。把它写成「我」，是为了让 Multi-Raft 和 PD 调度从名词变成情节。
漫画分镜由 Cursor 辅助完成，画面用图像模型生成后人工挑选；中文全部后制，避免模型把字画飘。技术表述对照了 TiDB 文档中心的存储、调度、热点处理与 Split Region 说明，并做了版本差异标注。画面是示意，不是运行手册。
留给社区的一句话
看见 Region，才算看见 TiDB。
扩容是把一段段 Key 搬走；可靠是让多数副本先举手；变快有时不是加机器，而是别让所有请求排进同一扇门。