企业官网建设流程全解析

1. 为什么要在 Spring Boot 里认真对待 MongoDB 的分片与分表

很多团队一开始用 MongoDB，都是冲着"文档模型灵活、写入快、开发爽"去的。单机跑个几百万条数据，查询响应毫秒级，感觉一切都很美好。可一旦数据量爬到千万级甚至亿级，或者单集合的写入 QPS 顶到磁盘 IO 上限，问题就来了：查询开始变慢、索引体积膨胀、单节点磁盘告警、备份窗口越来越长。这时候你才意识到，MongoDB 的"分库分表"不是可选项，而是必须提前规划的架构能力。

这里要先厘清一个概念。MongoDB 原生提供的是分片集群（Sharded Cluster），它通过 mongos 路由、config server 元数据、shard 分片节点三层结构，把数据按分片键（shard key）打散到多个分片上。这跟关系型数据库里常说的"分库分表"在目标上是一致的——水平扩展、分散压力，但实现路径完全不同。关系库的分库分表往往要靠中间件（如 ShardingSphere）在应用层做路由，而 MongoDB 的分片是数据库自身的能力，应用层基本无感。

那为什么标题里还要强调"Spring Boot 集成 MongoDB 并实现分库分表"？因为在实际工程里，光把集群搭起来远远不够。Spring Boot 应用怎么连、连 mongos 还是连单节点、分片键怎么选、写入时怎么保证数据均匀、查询时怎么避免全分片扫描、分片后怎么做聚合统计——这些才是真正决定系统能不能扛住的关键。我见过太多项目，集群搭得漂漂亮亮，结果分片键选错，所有数据全压在一个分片上，等于白搭。

这篇文章面向的是已经用过 Spring Boot + MongoDB、但还没真正处理过海量数据的开发者。我会从分片机制讲起，再落到 Spring Boot 的具体配置和代码，最后重点聊分片键选择、查询优化、聚合处理这些容易踩坑的地方。文中涉及的集群搭建命令、配置参数、代码片段都可以直接拿去改改就用。需要说明的是，具体分片数量、机器规格这些要结合你自己的数据量和硬件来定，我给的是通用思路和常见实践。

2. MongoDB 分片集群的组成与数据路由逻辑

2.1 三个核心角色：mongos、config server、shard

要理解分片，先得把这三个角色分清楚。**shard（分片节点）**是真正存数据的地方，每个 shard 本质上是一个副本集（replica set），保证高可用。**config server（配置服务器）**存的是整个集群的元数据：哪个分片有哪些数据块（chunk）、分片键是什么、集群有哪些分片。它也必须是一个副本集，因为元数据丢了集群就废了。**mongos（路由进程）**是应用连接的入口，它不存数据，只负责根据 config server 的元数据，把请求转发到对应的 shard 上。

应用层看到的永远是一个 mongos 地址，感觉就像在连一个单机 MongoDB。这也是为什么 Spring Boot 集成时，配置里写的连接串指向 mongos 就行，不需要在应用里写任何分片逻辑。这个设计的好处是应用无侵入，坏处是——如果分片键选得不好，应用层完全感知不到性能问题，直到监控报警。

2.2 chunk 迁移：数据是怎么自动均衡的

MongoDB 把每个分片键范围的数据切成一块块chunk，默认每个 chunk 大小 64MB。当某个分片上的 chunk 数量明显多于其他分片时，**balancer（均衡器）**就会把 chunk 从多的分片迁到少的分片。这个过程是后台自动进行的，但对业务有影响：迁移期间会占用网络和 IO，如果迁移太频繁，会拖慢正常读写。

这里有个经验：balancer 最好设置在业务低峰期运行。可以通过sh.startBalancer()和sh.stopBalancer()手动控制，或者配置均衡窗口。我一般会在上线初期先关掉 balancer，等数据写入稳定、分片键验证没问题后再打开，避免早期数据倾斜导致疯狂迁移。

2.3 分片键决定了数据分布的上限

分片键是分片集群里最重要的一个决策，没有之一。它决定了数据怎么分布、查询能不能命中单个分片、写入能不能均匀打散。MongoDB 支持两种分片策略：范围分片（ranged）和哈希分片（hashed）。

范围分片按分片键的值区间切分，适合范围查询多的场景，但如果分片键是单调递增的（比如时间戳、自增 ID），新写入会全部落到最后一个 chunk，形成"热点写"。哈希分片对分片键做哈希后再分布，写入能均匀打散，但范围查询会变成全分片扫描。

实际项目里，我经常用复合分片键来平衡。比如{tenantId: 1, createTime: 1}，先按租户哈希或范围分，再按时间排序，这样既能保证多租户数据隔离，又能支持租户内的范围查询。

3. Spring Boot 连接分片集群的配置细节

3.1 连接串到底该写 mongos 还是 replicaSet

这是新手最容易搞混的地方。连分片集群时，连接串应该指向mongos 的地址，而且不要带replicaSet参数。因为 mongos 本身不是副本集成员，带上 replicaSet 反而会导致连接失败。正确的写法类似：

spring: data: mongodb: uri: mongodb://mongos1:27017,mongos2:27017/mydb?readPreference=secondaryPreferred

如果你连的是普通副本集，才需要写replicaSet=rs0。这个区别一定要记牢，我见过有人把副本集的连接串直接套到分片集群上，排查了半天才发现是参数问题。

3.2 读写关注与读偏好怎么设

分片集群下，writeConcern和readConcern的设置直接影响一致性和性能。写入方面，w: "majority"能保证数据被多数节点确认，安全性高但延迟大；w: 1快但可能在故障时丢数据。对于订单、支付这类不能丢的数据，我建议用 majority；对于日志、埋点这类可容忍少量丢失的，用 1 就行。

读偏好方面，分片集群支持primary、secondary、nearest等。如果业务能接受轻微延迟，用secondaryPreferred可以把读压力分散到从节点，显著提升吞吐。但要注意，从节点读可能读到旧数据，对一致性要求高的场景（比如刚写入就要读出来）还是得走 primary。

@Configuration public class MongoConfig { @Bean public MongoClientSettings mongoClientSettings() { return MongoClientSettings.builder() .applyConnectionString(new ConnectionString( "mongodb://mongos1:27017,mongos2:27017/mydb")) .readPreference(ReadPreference.secondaryPreferred()) .writeConcern(WriteConcern.MAJORITY) .build(); } }

3.3 连接池参数别用默认值

Spring Boot 默认的连接池参数偏保守，在高并发下容易成为瓶颈。分片集群因为要经过 mongos 转发，连接开销比单机大，所以连接池要适当调大。关键参数有maxPoolSize、minPoolSize、maxIdleTimeMS。我的经验是：maxPoolSize设为单机并发线程数的 1.5 倍左右，minPoolSize保持在 10 到 20，避免频繁创建连接。

spring: data: mongodb: uri: mongodb://mongos1:27017,mongos2:27017/mydb auto-index-creation: false

注意：生产环境一定要把auto-index-creation关掉。分片集群上自动建索引可能触发全分片操作，风险很大，索引应该由 DBA 或运维脚本统一管理。

4. 分片键选择：一个决策失误能拖垮整个集群

4.1 好分片键的三个硬指标

选分片键，我一般用三个指标去衡量：基数够高、分布够均匀、查询能命中。基数指的是分片键不同值的数量，基数太低（比如性别、状态这种只有几个值的）会导致 chunk 数量上不去，无法有效分散。分布均匀指的是写入不会集中到某一个值上。查询能命中指的是常用查询条件里包含分片键，这样 mongos 能直接路由到目标分片，而不是广播到所有分片。

举个反面例子：用status字段做分片键，值只有"待支付、已支付、已发货"几个。结果就是所有"待支付"的数据挤在一个 chunk 里，写入全压一个分片，查询status=待支付虽然能命中，但数据量一大照样慢。这就是典型的基数不足。

4.2 单调递增键的写热点问题

用_id（ObjectId）或时间戳做分片键，是另一个高频错误。ObjectId 大致是随时间递增的，范围分片下，新写入永远落在最后一个 chunk，导致最后一个分片承担全部写压力，其他分片闲着。这个现象叫写热点。

解决办法有两个：一是改用哈希分片，把_id哈希后打散；二是用复合分片键，比如{userId: 1, _id: 1}，先按 userId 分散，再按 _id 排序。哈希分片最简单，但代价是范围查询变慢。如果你的查询基本都是按 _id 等值查，哈希分片是很好的选择。

4.3 复合分片键的实战设计

复合分片键是我在真实项目里用得最多的方案。设计思路是：第一个字段负责分散写入，第二个字段负责支持范围查询。比如一个多租户的订单系统，分片键设计成{tenantId: "hashed", createTime: 1}。tenantId 哈希后保证不同租户的数据打散到不同分片，createTime 升序支持租户内按时间范围查询。

这里有个细节：复合分片键里，哈希字段只能有一个，而且必须是第一个。MongoDB 不支持多个哈希字段。另外，分片键一旦设定，后期修改成本极高，需要重建集合和数据迁移，所以上线前一定要用真实数据量做压测验证。

// 启用分片并设置复合分片键 sh.enableSharding("order_db") sh.shardCollection("order_db.orders", { "tenantId": "hashed", "createTime": 1 })

4.4 分片键与索引的配合

分片键会自动成为集合的一个索引（如果集合还没有以分片键开头的索引）。但业务查询往往不止按分片键，还需要其他字段的索引。这里的原则是：常用查询的索引最好以分片键开头，这样查询既能路由到分片，又能用上索引。如果索引不以分片键开头，mongos 可能还是要广播到所有分片，索引只在单个分片内生效，整体效率打折。

比如查询{tenantId: "A", status: "PAID", createTime: {$gt: ...}}，理想索引是{tenantId: 1, status: 1, createTime: 1}。这样 mongos 先按 tenantId 路由到目标分片，分片内再用 status 和 createTime 过滤，效率最高。

5. 分片后的查询与聚合：避开全分片扫描

5.1 怎么判断查询是否命中了分片

MongoDB 提供了explain()来分析查询计划。在分片集群上，重点看返回结果里的shards字段和mongos阶段的执行信息。如果查询命中了单个分片，shards里只会有一个分片；如果广播到所有分片，就会列出全部。我一般会在开发阶段对核心查询都跑一遍 explain，确认没有意外的全分片扫描。

db.orders.find({ tenantId: "A", createTime: { $gt: ISODate("2024-01-01") } }) .explain("executionStats")

看输出时，关注executionStats.totalDocsExamined和nReturned的比值。如果扫描了大量文档却只返回几条，说明索引没用好，需要调整。

5.2 聚合管道在分片集群上的执行方式

聚合操作在分片集群上分两种执行模式：分片内聚合 + mongos 合并，以及全分片聚合。如果聚合的第一个阶段能按分片键过滤，mongos 会把请求下发到相关分片，各分片先做局部聚合，再把结果送到 mongos 做最终合并。这种模式效率高。但如果第一个阶段不能按分片键过滤，就会广播到所有分片，每个分片都跑一遍，最后合并，开销成倍增加。

所以写聚合时，尽量把分片键过滤放在$match的最前面。比如统计某租户的订单总额，$match: {tenantId: "A"}一定要放在管道第一步，让 mongos 能精准路由。

Aggregation aggregation = Aggregation.newAggregation( Aggregation.match(Criteria.where("tenantId").is("A") .and("createTime").gte(startDate)), Aggregation.group("status").sum("amount").as("totalAmount") );

5.3 跨分片排序与分页的代价

sort和skip/limit在分片集群上是比较重的操作。如果排序字段不是分片键，mongos 需要从所有分片拉取数据，在内存里做归并排序，数据量大时容易触发内存限制。分页的skip更是如此，skip越大，每个分片都要扫描并丢弃前面的数据，效率极低。

我的做法是：能用游标分页（基于分片键或唯一有序字段）就不用 skip 分页。比如按 createTime 排序翻页，记录上一页最后一条的 createTime，下一页用createTime > lastTime来查，这样每个分片都能用索引定位，效率稳定。如果业务必须用 skip，尽量限制最大页数，或者把结果缓存起来。

5.4 分片集群上的事务边界

MongoDB 4.2 以后支持跨分片事务，但跨分片事务的性能远低于单分片事务，因为它涉及两阶段提交和多个分片的协调。在分片集群上设计业务时，我强烈建议尽量让一个事务涉及的数据落在同一个分片。怎么做到？把分片键设计成事务的天然边界，比如按 tenantId 分片，那么同一个租户的事务就都在一个分片内，事务开销小。

如果实在无法避免跨分片事务，要控制事务的持续时间和涉及的分片数量。事务越长、涉及分片越多，锁竞争和失败重试的概率越高。

6. 数据迁移、扩容与日常运维的实操经验

6.1 加新分片时数据怎么重新分布

集群跑了一段时间要扩容，加新分片是常见操作。加完分片后，balancer 会自动把部分 chunk 迁到新分片上。但这个过程可能持续很久，尤其是数据量大的时候。我的经验是：加新分片尽量选在业务低峰期，并且提前监控网络和 IO。迁移期间如果影响到线上，可以临时sh.stopBalancer()，等业务空闲再打开。

另外，加新分片后不要指望数据立刻均匀。balancer 是按 chunk 数量均衡的，不是按数据大小。如果 chunk 大小差异大，可能需要手动moveChunk来调整。这个操作要谨慎，最好在测试环境演练过再上生产。

6.2 预分片：避免上线初期的热点

新集合刚创建时，所有数据都在一个 chunk 里，即使配了多个分片，初期写入也会集中在一个分片，直到 chunk 分裂并迁移。对于写入量大的集合，可以在上线前做预分片（pre-splitting），手动把分片键范围切成多个 chunk 并分配到不同分片，这样一上来写入就是分散的。

// 对哈希分片键预分片 sh.shardCollection("order_db.orders", { "tenantId": "hashed" }) // 哈希分片会自动创建多个 chunk，无需手动切分

范围分片才需要手动预分片，哈希分片因为哈希值本身均匀，MongoDB 会自动创建足够多的 chunk。所以如果写入压力大又不想折腾预分片，直接用哈希分片更省心。

6.3 监控哪些指标能提前发现分片问题

分片集群的监控，我重点关注几个指标：各分片的 chunk 数量是否均衡、各分片的写入 QPS 是否均匀、balancer 是否频繁运行、慢查询是否集中在某个分片。如果发现某个分片的 chunk 数或写入量明显高于其他，基本可以判定分片键有问题，需要重新评估。

MongoDB 自带的sh.status()能看 chunk 分布，db.currentOp()能看正在执行的操作，配合监控平台（如 Prometheus + MongoDB Exporter）可以做到实时告警。我一般会设置两个告警：单分片 chunk 占比超过 40%，以及 balancer 单次运行超过 30 分钟。

6.4 备份与恢复在分片集群下的特殊性

分片集群的备份比单机复杂得多，因为数据分散在多个分片，而且有元数据。不能简单地逐个分片 mongodump，因为各分片的数据在时间点上可能不一致，恢复出来会对不上。正确做法是用 MongoDB 官方支持的一致性备份方案，比如通过文件系统快照配合协调各分片的备份时间点，或者使用支持分片集群的备份工具。

如果数据量不大、能接受短暂停机，也可以停掉 balancer 和写入，逐个分片 dump，再单独备份 config server 的元数据。恢复时先恢复 config server，再恢复各分片，最后启动 mongos。这个流程一定要在测试环境完整演练，生产上直接操作风险极高。

7. 几个我踩过的坑和对应的解法

7.1 分片键选错后如何补救

最惨的情况是上线后才发现分片键选错，数据已经倾斜。这时候有几个选择：一是重建集合，用新的分片键重新分片，把数据迁移过去，代价是停机或双写；二是用新的集合承载新数据，老数据保留只读，逐步迁移；三是如果倾斜不严重，通过手动 moveChunk 缓解。我的建议是，如果倾斜已经影响到线上，优先考虑方案二，用双写过渡，风险最小。

7.2 mongos 成为单点怎么办

mongos 是无状态的，理论上可以部署多个，应用连接多个 mongos 地址做负载均衡。但很多项目只部署一个 mongos，结果它挂了整个集群就不可用。生产环境至少部署两个 mongos，应用连接串里写上多个地址，驱动会自动做故障转移。这个成本很低，但收益很大。

7.3 大文档在分片集群上的额外开销

MongoDB 单文档上限 16MB，分片集群下大文档还有额外问题：迁移 chunk 时大文档传输慢，容易拖长迁移时间；查询大文档时网络传输开销大。所以设计文档结构时，尽量把大字段拆出去单独存，主文档保持精简。比如订单的商品明细，如果很多，可以单独存一个集合，主文档只存摘要和引用。

7.4 时区与日期字段在分片键里的坑

用日期字段做分片键时，一定要注意时区。如果应用写入的是本地时间，而查询用的是 UTC，范围查询可能对不上，导致扫描多余分片。我的做法是统一用 UTC 存储，应用层负责转换显示。这样分片键的范围查询逻辑清晰，不会因为时区问题出现意外。

8. 写在最后的一点个人体会

分片集群这东西，搭建本身不难，难的是分片键设计和后续的查询优化。我自己的经验是，在数据量还没起来的时候就要想清楚分片键，因为等到数据上亿再改，成本是数量级的差别。另外，别迷信"自动均衡"——balancer 能帮你均衡 chunk，但均衡不了业务逻辑上的热点，那得靠分片键设计。

还有一点，Spring Boot 集成 MongoDB 分片集群，代码层面其实很简单，复杂的是运维和架构决策。所以团队里最好有人对 MongoDB 的分片机制有深入理解，而不是只会写MongoTemplate。真出了问题，能看懂sh.status()和 explain 输出的人，才是能救火的人。