我做过不少大数据平台的项目几乎每个系统演进到一定阶段都会撞上同一个问题单机扛不住了数据量上去了查询变慢了写入也开始抖动。这时候你翻任何一本分布式系统相关的书都会告诉你两个字分片。但真到实操环节怎么分、按什么键分、分多少片、扩容怎么办处处都是坑。这篇文章专门把数据分片这件事从头到尾拆开讲清楚从原理到策略再到真实项目里踩过的坑一次聊透。这两年被问到最多的就是“数据分片到底是什么、跟分区有什么区别”或者干脆是面试现场直接甩一句“你们项目里怎么做的分片”。这篇文章的目标读者是正在搞大数据平台建设、准备大数据面试、或者被线上数据倾斜折磨得焦头烂额的工程师。看完不说能立刻成为专家但至少下次聊分片策略的时候你能把方案背后的逻辑讲明白而不是只会背“一致性哈希”四个字。1. 分片到底是什么先解决“为什么不能只靠一台机器”1.1 单机瓶颈的本质很多人对分片的第一反应是“把数据拆开放到多个节点上”这句话没错但没说到根子上。分片本质上解决的是单机资源上限的问题而这个上限具体体现在三个维度上缺一不可。第一个维度是存储容量。假设一台物理机挂8块16TB的硬盘RAID之后可用空间大概在100TB出头。听起来挺大但你要面对的是PB级的数据仓库或者每天新增几十亿条日志的系统100TB也就是几个月的事。就算你能把冷数据归档热数据也迟早撑爆盘。第二个维度是计算能力。数据量大了以后不只是存不下更重要的是查不动。一张10亿行的表哪怕加了索引一次全表扫描也要分钟级甚至小时级。对用户来说就是页面转圈对业务来说就是不可接受。CPU在单机上是有核数限制的内存是有容量上限的你没法靠堆硬件无限提升单机性能。第三个维度是写入吞吐。这是最容易忽略的坑。单机数据库的写入瓶颈通常不在CPU而在磁盘的IOPS和binlog落盘、WAL刷写的顺序。我用过一台配置相当不错的物理机MySQL的稳定写入吞吐大概在每秒几千条到一两万条之间再高就开始出现锁等待和复制延迟。如果业务峰值QPS是几万单机再怎么调优也顶不住。所以说分片不是“可选优化项”而是体量到了某个临界点之后必须做的架构演进。分片的核心目标也很好理解让每一台机器只承担一部分数据和这部分数据上的读写压力多台机器一起干活总容量和总吞吐都能线性扩展。1.2 垂直拆分与水平分片的区别聊分片之前必须先把两个经常被混为一谈的概念拆开垂直拆分和水平分片。垂直拆分是把一个库按业务模块拆成多个库比如用户库、订单库、商品库各放一台机器。这种方式的特点是每个库的表结构完全不同互相没有交集。它的好处是业务隔离干净、故障域独立坏处是它只解决了“库太大”的问题没解决“单表太大”的问题。订单表如果已经10亿行了拆到订单库里照样是10亿行该慢还是慢。水平分片才是我们常说的“分片”或者“sharding”它是把同一张表的数据按某种规则拆到多个节点上每个节点存储一部分数据所有节点的数据合起来是完整的一张表。比如订单表有10亿行分10片每片1亿行。单表数据量降下来了查询和写入压力也被分摊了。这里要特别说明一下大多数人理解的“分区”Partition和“分片”Sharding其实是两个层面的东西。分区通常发生在单机内部比如MySQL的Range分区、List分区是让一张表在存储引擎层面拆成多个物理片段但逻辑上还是一个表事务、索引都还是单机语义。分片则是跨节点、跨实例的每个分片是一套独立的数据库实例或独立的表应用层需要通过中间件或客户端路由才能找到数据。分片是在多机维度解决问题分区是在单机维度优化管理。真实的项目里二者经常组合使用比如先按用户ID分片每个分片内部再按时间分区方便冷热数据归档。1.3 分片后带来的复杂度为什么还要硬着头皮上分片不是免费的午餐。数据拆开了相应地就会引入一大堆原来单机架构下不用操心的问题跨分片的关联查询不能直接JOIN了事务变成分布式事务了全局唯一ID不能再靠数据库自增了扩容时要搬数据了某个分片负载过高还会出现数据倾斜。这也是很多人对分片又爱又恨的原因。但没办法数据量到了一定的体量分片是绕不开的路径。我见过一些项目用单机硬撑着撑到后面连备份恢复都要花十几个小时出事的时候根本玩不转。与其到那时再被动分片不如在架构设计阶段就认真考虑数据分片的方案。2. 分片策略选型Hash、Range还是一致性哈希2.1 Hash分片最简单也最容易踩坑Hash分片是目前最常见的一种策略。思路就是选定一个分片键对这个键计算哈希值然后对分片数量取模得到一个分片编号。比如用户ID为100的订单hash(100) % 4得到结果为0就放到第0个分片。这个方案的好处是数据分布非常均匀只要分片键的基数够大、哈希函数够散每个分片的数据量基本差不多。但是Hash分片有一个致命问题一旦分片数量改变数据迁移量巨大。假设原来4片要扩到5片理论上有4/5的数据需要重新分布。扩容期间不仅要搬数据业务读写还要保证正确性这在生产环境是非常棘手的操作。我参与过一个订单系统最初分片数量定的是8上线半年后业务量翻了三倍被迫扩容到16片。那次扩容花了整整一个周末而且是停机迁移业务侧完全不可用后来复盘的时候所有人都觉得这个方案定得太草率了。另外一个Hash分片的坑是分片键的选择。如果你选的分片键不够分散比如按订单状态来分那么“已完成”状态的订单数量远远大于“待支付”就会导致大量数据落在同一分片上。千万记住分片键要选高基数的字段并且需要尽量符合业务访问特征。Hash分片适合按某一个固定的实体维度去查询的场景比如按用户ID查订单、按设备ID查轨迹。如果业务查询维度经常变化比如一会儿按用户查一会儿按商家查那Hash分片会让另一类查询变成全分片扫描根本走不了索引。2.2 Range分片范围查询友好的另一面Range分片是按照分片键的连续区间来分配数据的比如按时间范围分片2023年的数据放在分片A2024年的数据放在分片B2025年的分片C。或者按用户ID的区间1到100万放一片100万到200万放一片。Range分片最大的优势是范围查询非常高效因为你要查的数据被提前聚在少数几个分片里不需要广播给所有分片。时间序数据尤其适合比如日志系统按天分片查某一天的日志只需要访问对应分片冷热数据还能通过Range分片自动分离旧数据所在的分片可以直接做归档甚至不参与在线查询。Range分片的致命弱点是数据热点问题。如果业务有明显的近期特征比如大部分读写都集中在最近一天的数据上那么新数据所在的分片就会成为热点其他分片则空闲。在极端情况下你做分片是为了分摊压力结果压力全跑到一个分片上跟没分片几乎没区别。我见过一个招聘系统的简历库就是这么死的候选人数据按时间Range分片平时没问题一到“金三银四”求职季全部实时流量都打向最近的分片那个分片直接被打爆其他分片闲得发慌。所以在实际选型的时候Range分片通常适合写入有规律、查询大多是时间范围或者顺序访问的场景而且还需要有配套机制应付热点比如加一层缓存、对最新分片再细化分片粒度等等。2.3 一致性哈希扩缩容的救星Hash取模的扩容噩梦和Range分片的热点问题促成了一致性哈希方案的普及。一致性哈希的核心思想是把整个哈希值空间组织成一个虚拟的圆环数据节点物理分片也通过哈希映射到这个环上。数据进来的时候计算分片键的哈希然后顺时针查找环上第一个遇到的节点数据就存在那里。这个方案听起来只是换了个寻址方式但它带来的核心好处是增加或删除一个节点时只需要迁移该节点逆时针方向到前一个节点之间那部分数据其他节点的数据完全不受影响。这比取模分片的重新分布代价小了太多。一致性哈希还有个关键增强点叫“虚拟节点”。因为真实物理节点在哈希环上的位置是随机的节点少的时候容易出现分布不均匀A节点管了大半个环的数据B节点只管了一小块。解决办法是把每个物理节点虚拟成几百个虚拟节点均匀撒到环上。这样数据分布就均匀了而且某个物理节点挂了它的负载会被多个虚拟节点分摊不会全部压到邻近的某一个节点上。不过一致性哈希也有自己的问题虽然迁移量小但迁移过程中还是会有一段时间的“数据不一致风险”。如果查询发生在迁移中间要么请求可能路由到老节点拿不到数据要么需要额外做双读双写。很多工程实现包括Redis Cluster会在迁移期间对正在迁移的slot做阻塞访问保证一致性但这会对业务造成短暂延迟。所以一致性哈希的完全自动化管理需要在客户端和集群管理上做很多额外工作不是引入一个哈希环就万事大吉的。2.4 分片键选择决定了上层建筑的质量分片键是整个分片方案的“宪法”。一旦定了后面改起来难如登天。分片键的选择有几个硬性标准我根据实际踩坑经验整理下。首先分片键的基数必须高。如果分片键只有几个枚举值比如状态成功/失败、性别男/女那么无论用什么哈希算法数据都分布不到很多分片上。基数低意味着每个分片内的数据量不可控。其次分片键要能覆盖大多数查询场景。黄金标准是你80%以上的查询都携带这个字段作为条件。比如在电商系统里用户端的查询几乎都带“用户ID”所以按用户ID分片是常规操作。但如果是后台运营系统要按商家去汇总订单带“商家ID”的查询也不少这时候按用户ID分片就会导致商家维度的查询广播到所有分片查询性能会很难看。这种情况下有的团队会引入“分片键冗余”即同时维护一张按商家ID分片的订单表或者用数据同步组件做异构索引这属于进阶玩法了后面细说。第三分片键最好不要是会被更新的字段。我曾经见过有个系统按“用户手机号”分片结果用户换了手机号但手机号已经是分片键数据没法直接改路由只能先删后插查出来的错数据让用户投诉了一大轮。教训很惨重。选一个稳定的、天然只增不改的字段比什么都强。3. 分片路由与元数据管理数据到底到哪里去查3.1 客户端路由、中间件路由与中心化路由确定了分片策略之后下一步就是解决“数据请求从进来之后怎么找到正确的分片”的问题。按照路由实现的位置常见的有三种方式。第一种是客户端路由。也就是在应用代码里嵌入寻址逻辑自己算好要访问哪个分片然后直连对应的数据源。这种方式最简单、性能最好因为不需要额外的中间层转发。缺点也很明显分片逻辑跟业务代码耦合一旦分片规则调整所有客户端都要跟着改而且多语言客户端的逻辑要保持一致很容易出现“Java能查到C查不到”的尴尬。第二种是中间件路由。部署一层独立的代理服务比如ShardingSphere Proxy应用只跟代理打交道代理负责解析SQL、路由到正确的后端分片、合并结果。这种方式对应用侧非常友好开发人员几乎感知不到分片的存在只要连上个普通数据库连接就行。中间件方案的问题是多了一层网络转发有额外延迟而且中间件自身必须高可用否则分片架构的功能再厉害代理挂了等于全挂了。第三种是中心化路由也常被称为“元数据服务”或“配置中心路由”。所有请求先查一下全局的路由表知道目标数据在哪个分片再去访问真正的分片。典型代表是HBase里的HBase Meta表、ClickHouse的分布式表、以及很多自研的分片中间件。这个方案的优点是路由信息可以动态变更扩容、迁移只要更新路由表就行客户端无需知道具体数据位置。缺点是路由表本身可能成为单点和性能瓶颈分布式系统里要做多级缓存来降低对路由表的访问压力比如HBase的客户端就大量缓存region的位置信息尽量减少跟Meta表的交互。这三者没有绝对的好坏选择哪条路取决于团队的运维能力和应用的访问模式。我的建议是如果团队规模不大、系统复杂度可控用客户端路由直接写死规则是最省事的如果分片数量多、规则经常变、团队还能配人力去维护中间件那中间件方案更省心如果系统已经到了几十上百个分片的规模走向中心化元数据是必然选择。3.2 全局唯一ID生成分片后的基础组件我记得第一次做分片方案设计时专门为ID生成方式吵了一下午。因为分片之后多张表之间的主键如果还靠数据库自增那每个分片的主键会重复跨分片合并数据时立刻乱套。所以分片后的第一件事就是搞定全局唯一ID。目前业界常用的方案不外乎几种。一是UUID/GUID简单但不能保证递增且长度过长对索引不友好除非你不在乎性能。二是雪花算法Snowflake经典的时间戳加机器ID加序列号组成64位ID不仅能保证全局唯一还能按时间粗略有序这对分页、排序、范围查询都有好处。三是依赖一个独立的发号器服务比如百度开源的UidGenerator、美团的Leaf这种方案适合对ID趋势递增有强要求的业务。我自己的习惯是优先考虑雪花算法。它在无中心化依赖的情况下能实现趋势递增、高并发生成ID非常契合大数据场景。但要注意雪花算法强依赖机器时钟如果服务器NTP同步有问题时钟回拨会导致ID重复。生产环境一定要做时钟回拨的容错处理比如记录上次生成ID的时刻一旦发现当前时间小于上次时间短时间等待或直接报错而不是闭着眼睛继续生成。3.3 跨分片查询不能JOIN怎么办分片之后最让业务开发头疼的不是写数据而是读数据。淘宝APP上“我的订单列表”这种按用户ID查的请求很轻松一条SQL定位到分片直接查。但运营后台要查“过去一个月所有买了某商品的用户”这个需求就复杂了。跨分片查询的处理策略按“能不能接受实时”分为两条路。一条路是接受一定的查询延迟用聚合查询引擎来做。前端请求到了以后广播到所有分片分别执行然后再把结果汇总去重排序。听起来简单但问题在于深度分页和排序会很尴尬。MySQL的ORDER BY ... LIMIT 10在各分片分别执行时每个分片都返回各自的前10条然后汇总排序结果大概率是不准的因为你可能漏掉了某个分片里排在第11条但整体排序该进前10的数据。修正做法是让每个分片把可能进入最终结果的候选集都取出来比如每片取100条汇总后重排再取前10然后跟前端交互的时候还要配合游标或者时间戳做锚点分页。这一套逻辑非常容易出bug我们实际排查过多起“分页数据重复/缺失”问题基本都是这个原因。另一条路是把跨分片查询转换为“预计算”和“冗余”。我们把订单数据按用户ID分片后再构建一套按商品ID、商家ID组织的索引数据用另外的存储引擎比如Elasticsearch来承接那些多维度的分析查询。业务查询先查ES拿到订单ID集合再根据订单ID去分片里捞原始数据。这就是所谓“异构索引”或者“CQRS”思想的简化版。对在线业务来说这个方案比广播聚合性能稳定得多代价是要维护一份额外的索引数据对数据一致性也有分钟级延迟的妥协。4. 数据倾斜与热点应对别让分片名存实亡4.1 数据倾斜的典型症状与诱因分片做完最怕看到的现象就是“明明10个分片却只有2个在干活”。这是数据倾斜的直接表现具体症状一般是某个分片的节点CPU报警、IO打满、连接数飙高而其他节点负载悠闲。常见的诱因有三类。第一类还是分片键选得不好比如性别、地区这种低基数字段或者字段值本身分布极不均衡比如按“用户所在的省”分片广东用户数量远远大于宁夏那广东这一片必然成为热点。第二类是数据本身的“长尾效应”极少数分片键对应的数据量巨大比如某个大客户的订单量比其他客户高出几个数量级那按客户ID分片时这个大客户所在的分片就很容易拖垮整个集群。第三类是时间维度上的突发流量比如秒杀、促销、热点新闻引发的访问洪峰会集中打向一部分分片键。倾斜的本质是“分片键的哈希分布”和“业务请求分布”之间产生了错位。哈希算法只能保证键值均匀映射不能保证访问量和数据量均匀映射。就算数据量均匀如果绝大多数请求都是查那一个热门ID的数据在数据层面依然是均匀的但请求层面已经倾斜到爆炸。4.2 解决倾斜的常用套路加盐、拆片、热点识别数据倾斜问题的解决手段可以从写和读两个方向分别设计。写入侧的倾斜最粗暴的办法是“加盐”。在分片键上混入随机数或可控后缀让原本集中在单个分片的数据被分散到多个分片。但加盐之后查询侧得知道盐值的规则才能定位数据否则一个查询要发到多个分片去扫描。实际工程里更稳妥的是“两级映射”热点键单独识别把这个键的数据拆成多个子键比如原本大数据量客户的ID为888那就创建888-0、888-1、888-2多个虚拟子键把该客户的数据打散到多个分片。查询的时候应用层同时发多个请求到这些子键所在分片再合并。代价是应用层逻辑变复杂但对稳定性提升非常明显。读侧的倾斜应对思路是“热点识别 缓存”。很多读热点本质上只是高并发读同一份数据跟数据量关系不大。比如某个热门商品详情、某条爆款短视频在写入侧数据量并不大但被大量用户同时访问。这种情况下给这极少数的热点数据加一层Redis或者本地缓存比费劲调整分片策略要高效得多。我们之前用一个简单的LRU热点识别模块统计每个分片键的访问频次超过阈值就把该键的数据推送到缓存同时标记为热点后续请求走缓存通道。实测这个方案能把峰值QPS从每秒几千提升到二十几万而底层分片架构完全没有改动。4.3 容量评估刚开始分多少片合适分片数量定多少是设计阶段的灵魂拷问。定少了过一阵又要扩容扩容的痛苦前面已经说过定多了每台机器资源利用率低还要白白维护空转的节点。拍脑袋定片数没有意义我给你一个经验估算方法。假设你有单表1亿条数据每条记录1KB那么总数据量是100GB。考虑未来3年增长到5亿条也就是500GB。单台MySQL或PostgreSQL在保证查询性能的前提下建议单实例数据量控制在200GB~500GB以内。这么算下来你至少需要2~5个分片。然后再叠加写入吞吐维度假设业务高峰期写入QPS是8000单实例稳定写入QPS按1500算那就需要至少6个实例才能扛住写入压力。综合存储和吞吐两个维度取较大值再留出30%~50%的冗余基本就是初始分片数。我还想强调一点分片数尽量是2的幂或者质数相关的数这不全是为了玄学。取模分片在扩容时如果片数是2的幂某些哈希算法可以基于位运算优化而且迁移数据的时候容易做分轮搬迁。Hash取模的场景下从4片扩到8片比从4片扩到5片简单得多因为4的倍数关系下旧数据的新位置正好是原位置乘以2部分数据还能原位保留。5. 主流大数据组件里的分片机制各有各的脾气5.1 HBase的Region拆分HBase是大数据领域里典型的数据分片实践者。它把一张表按RowKey的字典序拆成多个Region每个Region分布在不同的RegionServer上。当单个Region的数据量超过阈值默认是10GB可配置128MB到几十GB不等就会触发Region Split自动拆成两个子Region。HBase的RowKey设计对分片的影响极大。RowKey如果带了随机前缀比如用户ID的反转、MD5哈希那么数据的写入会均匀分布在所有Region上适合对写入吞吐有极高要求的场景。RowKey如果纯粹是自增ID那么所有写入都会打到最后一个Region上形成“写热点”因为表的RowKey是按字典序排列的新数据永远排在最后。这也是新手做HBase表设计时最容易犯的错。HBase的Region还会触发自动合并如果删除了大量数据Region太小会合并以减少文件数。平时运维HBase要特别注意Region的均衡性必要时可以手动执行balance命令或者开启hbase.balancer.period调整均衡周期。5.2 Elasticsearch的分片与副本Elasticsearch会把一个索引拆成多个分片shard每个分片本质上是Lucene的完整倒排索引分布在不同的数据节点上。建索引时指定number_of_shards和number_of_replicas但这个分片数量在建索引之后几乎是不可变更的要改只能重建索引这是ES设计里最被人诟病的一点。ES分片数量的评估没有一个万能答案。定少了单分片数据量过大聚合查询慢甚至出现过映射爆炸、段合并把IO耗尽的问题。定多了分片和副本占用的资源大量浪费而且每次查询都要把所有分片都扫一遍查询慢不说Merge结果的开销也大。业界普遍建议是每个分片的数据量在20GB~50GB之间单节点上的分片数不要太多否则段合并和线程池调度都会失控。ES对分片的读写有一个特点写入时默认按文档ID做路由存储分布依赖内置的哈希。如果你想按业务维度隔离数据可以自定义routing字段。比如日志索引按“业务线”作为routing那么同一业务的日志会进入同一分片查询该业务的日志时可以跳过其他分片但代价是分片之间数据大小可能很不均衡。用不用自定义routing本质是在“查询隔离性”和“数据均衡”之间做权衡。5.3 ClickHouse的分布式表与本地表ClickHouse的分布式分片是建立在“分布式表”和“本地表”两层设计上的。本地表是真正存储数据的物理表分布式表只是逻辑上的视图负责把SQL分发到底层的本地表上执行然后合并结果。ClickHouse的分布式表会在写入时根据sharding_key来决定把数据转发到哪个分片。典型的做法是使用rand()做随机分片适合数据不需要有序的场景或者使用cityHash64(某字段)做哈希分片让同一个维度的数据落在同一个分片。这里有个跟其他系统不一样的地方ClickHouse的分布式表非常依赖查询模式下推到分片的能力。如果你的查询没有带上sharding_key作为过滤条件ClickHouse只能走分布式查询也就是把SQL转发到所有分片去执行代价非常大。所以设计ClickHouse的分片键时必须仔细分析查询的过滤条件尽量保证高频查询都会带分片键字段。5.4 Kafka的分区与消费者并行度Kafka里的分区Partition本质上也是一种分片。Kafka的Topic可以分成多个分区每个分区是同一主题下消息的一个有序队列落在不同的Broker上。分区数决定了同一消费组里最多能有多少个消费者并行消费这就是Kafka并行度的上限。Kafka的分区数设定有一个容易忽略的点分区数不是越多越好。每个分区在Broker上对应一组日志文件和若干索引每个分区还跟消费者之间维护着位移信息。分区太多文件句柄和内存占用会大幅上升而且分区多会导致消息在多个磁盘之间随机写对小文件IO场景很不友好。我们实测过一个Broker上单Topic分区数超过200之后Controller重新选举和Leader切换时间明显变长故障恢复变慢。选分区数一般建议按“目标吞吐量 / 单分区吞吐量”的公式来估算再留出2~3倍冗余。目标写入吞吐是每秒10万条单分区实测能吞每秒5000条那至少就要20个分区保守点设到40~60个以应对未来增长。6. 分片扩容与数据再平衡一次教科书级的现场操作6.1 扩容前必须做的准备分片扩容是我在大数据运维里做过的最紧张的事没有之一。老系统的扩容虽然数据迁移量巨大但方案相对成熟跟着步骤走就行新系统的首次扩容则处处是未知数一旦估算错误可能引发雪崩。扩容前的第一件事不是写脚本而是盘点现状。我会先把所有分片的数据量、节点负载、查询延迟、慢查询日志全部拉出来对比一遍找出“为什么需要扩容”的真正原因。是存储快满了还是CPU已经长期高水位抑或是连接数接近最大值原因不同扩容策略也不一样。如果是存储原因可以只对数据量最大的分片做子分片如果是CPU原因可能需要整体增加分片数量并把数据重新打散。第二件事是检查分片键的分布情况。用一个大查询把所有分片按分片键聚合统计一遍看看每个分片的键值基数是否均匀。如果已经出现一个超大分片键那么扩容之前最好先规划好如何对热点键做拆分否则扩容完还是会出现新的热点分片。第三件事是备份。扩容期间最怕出意外迁移脚本跑一半报错数据对不上。一个可靠的备份能让你随时回滚至少心里有底。HDFS快照、MySQL的物理备份、ES的快照仓库务必在扩容前完整跑一次。另外要选定一个业务低峰期窗口而不是想当然地“半夜就可以”。很多平台的真实低峰期在凌晨三四点但也有的业务全球用户都在访问需要借助流量调度先把一部分流量切走再做内部变更。6.2 不停机迁移的常用链路老办法停服迁移简单但代价高现在主流方案追求在线迁移。以MySQL分片库为例最常见的实现方式是一套“双写加校验”的流程。首先是“建立同步”在旧分片之外新建新的目标分片然后通过数据同步工具比如DTS或者CanalDTS把旧分片的数据全量导入目标分片之后持续跟进增量变更。初始化完成之后新旧之间的同步延迟会越来越小直到追平。然后是“双写切换”让应用层同时写旧分片和新分片同时依靠校验程序逐条对比新旧两个分片的数据发现差异就按源端为准修正。双写阶段通常会持续一段时间用来验证数据的正确性和系统的稳定性。这里有一个关键点双写不能只靠应用层改代码一旦代码发布出问题双写就中断了数据就分叉了。最好用数据同步工具在MySQL binlog层面做转发实现“源库—新库”的天然双写。最后是“流量切换”把读流量和写流量逐步从旧分片切到新分片先切10%、再切30%、50%观察新分片的负载和查询延迟全部稳定后再把旧分片下线。整个流程走完快则一天慢则一周每一步都需要监控告警和回滚预案。6.3 数据校验方案哈希比对与抽样数据迁移之后怎么证明新分片的数据跟老分片完全一致这是扩容报告里最受挑战的部分。我们通常会做三层校验。第一层是行数校验按分片统计每个分片的行数、按关键维度统计聚合值比如总数、总额老分片和新分片对齐。这个最快但只能证明数据差不多不能证明每一行都对。第二层是哈希对比把每个分片的数据按主键排序计算每一行的MD5再对整个分片算一个最终摘要值对比新旧分片的摘要值。如果两个摘要值一致基本可以认定数据完全一致。但数据量大的时候全量算哈希非常耗时所以一般跟第三层配合使用。第三层是抽样校验对同一个分片键的数据随机抽取千分之一到百分之一的样本逐字段比对新旧分片的具体内容。抽样比例你可以根据数据的敏感程度决定线上交易数据我建议抽到5%以上日志类数据1%就够。三层校验全通过之后才允许执行正式的流量切换。6.4 扩容后的性能回放与验收很多人以为流量切过去就算完了实际上扩容的验收标准不仅仅是“系统没挂”。我会在扩容完成后的两到三周内持续回放扩容前的历史流量模拟高峰期把读写QPS推上去对比扩容前后的P99延迟、错误率、CPU使用率是否达到预期。如果扩容后延迟并没有显著下降或者某个分片仍然负载偏高那说明分片键的设计或者分片数量的估算还是有问题的。回放的方式可以借助线上真实流量的录播把Nginx或网关层记录的请求日志按时间顺序重新打到新集群。这个操作能真实暴露那些“测试环境永远模拟不出来”的瓶颈比如某条慢SQL在数据量分布均匀之后突然变快了但某个跨分片聚合反而变慢了。发现问题及时修正避免在扩容完成后被动踩坑。7. 面试和实际落地中最容易被问爆的问题7.1 分片和分区的区别面试官到底想听什么面试时候被问“分片和分区的区别”很多人会直接背诵定义但面试官真正想听的是你能不能结合实际场景把二者的联系和区别讲清楚体现出架构思维。比较加分的回答逻辑是这样的先说本质分区是在单机存储引擎内部将表的数据按规则切分成多个物理片段这些片段仍然共享同一个数据库实例通常是为了便于管理、归档、删除。分片则是在多机层面并行处理每个分片是独立的存储引擎或数据库实例数据按规则分布在不同机器上主要用于提升容量和吞吐。然后补充一句两者经常叠加使用比如分片后每个分片内部再做分区用于管理冷热数据。最后如果能结合你实际用过的组件举例比如HBase的Region是分片、Cassandra的vnode是分片、MySQL的PARTITION BY RANGE是分区那基本就是满分答案。7.2 扩容时数据怎么迁移才不会出乱子面试官问扩容方案本质是想考察你在分布式系统下的工程能力和风险意识。一条把取模分片扩展到更多分片的标准回答思路是第一说明取模分片扩容会引发大规模数据迁移所以生产环境不建议直接取模尽量用一致性哈希加虚拟节点或者采用“先扩容虚拟节点数量、再平滑搬迁”的方式。第二如果现状就是取模分片那就用“双写 全量迁移 增量追平 切换 校验”的五步方案把停机时间压缩到分钟级甚至秒级。第三提一下预算层面的细节迁移工具要支持断点续传校验工具要做回滚方案要准备灰度切换的流量比例要控制。能把这三层讲清楚比背一堆空洞的理论有用得多。7.3 分片键选不好还有没有补救方案很多人实际项目里分片键已经定死遇到热点或者跨分片查询才开始后悔。这种情况下补救方案是有的但都需要付出代价。一种是对分片键加一层映射。举个例子原本按用户ID分片但运营经常按商家ID查。可以在应用层维护一张“商家ID到用户ID”的映射表查询时先查映射表拿到用户ID再访问分片。这张映射表本身可以存在Redis里性能完全可接受。坏处是数据一致性要维护商家和用户的关联一旦变就要同步映射表而且批量查询时要拼接多个用户ID。另一种是引入全文检索或者分析型数据库做异构索引把跨分片查询的重活交给ES、ClickHouse这类组件。订单表继续按用户ID分片但商品维度的汇总查询交给ESES里同步一份精简字段的数据。业务方接收到“响应有延迟但查询能力大幅提升”的折中方案实际用下来极少有人反对。7.4 分片数量的计算有没有靠谱的估算方法分片数量不是越大越好这点一定要记住了。我给团队评审时有一个固定的一套性价比公式根据单分片存储上限、单分片吞吐上限、业务未来3~5年的数据增长量这三个参数算出分片数量的下限再乘上1.5到2的冗余系数得到最终建议值。举一个具体例子业务现有数据300GB每天新增1GB三年后大约1.4TB单实例存储上限按500GB算至少需要3个分片业务峰值写入QPS 6000单实例写入上限1500至少需要4个分片取最大值4乘1.5冗余系数建议初始分片数6个。如果考虑到后期扩容以2倍递增更省事也可以直接定8个留够余量。分片数量并不是越多越能扛性能。分片多了元数据管理、连接数、聚合查询开销都会增加甚至在分片数量超过某个临界点后增加分片反而让整体性能下降。所以这个数量真的需要认真设计不能图省事抛个“我要100片”。8. 实践中的一些基础设施配套8.1 分片后的监控告警项和关键指标分片架构上线之后监控的维度跟单机时代完全不同。除了常规的CPU、内存、磁盘、网络你还要关注每个分片之间的负载均衡度、分片间数据分布倾斜度、分片请求量的离散系数。我给自己的监控面板上加了几个核心参数各分片的QPS方差、分片间数据行数极差、跨分片查询的比例、慢查询的数量分布。一旦某个分片的QPS明显高于其他分片或者数据量极差超过阈值就说明倾斜在发生需要介入处理。数据分片的健康度不能只看平均值平均值会把问题掩盖掉。一个集群的10个分片9个空闲1个打满平均负载看着不高但那一个打满的分片已经在影响线上业务了。所以一定要看分位值或者直接把每个分片单独拉出来看不能只盯一个聚合的Dashboard。8.2 分片与分库分表中间件的集成如果你用的是MySQL生态实际落地时大概率会引入分库分表中间件。ShardingSphere是目前最活跃的开源项目之一包含JDBC和Proxy两种形态我简单介绍下各自的适用场景。ShardingSphere-JDBC是轻量级的客户端模式它嵌入应用内部应用启动时读取分片规则直接把SQL改写成目标分片的分片SQL然后发给后端数据库。因为没有额外的网络代理层性能损耗极小适合Java技术栈、对延迟敏感的业务。ShardingSphere-Proxy则是独立部署的服务端对客户端透明任何语言的客户端都能通过MySQL协议连上来使用适合多语言团队和不愿意改业务代码的场景。我一般建议小规模团队用JDBC因为部署简单排查问题方便如果有很多个异构系统要接入分片库或者需要统一的团队来运维分片规则那Proxy更合适。中间件配置的分片规则非常灵活可以按表配置分片键、分片算法、分片列等。但要注意中间件只帮你路由SQL跨分片事务、跨分片聚合仍然需要业务层配合不是配置一下全自动解决的。8.3 分布式事务与分片的取舍分片之后原本在一个库里的多条记录可能被拆到不同分片原来的本地事务就升级成了分布式事务。常用的分布式事务方案有基于消息的最终一致性、TCCTry-Confirm-Cancel、以及XA两阶段提交。实际项目里我很少见到真正的强一致分布式事务被大规模应用。强一致带来的代价是性能下降和复杂度上升很多业务场景其实只需要最终一致性。比如一个订单创建后要扣库存你可以先把订单写成功再通过MQ异步通知库存服务扣减如果扣减失败则走补偿流程。这种异步化方案在高并发下体验很好而且对分片架构的侵入性最小。需要提醒的是分布式事务的方案会影响表结构设计和分片键选择务必在架构设计阶段就想清楚而不是上线后再补救。比如TCC方案要求每个参与方都实现Try、Confirm、Cancel三个接口这在业务代码层面的改动量是很大的。9. 几个月后回头看分片方案的真实验收清单我会在分片方案上线之后大约一个季度再做一次技术复盘。这次复盘不关心方案本身而是关注系统在实际运行中是否达到了预期的目标。我通常用这几个维度来打分调度是否稳定有没有出现过分片节点频繁宕机、分片间负载长期不均衡、扩容后性能没有明显提升的情况路由是否正确业务侧有没有发生过查不到数据、查到了重复数据之类的路由错误查询性能是否达标分片之后的P99查询延迟是否比单机时代更优跨分片查询是否在可接受范围内运维是否便捷分片状态的监控是否清晰、扩容是否快、故障是否容易定位如果这些维度的答案是肯定的我会认为这个分片方案是健康的。如果某个维度不达标我会先记下来并在下一次技术债清理时优化。分片架构不是一锤子定终身它是一个持续迭代的设计过程。随着业务数据量的增长和访问模式的变化分片策略也需要随之调整。我自己在做分片评估时一直秉持一个原则不为了分片而分片。数据量单机能扛就不要急着拆非要拆就先把分片键和分片数量这些地基性的问题想透再动工。很多人以为分片只是一种技术手段实际上它更是一种对业务访问模式的深刻理解。你只有真正知道你的数据是怎么产生、怎么被读、未来会怎么膨胀才能定出经得起时间考验的分片方案。