干这行的时间越长越发现一个有意思的规律很多系统刚开始跑得挺顺数据量到了几百万、上千万以后突然就开始频繁出问题——慢查询变多、单库连接被打满、写入开始排队。这时候大多数团队会想到拆库拆表但“拆”这个动作本身并不难难的是拆完之后的数据到底怎么组织、怎么定位、怎么扩容。这就是分区架构要回答的问题。这篇文章我想把分区架构这件事从头到尾聊透包括它到底解决什么、常见策略怎么选、路由和元数据是怎么回事、扩容时为什么容易翻车以及我在实际项目里踩过的坑和排查思路。无论你是后端开发、架构师还是DBA只要系统里数据量还在涨这篇都值得花几分钟过一遍。1. 先把概念理清楚分区、分片与“分库分表”的关系1.1 分区不是拆分本身而是数据的组织方式很多人容易把分区Partition、分片Shard、分库分表混在一起说其实它们是不同层面的东西。分库分表是一种物理拆分动作把原本在一张表、一个库里的数据搬到多个库里、多张表里而分区是决定“哪条数据应该放到哪个物理位置”的规则。打个比方分库分表是盖了好几栋楼分区是决定每家每户住哪栋楼、哪个房间的分配方案。楼盖好了但住户乱住或者分配规则不稳定后面一定出问题。在分布式系统里分区这个词含义更宽。Kafka把一个Topic切成多个Partition每个Partition是一个有序日志Redis Cluster把key空间切成16384个槽位MySQL的InnoDB也支持表分区Range、Hash、List等。它们形态不同但本质都是同一件事把大数据切分成小数据让每个节点只处理一部分整体吞吐和容量才能线性扩展。所以理解分区架构核心不在于“切”这个动作而在于一套完整的分配规则、寻址方式和迁移机制。你决定用哪个字段做分片键、映射到哪个分区、分区数怎么定、扩容时怎么迁移这些加起来才是完整的架构。1.2 分区架构设计不当后期要付出多少代价我见过不止一个项目上线时图省事直接用主键取模分表比如user_id % 10一共10张表。前期数据量不大一切正常。等业务涨到一定程度需要扩容到20张表问题就来了原来user_id % 10 3的数据在扩容后可能要重新计算到3、13两个位置历史数据全部需要迁移而且迁移期间新旧路由必须同时兼容。更难受的是如果当初选了user_id作为分片键但业务经常按手机号或订单号查用户查询就会变成全分片扫描。这些都是典型的“分区架构设计不当”的代价。归纳起来常见的痛点有几类数据倾斜某个分区数据量或访问量远高于其他分区形成热点拖垮单个节点。路由不一致分区规则变了但历史数据没迁完老路由和新路由对不上读写错乱。扩容困难分区数固定、取模取死想要扩节点必须大规模迁移。跨分区查询成本高一次业务操作涉及多个分区的数据要么应用层聚合要么走汇总表复杂度直线上升。数据生命周期管理难不同时间的数据想冷热分离但分区规则不支持按时间切割归档无从下手。这些问题的共性是前期欠的债后期连本带利还。所以分区架构最关键的一点不是把数据拆开就完事而是要让数据分布、路由、扩容、迁移、查询模式形成一个整体上可控的闭环。2. 分区策略怎么选四种常用方案与选型要点2.1 范围分区直观但容易踩热点范围分区Range Partitioning是按某个字段的值区间来划分比如按用户ID的1~10000放分区010001~20000放分区1或者按时间2024年1月的数据放一月分区2024年2月放二月分区。这种方案的优点是规则直观DBA和开发都容易理解配合MySQL的表分区或PgSQL的声明式分区天然好用。范围分区最大的坑是热点问题。按时间分区尤其典型业务永远在写“当前”所以最近一个时间分区的写入压力远远高于历史分区所有写流量都打在同一块物理存储上。如果按ID范围分区也可能因为ID分配不均衡导致某个区间数据量暴涨。另外如果业务查询经常跨多个范围边界比如查“上个月到今天”的数据一个查询要扫好几个分区性能反而下降。范围分区适合什么场景日志归档、订单按月归档、时序数据这种“写最新、读老数据较少”且时间维度是主查询路径的业务。数据能按生命周期自然地冷热分层删旧数据直接Drop整个分区成本很低。但要注意这种方案对单分区的写入热点要有预案比如最近分区下面再做一层哈希子分区或者短期内接受单点写入瓶颈。2.2 哈希分区均匀性好扩容是难点哈希分区是生产环境用得最多的方案。最简单的形式是分片键的Hash值对分区数取模常见写法是partition hash(shard_key) % N。它能把数据较均匀地打散到各个节点上避免范围分区那种“最新数据全压一个节点”的热点问题。但这个方案有个经典陷阱一旦N定死后续扩容就是噩梦。比如N10时key的hash值对10取模扩容到20后原来落在分区3的数据新的映射可能落在3也可能落在13覆盖面变了几乎所有数据都要迁移。更麻烦的是取模期间如果有读写并发路由切换的瞬间数据位置和实际位置不一致就会出现查不到数据或者写入报错。为了规避这个问题很多系统引入了虚拟桶或一致性哈希。一致性哈希把哈希值域看成一个环节点映射到环上数据顺着环找到最近的节点。节点加减只影响相邻区间迁移量大幅降低。但一致性哈希也有缺点节点少时分布容易不均匀需要引入虚拟节点来平滑另外路由计算相对复杂不太适合直接在SQL层做。哈希分区适合用户表、订单表这类访问相对随机、对单条数据操作远多于范围扫描的业务。选它之前最好确认两点分片键本身基数足够大比如用户ID且业务不会频繁按其他维度全量扫描。2.3 列表分区和复合分区场景化兜底列表分区List Partitioning是按枚举值来划分比如把中国移动用户放到分区A、联通用户放到分区B、电信用户放到分区C。这种策略适合维度本身就有限且业务上天然按维度隔离的场景。缺点是如果某个枚举值的数据量特别大比如某个大客户占了80%订单还是会倾斜而且新增枚举值时要手动加分区。复合分区则是把多种策略叠加。比如先按时间做范围分区再在每个时间分区内按user_id做哈希子分区或者反过来先哈希后范围。复合分区的优势是能同时兼顾范围分区的时间裁剪和哈希分区的均匀性但实现复杂度和运维成本也高。选型时我的原则很简单能用范围解决的问题不用哈希能用哈希解决问题的不要上一致性哈希除非预期扩容非常频繁。复合分区只在大表、数据特征特别复杂时才考虑常规业务一套简单策略足够。2.4 分区策略对比与选型决策表策略类型数据均匀性热点风险扩容成本典型场景范围分区差易倾斜高最新区间易热低新范围直接加日志、时序数据、归档哈希取模好低但分片键分布差时会倾斜高需要全量迁移用户、订单等OLTP核心表一致性哈希较好低虚拟节点可平滑较低只影响邻近区间缓存、分布式存储、频繁扩缩容场景列表分区取决于枚举分布高大枚举值易成热点低手动Add分区按地域、客户、租户强隔离复合分区好低多维平滑中迁移复杂度高超大表、时间实体双维度查询看完这张表应该能明白分区策略没有绝对最优只有“对你的业务查询模式和数据特征是否合适”。选型时多问一句——“这条数据将来会怎么被读到”比什么高深的算法都管用。3. 路由与元数据分区架构的“寻址系统”3.1 三种路由模式客户端路由、代理路由、中心元数据设计好分区规则之后下一个核心问题是当一个读写请求进来系统怎么知道目标数据在哪一个分区这就是路由Routing。第一种是客户端路由也就是应用侧自己集成路由算法根据分片键直接计算目标分区。早期的分库分表框架就是这么做的优点是性能好、没有额外网络跳缺点是路由规则散落在所有业务代码里规则一旦变更所有客户端都要跟着升级很容易出现“老服务还在用老规则”的兼容问题。第二种是代理路由中间加一层代理服务应用只和代理通信代理负责解析SQL、路由转发和结果聚合。好处是业务侧无感知、升级路由不用改应用坏处是引入额外一跳延迟和吞吐有损耗而且代理本身成了新的瓶颈和高可用风险点。第三种是中心元数据路由系统里有一个独立的元数据服务保存“分片键值范围到分区地址”的映射关系。客户端先查元数据拿到目标分区地址再直连分区读写。很多分布式数据库产品内部都采用这种思路。它的灵活性最高支持动态迁移和路由切换但元数据中心自身需要高可用而且要不引入过大延迟通常需要客户端缓存元数据并监听变更通知。给个直觉类比客户端路由是每个人手里拿着一本通讯录代理路由是你打给总机总机帮你转接中心元数据是有一本权威黄页但大家会本地抄一份常用号码。三种没有绝对好坏取决于团队能接受多少运维复杂度。小规模系统用客户端路由最省事业务线多、规则变化频繁时代理路由或中心元数据更长期。3.2 再平衡扩容缩容时的分区迁移分区架构里真正见功力的环节是迁移也就是再平衡Rebalance。很多系统在设计初期没有为迁移留好接口一旦需要扩容就只能停服、离线迁移、再切流量整个过程胆战心惊。比较常见的再平衡思路有三种。第一种是全量重哈希适合分区少、数据量小、可以接受短停服的场景操作上就是算新路由、停写、搬数据、校验、切流。第二种是双写迁移新老路由并行一段时间写入同时发到新旧位置历史数据通过批处理回放核对一致后切读流量。第三种是槽位迁移像Redis Cluster那样把数据映射到固定数量的槽位上扩容时把一部分槽位从老节点搬到新节点搬完一个槽位就更新元数据整个集群对外持续可用。第三种方式在我个人看来是长期维护最舒服的形态。固定槽位数量例如16384意味着路由算法永远不用变变化的只是“槽位到物理节点”的映射表迁移粒度可以精确到槽位级别还能控制并发迁移速度。3.3 迁移期的一致性与可用性怎么保障迁移过程中的核心难点有两个一是迁过去的数据和源端一致二是迁移期间读写不能乱。保证一致性的常见做法是快照增量回放。先把源分区某一时刻的快照拷贝到目标分区然后持续同步增量日志比如Binlog或者消息流直到增量追平。追平之后还需要做一次逐条校验或摘要校验比如对比主键集合、行数和字段校验和。这一步非常关键因为网络传输、并发写入都可能导致漏数据或重复数据。校验通过后把路由元数据原子切换切换瞬间新建的连接走新路由已经在传输中的请求要等待处理完成或重试。可用性方面我踩过的坑是迁移时只关注数据有没有搬完忽略了业务流量切到新分区之前老分区还承担全部读写压力。迁移速度和业务负载是互相拉扯的如果副本同步追不上新写入速度迁移任务会被无限拖延。所以一定要给迁移任务设置“追平”和“限流”机制——比如按主键范围分批搬、控制每批次线程数同时监控源端延迟。延迟一旦拉大宁可暂时降低迁移速度也不能把业务拖垮。4. 从零设计一个分区系统五个落地步骤4.1 分片键选择第一个决定成败的决策分片键选对了后面所有事情都顺选错了架构怎么优化都别扭。我的经验里分片键必须同时满足四个条件基数足够高如果只有几种取值比如状态、性别哈希后也均匀不到哪去。访问足够分散业务请求均匀落在不同分片键上避免“一个超级会员占据所有流量”。和主要查询路径一致业务80%的查询都带上这个字段才能把查询路由限制到单分区。不可变或极少变化分片键一旦允许更新意味着数据可能要从一个分区搬到另一个分区成本和复杂度都很大。有一次我接手一个系统原有的分片键选的是订单ID查询量最大的却是“查某个用户的所有订单”。每次查询都不得不广播到所有分片再聚合性能非常差。后来把分片键改成用户ID单用户订单天然落在同一分区所有体验立刻改善。这就是分片键和查询模式匹配的意义。4.2 分区数与容量估算怎么算才不返工分区数量不是拍脑袋定的。我的建议是从三个约束倒推单分区数据量上限、单分区QPS上限、未来业务增长倍数。假设单节点单表数据量最好控制在2000万行以内这个值不是绝对的取决于字段宽度和索引大小但作为初始参考很实用当前预估数据量是5000万行未来三年按3倍增长到1.5亿行那最少需要8个分区才能容纳。QPS同理假设单分区能扛2000 QPS的读写混合业务峰值QPS是2万至少需要10个分区。取两个值中的较大值并预留50%~100%缓冲就得到初始分区数。这个概念用公式表达就是分区数 max(数据量预估 / 单分区容量上限, 峰值QPS / 单分区QPS上限) × 冗余系数冗余系数我建议至少取1.5到2。规则很简单分区数多一点前期成本和资源占用高一点但后续扩容压力小很多分区数少了很快就要面对痛苦的在线迁移。4.3 迁移方案设计先想好怎么变再动手分我做了几个系统之后越来越认同一个观点分区设计真正的工作量不在于“初始切分”而在于“后续变更”。所以设计阶段就考虑好未来怎么扩容、怎么改变分片键、怎么缩容比什么都重要。可行的迁移方案在4.2节已经提到如果用的是哈希取模最好先引入虚拟桶层。数据先hash到虚拟桶比如1024个桶再映射到物理分区。这样未来扩容只需要调整“桶到分区”的映射关系不需要重新哈希数据。比如当前只有8个物理分区每个分区挂128个桶以后扩到16个分区就把属于分区的桶分一半给新分区旧数据不用重算只需要迁移部分桶的数据。这个方案带来的设计复杂度不高但收益非常大。我强烈建议任何一个新的分区系统都采用虚拟桶一层。即使初期看起来“多了一层没必要的映射”等到第一次扩容你就会感谢当时多花的这一小时设计时间。5. 常见故障与排查实录5.1 数据倾斜分区之间大小差太多倾斜的表现很容易发现某个分区的磁盘使用率是其他分区的两倍以上或者一台机器慢慢被拖垮。原因要么是分片键选得不好要么是数据本身分布就畸形比如某个大客户贡献了大量订单。排查时先确认是不是天然倾斜用分片键做一次分组统计看每个值的行数分布。如果是少数大key导致的可以考虑把大key单独抽出来放一个分区再做二次分片如果整体分布就是歪的说明分片键选错了需要考虑重建分区或改换路由。注意大key治理没有通用银弹核心思路是“把大象从蚂蚁堆里分出去”。5.2 路由不一致数据已经迁走客户端还在读写这个问题最容易在迁移过程中爆发。元数据已经切换但客户端本地缓存的映射还没刷新于是请求按老路由打到旧分区结果数据已经搬走了响应结果缺失或写入失败。排查思路一般是三步。第一步检查客户端缓存的刷新机制是定时拉取还是监听推送刷新间隔多少。第二步看是否有流控或回滚机制一旦发现路由不一致能自动降级到“先查元数据再路由”。第三步如果是并发迁移时有短暂空窗要考虑在路由切换前设置一个短暂的“只读/拒绝写”保护期等旧连接排空再切。5.3 跨分区查询与事务限制怎么绕分区之后跨分区查询和分布式事务是最头疼的。单条SQL跨多个分区要么由中间层聚合要么应用层多个线程并行查询再合并排序。事务也一样多个分区之间无法用数据库原生事务保证ACID只能引入分布式事务方案而且代价不低。我的建议是做业务建模时就尽量避免。比如订单和订单明细放同一个分区用户和用户的账户放同一个分区让80%的操作变成单分区的本地操作。剩下的20%跨分区场景则尽量设计成最终一致通过消息对账去处理而不是强一致。你没法既要分区扩展性又要所有操作都像单库一样简单这个取舍必须做在前面。5.4 监控指标分区架构要盯哪些数最后分享一个我长期维护分区系统时总结的监控清单。这些指标不需要很复杂但每一个都对应一类故障各分区数据量方差和最大值用来提前发现倾斜。各分区QPS、CPU、磁盘IO分布用来发现热点访问。分区迁移任务的追平延迟和迁移速率用来评估扩容健康度。路由命中率和缓存刷新耗时用来保障寻址及时。跨分区请求占比用来评估业务演进是否偏离分区设计。这些指标统一上报到监控系统后我习惯给“最大分区数据量”和“分区QPS标准差”各设一条报警。报警阈值可以按实际基线调整但只要这两个指标异常基本都意味着分区架构正在劣化值得立即介入。最后说几句实在的这几年看下来分区架构的成败往往不是技术深度决定的而是设计的克制程度决定的。很多人一上来就上非常复杂的动态扩容、自动再平衡、复合分区最后维护成本高到下不了台。实际上绝大多数业务一个稳定分片键加虚拟桶、固定槽位映射、完善的迁移工具就够了。复杂方案的特性和它带来的额外故障可能性是成正比的没必要为了展示架构能力而给自己挖坑。另外无论选哪种方案都建议把“数据迁移”当作一等公民来设计。架构这个词听起来很宏大但真正考验你的往往是某次凌晨扩容时数据能否在业务无感知的情况下安全挪动。设计分区规则可能只需要一天但写迁移工具、做一致性校验、演练回滚流程可能得花一个月。这些功夫看起来不亮眼但它们才是分区架构能长期平稳运行的底气。 
长河君 · 2026/10/17 5:51:35 · 阅读 1.2k 数据分区架构设计实战：从分片键到扩容迁移
干这行的时间越长越发现一个有意思的规律很多系统刚开始跑得挺顺数据量到了几百万、上千万以后突然就开始频繁出问题——慢查询变多、单库连接被打满、写入开始排队。这时候大多数团队会想到拆库拆表但“拆”这个动作本身并不难难的是拆完之后的数据到底怎么组织、怎么定位、怎么扩容。这就是分区架构要回答的问题。这篇文章我想把分区架构这件事从头到尾聊透包括它到底解决什么、常见策略怎么选、路由和元数据是怎么回事、扩容时为什么容易翻车以及我在实际项目里踩过的坑和排查思路。无论你是后端开发、架构师还是DBA只要系统里数据量还在涨这篇都值得花几分钟过一遍。1. 先把概念理清楚分区、分片与“分库分表”的关系1.1 分区不是拆分本身而是数据的组织方式很多人容易把分区Partition、分片Shard、分库分表混在一起说其实它们是不同层面的东西。分库分表是一种物理拆分动作把原本在一张表、一个库里的数据搬到多个库里、多张表里而分区是决定“哪条数据应该放到哪个物理位置”的规则。打个比方分库分表是盖了好几栋楼分区是决定每家每户住哪栋楼、哪个房间的分配方案。楼盖好了但住户乱住或者分配规则不稳定后面一定出问题。在分布式系统里分区这个词含义更宽。Kafka把一个Topic切成多个Partition每个Partition是一个有序日志Redis Cluster把key空间切成16384个槽位MySQL的InnoDB也支持表分区Range、Hash、List等。它们形态不同但本质都是同一件事把大数据切分成小数据让每个节点只处理一部分整体吞吐和容量才能线性扩展。所以理解分区架构核心不在于“切”这个动作而在于一套完整的分配规则、寻址方式和迁移机制。你决定用哪个字段做分片键、映射到哪个分区、分区数怎么定、扩容时怎么迁移这些加起来才是完整的架构。1.2 分区架构设计不当后期要付出多少代价我见过不止一个项目上线时图省事直接用主键取模分表比如user_id % 10一共10张表。前期数据量不大一切正常。等业务涨到一定程度需要扩容到20张表问题就来了原来user_id % 10 3的数据在扩容后可能要重新计算到3、13两个位置历史数据全部需要迁移而且迁移期间新旧路由必须同时兼容。更难受的是如果当初选了user_id作为分片键但业务经常按手机号或订单号查用户查询就会变成全分片扫描。这些都是典型的“分区架构设计不当”的代价。归纳起来常见的痛点有几类数据倾斜某个分区数据量或访问量远高于其他分区形成热点拖垮单个节点。路由不一致分区规则变了但历史数据没迁完老路由和新路由对不上读写错乱。扩容困难分区数固定、取模取死想要扩节点必须大规模迁移。跨分区查询成本高一次业务操作涉及多个分区的数据要么应用层聚合要么走汇总表复杂度直线上升。数据生命周期管理难不同时间的数据想冷热分离但分区规则不支持按时间切割归档无从下手。这些问题的共性是前期欠的债后期连本带利还。所以分区架构最关键的一点不是把数据拆开就完事而是要让数据分布、路由、扩容、迁移、查询模式形成一个整体上可控的闭环。2. 分区策略怎么选四种常用方案与选型要点2.1 范围分区直观但容易踩热点范围分区Range Partitioning是按某个字段的值区间来划分比如按用户ID的1~10000放分区010001~20000放分区1或者按时间2024年1月的数据放一月分区2024年2月放二月分区。这种方案的优点是规则直观DBA和开发都容易理解配合MySQL的表分区或PgSQL的声明式分区天然好用。范围分区最大的坑是热点问题。按时间分区尤其典型业务永远在写“当前”所以最近一个时间分区的写入压力远远高于历史分区所有写流量都打在同一块物理存储上。如果按ID范围分区也可能因为ID分配不均衡导致某个区间数据量暴涨。另外如果业务查询经常跨多个范围边界比如查“上个月到今天”的数据一个查询要扫好几个分区性能反而下降。范围分区适合什么场景日志归档、订单按月归档、时序数据这种“写最新、读老数据较少”且时间维度是主查询路径的业务。数据能按生命周期自然地冷热分层删旧数据直接Drop整个分区成本很低。但要注意这种方案对单分区的写入热点要有预案比如最近分区下面再做一层哈希子分区或者短期内接受单点写入瓶颈。2.2 哈希分区均匀性好扩容是难点哈希分区是生产环境用得最多的方案。最简单的形式是分片键的Hash值对分区数取模常见写法是partition hash(shard_key) % N。它能把数据较均匀地打散到各个节点上避免范围分区那种“最新数据全压一个节点”的热点问题。但这个方案有个经典陷阱一旦N定死后续扩容就是噩梦。比如N10时key的hash值对10取模扩容到20后原来落在分区3的数据新的映射可能落在3也可能落在13覆盖面变了几乎所有数据都要迁移。更麻烦的是取模期间如果有读写并发路由切换的瞬间数据位置和实际位置不一致就会出现查不到数据或者写入报错。为了规避这个问题很多系统引入了虚拟桶或一致性哈希。一致性哈希把哈希值域看成一个环节点映射到环上数据顺着环找到最近的节点。节点加减只影响相邻区间迁移量大幅降低。但一致性哈希也有缺点节点少时分布容易不均匀需要引入虚拟节点来平滑另外路由计算相对复杂不太适合直接在SQL层做。哈希分区适合用户表、订单表这类访问相对随机、对单条数据操作远多于范围扫描的业务。选它之前最好确认两点分片键本身基数足够大比如用户ID且业务不会频繁按其他维度全量扫描。2.3 列表分区和复合分区场景化兜底列表分区List Partitioning是按枚举值来划分比如把中国移动用户放到分区A、联通用户放到分区B、电信用户放到分区C。这种策略适合维度本身就有限且业务上天然按维度隔离的场景。缺点是如果某个枚举值的数据量特别大比如某个大客户占了80%订单还是会倾斜而且新增枚举值时要手动加分区。复合分区则是把多种策略叠加。比如先按时间做范围分区再在每个时间分区内按user_id做哈希子分区或者反过来先哈希后范围。复合分区的优势是能同时兼顾范围分区的时间裁剪和哈希分区的均匀性但实现复杂度和运维成本也高。选型时我的原则很简单能用范围解决的问题不用哈希能用哈希解决问题的不要上一致性哈希除非预期扩容非常频繁。复合分区只在大表、数据特征特别复杂时才考虑常规业务一套简单策略足够。2.4 分区策略对比与选型决策表策略类型数据均匀性热点风险扩容成本典型场景范围分区差易倾斜高最新区间易热低新范围直接加日志、时序数据、归档哈希取模好低但分片键分布差时会倾斜高需要全量迁移用户、订单等OLTP核心表一致性哈希较好低虚拟节点可平滑较低只影响邻近区间缓存、分布式存储、频繁扩缩容场景列表分区取决于枚举分布高大枚举值易成热点低手动Add分区按地域、客户、租户强隔离复合分区好低多维平滑中迁移复杂度高超大表、时间实体双维度查询看完这张表应该能明白分区策略没有绝对最优只有“对你的业务查询模式和数据特征是否合适”。选型时多问一句——“这条数据将来会怎么被读到”比什么高深的算法都管用。3. 路由与元数据分区架构的“寻址系统”3.1 三种路由模式客户端路由、代理路由、中心元数据设计好分区规则之后下一个核心问题是当一个读写请求进来系统怎么知道目标数据在哪一个分区这就是路由Routing。第一种是客户端路由也就是应用侧自己集成路由算法根据分片键直接计算目标分区。早期的分库分表框架就是这么做的优点是性能好、没有额外网络跳缺点是路由规则散落在所有业务代码里规则一旦变更所有客户端都要跟着升级很容易出现“老服务还在用老规则”的兼容问题。第二种是代理路由中间加一层代理服务应用只和代理通信代理负责解析SQL、路由转发和结果聚合。好处是业务侧无感知、升级路由不用改应用坏处是引入额外一跳延迟和吞吐有损耗而且代理本身成了新的瓶颈和高可用风险点。第三种是中心元数据路由系统里有一个独立的元数据服务保存“分片键值范围到分区地址”的映射关系。客户端先查元数据拿到目标分区地址再直连分区读写。很多分布式数据库产品内部都采用这种思路。它的灵活性最高支持动态迁移和路由切换但元数据中心自身需要高可用而且要不引入过大延迟通常需要客户端缓存元数据并监听变更通知。给个直觉类比客户端路由是每个人手里拿着一本通讯录代理路由是你打给总机总机帮你转接中心元数据是有一本权威黄页但大家会本地抄一份常用号码。三种没有绝对好坏取决于团队能接受多少运维复杂度。小规模系统用客户端路由最省事业务线多、规则变化频繁时代理路由或中心元数据更长期。3.2 再平衡扩容缩容时的分区迁移分区架构里真正见功力的环节是迁移也就是再平衡Rebalance。很多系统在设计初期没有为迁移留好接口一旦需要扩容就只能停服、离线迁移、再切流量整个过程胆战心惊。比较常见的再平衡思路有三种。第一种是全量重哈希适合分区少、数据量小、可以接受短停服的场景操作上就是算新路由、停写、搬数据、校验、切流。第二种是双写迁移新老路由并行一段时间写入同时发到新旧位置历史数据通过批处理回放核对一致后切读流量。第三种是槽位迁移像Redis Cluster那样把数据映射到固定数量的槽位上扩容时把一部分槽位从老节点搬到新节点搬完一个槽位就更新元数据整个集群对外持续可用。第三种方式在我个人看来是长期维护最舒服的形态。固定槽位数量例如16384意味着路由算法永远不用变变化的只是“槽位到物理节点”的映射表迁移粒度可以精确到槽位级别还能控制并发迁移速度。3.3 迁移期的一致性与可用性怎么保障迁移过程中的核心难点有两个一是迁过去的数据和源端一致二是迁移期间读写不能乱。保证一致性的常见做法是快照增量回放。先把源分区某一时刻的快照拷贝到目标分区然后持续同步增量日志比如Binlog或者消息流直到增量追平。追平之后还需要做一次逐条校验或摘要校验比如对比主键集合、行数和字段校验和。这一步非常关键因为网络传输、并发写入都可能导致漏数据或重复数据。校验通过后把路由元数据原子切换切换瞬间新建的连接走新路由已经在传输中的请求要等待处理完成或重试。可用性方面我踩过的坑是迁移时只关注数据有没有搬完忽略了业务流量切到新分区之前老分区还承担全部读写压力。迁移速度和业务负载是互相拉扯的如果副本同步追不上新写入速度迁移任务会被无限拖延。所以一定要给迁移任务设置“追平”和“限流”机制——比如按主键范围分批搬、控制每批次线程数同时监控源端延迟。延迟一旦拉大宁可暂时降低迁移速度也不能把业务拖垮。4. 从零设计一个分区系统五个落地步骤4.1 分片键选择第一个决定成败的决策分片键选对了后面所有事情都顺选错了架构怎么优化都别扭。我的经验里分片键必须同时满足四个条件基数足够高如果只有几种取值比如状态、性别哈希后也均匀不到哪去。访问足够分散业务请求均匀落在不同分片键上避免“一个超级会员占据所有流量”。和主要查询路径一致业务80%的查询都带上这个字段才能把查询路由限制到单分区。不可变或极少变化分片键一旦允许更新意味着数据可能要从一个分区搬到另一个分区成本和复杂度都很大。有一次我接手一个系统原有的分片键选的是订单ID查询量最大的却是“查某个用户的所有订单”。每次查询都不得不广播到所有分片再聚合性能非常差。后来把分片键改成用户ID单用户订单天然落在同一分区所有体验立刻改善。这就是分片键和查询模式匹配的意义。4.2 分区数与容量估算怎么算才不返工分区数量不是拍脑袋定的。我的建议是从三个约束倒推单分区数据量上限、单分区QPS上限、未来业务增长倍数。假设单节点单表数据量最好控制在2000万行以内这个值不是绝对的取决于字段宽度和索引大小但作为初始参考很实用当前预估数据量是5000万行未来三年按3倍增长到1.5亿行那最少需要8个分区才能容纳。QPS同理假设单分区能扛2000 QPS的读写混合业务峰值QPS是2万至少需要10个分区。取两个值中的较大值并预留50%~100%缓冲就得到初始分区数。这个概念用公式表达就是分区数 max(数据量预估 / 单分区容量上限, 峰值QPS / 单分区QPS上限) × 冗余系数冗余系数我建议至少取1.5到2。规则很简单分区数多一点前期成本和资源占用高一点但后续扩容压力小很多分区数少了很快就要面对痛苦的在线迁移。4.3 迁移方案设计先想好怎么变再动手分我做了几个系统之后越来越认同一个观点分区设计真正的工作量不在于“初始切分”而在于“后续变更”。所以设计阶段就考虑好未来怎么扩容、怎么改变分片键、怎么缩容比什么都重要。可行的迁移方案在4.2节已经提到如果用的是哈希取模最好先引入虚拟桶层。数据先hash到虚拟桶比如1024个桶再映射到物理分区。这样未来扩容只需要调整“桶到分区”的映射关系不需要重新哈希数据。比如当前只有8个物理分区每个分区挂128个桶以后扩到16个分区就把属于分区的桶分一半给新分区旧数据不用重算只需要迁移部分桶的数据。这个方案带来的设计复杂度不高但收益非常大。我强烈建议任何一个新的分区系统都采用虚拟桶一层。即使初期看起来“多了一层没必要的映射”等到第一次扩容你就会感谢当时多花的这一小时设计时间。5. 常见故障与排查实录5.1 数据倾斜分区之间大小差太多倾斜的表现很容易发现某个分区的磁盘使用率是其他分区的两倍以上或者一台机器慢慢被拖垮。原因要么是分片键选得不好要么是数据本身分布就畸形比如某个大客户贡献了大量订单。排查时先确认是不是天然倾斜用分片键做一次分组统计看每个值的行数分布。如果是少数大key导致的可以考虑把大key单独抽出来放一个分区再做二次分片如果整体分布就是歪的说明分片键选错了需要考虑重建分区或改换路由。注意大key治理没有通用银弹核心思路是“把大象从蚂蚁堆里分出去”。5.2 路由不一致数据已经迁走客户端还在读写这个问题最容易在迁移过程中爆发。元数据已经切换但客户端本地缓存的映射还没刷新于是请求按老路由打到旧分区结果数据已经搬走了响应结果缺失或写入失败。排查思路一般是三步。第一步检查客户端缓存的刷新机制是定时拉取还是监听推送刷新间隔多少。第二步看是否有流控或回滚机制一旦发现路由不一致能自动降级到“先查元数据再路由”。第三步如果是并发迁移时有短暂空窗要考虑在路由切换前设置一个短暂的“只读/拒绝写”保护期等旧连接排空再切。5.3 跨分区查询与事务限制怎么绕分区之后跨分区查询和分布式事务是最头疼的。单条SQL跨多个分区要么由中间层聚合要么应用层多个线程并行查询再合并排序。事务也一样多个分区之间无法用数据库原生事务保证ACID只能引入分布式事务方案而且代价不低。我的建议是做业务建模时就尽量避免。比如订单和订单明细放同一个分区用户和用户的账户放同一个分区让80%的操作变成单分区的本地操作。剩下的20%跨分区场景则尽量设计成最终一致通过消息对账去处理而不是强一致。你没法既要分区扩展性又要所有操作都像单库一样简单这个取舍必须做在前面。5.4 监控指标分区架构要盯哪些数最后分享一个我长期维护分区系统时总结的监控清单。这些指标不需要很复杂但每一个都对应一类故障各分区数据量方差和最大值用来提前发现倾斜。各分区QPS、CPU、磁盘IO分布用来发现热点访问。分区迁移任务的追平延迟和迁移速率用来评估扩容健康度。路由命中率和缓存刷新耗时用来保障寻址及时。跨分区请求占比用来评估业务演进是否偏离分区设计。这些指标统一上报到监控系统后我习惯给“最大分区数据量”和“分区QPS标准差”各设一条报警。报警阈值可以按实际基线调整但只要这两个指标异常基本都意味着分区架构正在劣化值得立即介入。最后说几句实在的这几年看下来分区架构的成败往往不是技术深度决定的而是设计的克制程度决定的。很多人一上来就上非常复杂的动态扩容、自动再平衡、复合分区最后维护成本高到下不了台。实际上绝大多数业务一个稳定分片键加虚拟桶、固定槽位映射、完善的迁移工具就够了。复杂方案的特性和它带来的额外故障可能性是成正比的没必要为了展示架构能力而给自己挖坑。另外无论选哪种方案都建议把“数据迁移”当作一等公民来设计。架构这个词听起来很宏大但真正考验你的往往是某次凌晨扩容时数据能否在业务无感知的情况下安全挪动。设计分区规则可能只需要一天但写迁移工具、做一致性校验、演练回滚流程可能得花一个月。这些功夫看起来不亮眼但它们才是分区架构能长期平稳运行的底气。