MongoDB 分片集群配置

当我们的应用程序日渐成熟，数据量和访问量不断增长时，单台 MongoDB 服务器往往会遇到性能瓶颈。这时候，MongoDB 的分片（Sharding）技术就成为了解决大规模数据存储和处理的关键方案。 在前面的学习中，我们已经了解了在单机环境下搭建基础集群的方法，而在实际的生产环境中，我们需要构建更加稳定和可扩展的分片集群架构。

因此我们这节课将深入探讨如何在真实的分布式环境中配置 MongoDB 分片集群，我们将学会如何协调配置服务器、分片节点和路由进程之间的工作关系，掌握集群扩容的策略，以及理解数据在分布式环境中的存储和分发机制。

分片时机的判断

是否启用分片架构，是MongoDB大规模应用架构设计中的一个核心决策。合理的分片时机，需要基于对系统性能瓶颈的识别与评估，既要避免过早复杂化系统，也要防止因扩展滞后而影响业务连续性。

避免过早分片的风险

在数据规模及访问压力未达阈值之前过早实施分片，通常弊大于利。分片集群相较单一副本集在架构、运维、监控及故障处理等多个维度上复杂度大幅提升。 更重要的是，分片键（Shard Key）一旦选定，后续更改成本极高，极易造成长期的架构锁定。因此，只有在系统规模和并发需求已到达单机极限时，分片才有其实际价值。 例如，若某电商平台用户量规模仍处于早期阶段即启用分片，除增加运维难度外，还可能因数据规模过小，无法发挥分片的可扩展性优势，使系统维护成本远高于预期效益。

分片应在系统资源出现如下典型瓶颈时优先考虑：

• 内存瓶颈：当业务工作集（Working Set）持续超过服务器可用内存，频繁的磁盘I/O导致数据库响应性能显著下降，通过分片将数据水平拆分至多台服务器，可有效扩展总体内存资源。
• 存储容量瓶颈：随着业务数据持续增长，单台服务器磁盘容量无法承载全部数据，即便通过硬件升级进行纵向扩展也会受限于成本及物理极限，此时分片能够实现横向扩容。
• 计算与连接数瓶颈：服务器CPU长期处于高负载，或并发连接数超出承载能力，分片有助于并行分担请求压力。
• 吞吐瓶颈：应用的读写操作量已超过单实例mongod的处理上限，在高并发场景（如实时数据分析、社交网络等）分片成为必要架构手段。

监控驱动下的分片决策

在高可用生产环境下，系统常因单一资源瓶颈导致性能受限，而非所有资源同步耗尽。因此，应通过持续监控识别关键瓶颈，并据此制定专门的扩容与分片策略。例如，图片社交应用主要受磁盘容量约束，需优先考虑存储扩展及数据分片； 而即时通信系统则因高并发连接对内存、网络等资源消耗巨大，应重点监控连接数、内存及带宽。

分片集群的核心组件

要构建一个完整的 MongoDB 分片集群，我们需要协调三个关键组件的工作：配置服务器（Config Servers）、分片节点（Shards）和路由进程（mongos）。这三个组件各司其职，共同构成了一个高可用、可扩展的分布式数据库系统。

配置服务器负责存储集群的元数据信息，包括哪些副本集充当分片、哪些集合被分片、每个数据块位于哪个分片上等关键信息。分片节点则是实际存储数据的地方，通常由副本集组成以确保高可用性。而 mongos 进程则充当客户端和分片之间的路由器，负责将查询请求定向到正确的分片上。

配置服务器

配置服务器可以说是整个分片集群的「大脑」，它们保存着集群运行所需的所有关键元数据。这些元数据包括集群拓扑信息、分片映射关系、数据块的分布情况等。正因为承担着如此重要的职责，配置服务器的设计和部署就显得尤为关键。

从 MongoDB 3.2 版本开始，配置服务器必须组成副本集的形式运行，这取代了早期版本中使用的同步机制。这种改进不仅提高了配置服务器的可用性，还简化了数据一致性的管理。在生产环境中，我们建议配置服务器副本集至少包含三个成员，并且最好将它们部署在不同的物理机器上，甚至考虑地理分布以提高容错能力。

配置服务器的启动流程

让我们通过一个实际的例子来了解如何启动配置服务器。假设我们有三台专门用于配置服务器的机器，IP 地址分别为 192.168.1.10、192.168.1.11 和 192.168.1.12。

首先，我们需要在每台机器上启动 mongod 进程，并指定相应的参数：

|
# 在第一台配置服务器上执行
$ mongod --configsvr --replSet configRS --bind_ip localhost,192.168.1.10 --dbpath /var/lib/mongodb
 
# 在第二台配置服务器上执行  
$ mongod --configsvr --replSet configRS --bind_ip localhost,192.168.1.11 --dbpath /var/lib/mongodb
 
# 在第三台配置服务器上执行
$ mongod --configsvr --replSet configRS --bind_ip localhost,192.168.1.12 --dbpath /var/lib/mongodb

这里的 --configsvr 参数告诉 mongod 进程这将作为配置服务器运行，这会对数据库的行为产生一些特殊的限制。比如，客户端只能向 config 和 admin 数据库写入数据，其他数据库都是只读的。

启动所有配置服务器后，我们需要将它们初始化为一个副本集：

|
$ mongo --host 192.168.1.10 --port 27019

然后在 mongo shell 中执行初始化命令：

|
rs.initiate({
  _id: "configRS",
  configsvr: true,
  members: [
    { _id: 0, host: "192.168.1.10:27019" },
    { _id: 1, host: "192.168.1.11:27019" },
    { _id: 2, host: "192.168.1.12:27019" }
  ]
})

数据一致性保障机制

配置服务器承担着分片集群全局元数据管理的核心职责，对数据一致性具有极高要求。MongoDB 在对配置服务器进行写操作时采用「majority」级别的写关注，读取时同样使用「majority」级别的读关注。 此机制保证了仅当大多数配置服务器节点确认后元数据更改才被提交，并确保读取数据的一致性与可用性。通过这种设计，集群能够稳健地维持全局状态一致，防止发生路由分歧和元数据冲突，最大限度保障分片集群的高可用与数据正确性。

配置服务器资源规划

配置服务器主要存储集群元数据信息，对磁盘容量需求有限，但对网络带宽与 CPU 性能有一定要求。其需高效应对大量 mongos 路由进程的元数据查询请求及分片节点的状态上报。为降低系统资源竞争及保证元数据高可用性，建议配置服务器独立部署于专用物理主机上，切勿与分片节点或应用服务器混布，以避免集群元数据管理受到业务流量波动的影响。

下图展示了配置服务器在分片集群架构中的中心地位：

从这个架构图可以看出，配置服务器处于整个分片集群的核心位置。mongos 进程需要从配置服务器获取路由信息，各个分片也需要向配置服务器报告数据块的变化情况。这种中心化的元数据管理方式虽然增加了配置服务器的重要性，但也大大简化了集群管理的复杂度。

mongos 路由进程

当配置服务器副本集准备就绪后，下一步就是启动 mongos 进程。mongos 是 MongoDB 分片集群中的路由层，它充当应用程序和分片之间的智能代理。与传统的数据库代理不同，mongos 不仅仅是简单地转发请求，它还会根据查询条件和分片键来智能地决定将请求发送到哪个或哪些分片上。

mongos 进程有一个重要的特点：它本身不存储任何数据。所有的路由决策都基于从配置服务器获取的元数据信息。这种无状态的设计使得 mongos 非常适合水平扩展，我们可以根据应用负载的需要启动多个 mongos 实例来提供更好的性能和可用性。

mongos 的启动和配置

启动 mongos 进程需要告诉它配置服务器的位置。假设我们的配置服务器副本集已经在前面设置好了，现在我们可以这样启动 mongos：

|
$ mongos --configdb configRS/192.168.1.10:27019,192.168.1.11:27019,192.168.1.12:27019 \
         --bind_ip localhost,192.168.1.100 \
         --logpath /var/log/mongos.log

以下为关键配置参数的专业说明：--configdb 参数用于指定配置服务器副本集的连接字符串，其格式为「副本集名称/节点地址列表」。mongos 进程将通过该信息连接配置服务器，以实时获取集群全局元数据。

--bind_ip 参数用于定义 mongos 监听的网络接口。生产部署时，建议同时绑定本地回环地址与业务网段，既保障本地运维管理，也确保应用服务器能够顺利接入。

mongos 默认监听 27017 端口，与标准 mongod 实例保持一致。这一设计降低了客户端访问和集群迁移的门槛，便于已有系统的平滑切换。

mongos 部署最佳实践

在生产环境中，mongos 的部署需综合考量性能、高可用性及运维复杂度。推荐至少部署两台及以上 mongos 实例以消除单点故障风险，确保节点故障时可无缝切换，提升业务系统的连续性。

mongos 实例数量并非越多越优。冗余过多会无谓增加配置服务器的压力，每台 mongos 都会周期性读写元数据，影响配置服务性能。一般场景下，部署 3-5 台 mongos 即可覆盖绝大多数高可用和并发需求。

从网络拓扑设计角度，建议将 mongos 节点部署于距离分片及应用服务器物理距离较近的位置，从而有效降低查询和数据路由时的网络时延，提升整体性能表现。

预检查与状态确认

以名为 rs0 的副本集为例，其成员分布于 192.168.2.10、192.168.2.11 和 192.168.2.12。转型操作前，须全面核查副本集当前运行状态：

|
$ mongo 192.168.2.10

然后使用 rs.status() 命令检查副本集的健康状况：

|
rs.status()

这个命令会返回详细的副本集状态信息，包括哪个节点是主节点，哪些是从节点，以及各个节点的复制状态。确保所有节点都处于健康状态是转换过程的前提条件。

配置分片服务器参数

从 MongoDB 3.4 版本开始，所有作为分片使用的 mongod 实例都必须使用 --shardsvr 参数启动。这个参数告诉 mongod 进程它将作为分片集群的一部分运行，这会影响一些内部行为，比如默认的数据块大小等。

为了避免服务中断，我们需要按照特定的顺序重启副本集的成员。首先重启所有的从节点，然后让主节点降级，最后重启原来的主节点：

|
# 重启第一个从节点
$ mongod --replSet "rs0" --shardsvr --port 27017 --bind_ip localhost,192.168.2.11
 
# 重启第二个从节点  
$ mongod --replSet "rs0" --shardsvr --port 27017 --bind_ip localhost,192.168.2.12

等待从节点重启完成并重新加入副本集后，我们需要让当前的主节点主动降级：

|
$ mongo 192.168.2.10

|
rs.stepDown()

然后重启原来的主节点：

|
$ mongod --replSet "rs0" --shardsvr --port 27017 --bind_ip localhost,192.168.2.10

将副本集注册为分片

当所有的副本集成员都以分片模式重启后，我们就可以将这个副本集添加到分片集群中了。连接到 mongos 的 admin 数据库：

|
$ mongo 192.168.1.100:27017/admin

使用 sh.addShard() 命令添加分片：

|
sh.addShard("rs0/192.168.2.10:27017,192.168.2.11:27017,192.168.2.12:27017")

需要注意的是，我们不需要在连接字符串中列出副本集的所有成员。mongos 会自动发现副本集的其他成员。但是为了提高连接的可靠性，建议至少提供两个成员的地址。

成功添加分片后，我们可以使用 sh.status() 命令查看集群的状态：

|
sh.status()

这个命令会显示当前集群中的所有分片信息，包括分片的标识符、副本集成员等详细信息。

应用程序连接方式的迁移

当副本集成功转换为分片后，最关键的一步是将所有的客户端应用程序从直接连接副本集改为连接 mongos。这个步骤必须彻底执行，因为分片功能只有在所有请求都通过 mongos 路由时才能正常工作。

如果部分应用程序仍然直接连接到分片上的副本集，可能会导致数据不一致或查询结果不完整的问题。为了防止这种情况，我们建议在网络层面设置防火墙规则，确保只有 mongos 进程能够直接访问分片节点。

这个部署架构展示了应用程序如何通过负载均衡器连接到多个 mongos 实例，从而获得高可用性和负载分散的效果。

集群容量扩展

随着业务的持续发展，即便是经过分片的数据库集群也可能会遇到容量瓶颈。当现有的分片无法满足不断增长的数据量和访问负载时，我们需要考虑向集群中添加更多的分片。

添加全新的分片节点

当我们需要扩展集群容量时，最直接的方法就是创建一个全新的副本集并将其添加为新的分片。这个过程相对简单，因为新的分片开始时是空的，不会涉及现有数据的迁移问题。

假设我们要添加一个名为 rs1 的新分片，运行在三台新服务器上：192.168.3.10、192.168.3.11 和 192.168.3.12。首先，我们需要在这些服务器上启动 mongod 进程并组成副本集：

|
# 在每台新服务器上启动 mongod
$ mongod --replSet "rs1" --shardsvr --port 27017 --bind_ip localhost,192.168.3.10
$ mongod --replSet "rs1" --shardsvr --port 27017 --bind_ip localhost,192.168.3.11  
$ mongod --replSet "rs1" --shardsvr --port 27017 --bind_ip localhost,192.168.3.12

然后初始化新的副本集：

|
rs.initiate({
  _id: "rs1",
  members: [
    { _id: 0, host: "192.168.3.10:27017" },
    { _id: 1, host: "192.168.3.11:27017" },
    { _id: 2, host: "192.168.3.12:27017" }
  ]
})

当新副本集准备就绪并选出主节点后，我们就可以将其添加到分片集群中：

|
sh.addShard("rs1/192.168.3.10:27017,192.168.3.11:27017,192.168.3.12:27017")

新分片添加成功后，MongoDB 的自动平衡器会逐步将现有分片上的数据块迁移到新分片上，从而实现负载的重新分布。这个过程是自动进行的，通常不需要人工干预。

整合现有副本集的策略

在某些情况下，我们可能已经有多个独立运行的副本集，希望将它们整合到一个分片集群中。这种场景在企业进行系统整合或者多个项目合并时比较常见。 整合现有副本集的一个关键前提是，这些副本集中不能有相同名称的数据库。例如，如果我们有三个副本集：

• 副本集 A 包含博客数据库（blog）
• 副本集 B 包含日历数据库（calendar）
• 副本集 C 包含邮件、电话和音乐数据库（mail、tel、music）

在这种情况下，我们可以将这三个副本集都添加为分片，最终得到一个包含五个数据库的分片集群。但是，如果有第四个副本集也包含名为「tel」的数据库，mongos 就会拒绝添加它，因为数据库名称冲突会导致路由混乱。 所以在进行副本集整合之前，我们需要仔细规划数据库的命名空间，必要时可能需要重命名某些数据库以避免冲突。

数据分片的配置流程

仅仅向集群中添加分片并不会自动让数据获得分片的好处。MongoDB 采用的是显式分片的策略，也就是说，我们必须明确指定哪些数据库和集合需要进行分片。

|
db.enableSharding("music")

|
sh.shardCollection("music.artists", {

这个流程图展示了 MongoDB 分片集群中数据写入和自动平衡的完整过程。当应用程序写入数据时，mongos 会根据分片键自动选择合适的分片；同时，后台的平衡器会持续监控数据分布情况，在必要时进行数据块的分割和迁移。

分片集群数据组织原理

在大规模（数百万乃至数十亿文档）环境下，mongos 路由器须高效、精准地定位任意文档。MongoDB 通过设计高效的元数据结构，实现了这一能力。

Chunk（数据块）

理论上，若为每个文档分别维护位置映射，随文档数量扩大，元数据规模将不可控、引发资源瓶颈。因此，MongoDB 引入了 “chunk（数据块）” 概念。每个 chunk 表示一组分片键范围连续的文档集合，且每个 chunk 始终全部落在同一个分片节点上。系统仅需维护 chunk 到分片的映射表，极大降低元数据规模和路由复杂性。

以典型用例说明：若用户集合以年龄为分片键，则可存在一个 chunk 覆盖 18-25 岁区间。mongos 路由查询（如 age=22）时，只需定位包含此范围的 chunk 并转发至对应分片，保证高效的数据定位和访问。

动态 Chunk 分裂机制

随着系统写入压力和数据量持续增长，个别 chunk 容量可能迅速膨胀。MongoDB 通过实时监控各 chunk 大小，一旦检测到超出配置阈值，会自动在合适分片键处将其拆分为两个更小的 chunk。该机制可递归触发，直到所有 chunk 均处于理想大小分布。 例如，原本覆盖 18-25 岁的 chunk，可根据增长趋势进一步拆为 18-21、22-25 等更细粒度的区块，增强负载均衡性及查询性能。

Chunk 边界的无重叠性

MongoDB 要求所有 chunk 的分片键范围严格无重叠，保证每份文档仅归属于唯一 chunk。这一约束直接消除了多路定位和“数据幽灵”问题，确保查询单一性和数据一致性。 例如，不允许并存覆盖区间为 18-22 岁 和 20-25 岁的 chunk，否则会引起 20-22 岁段的路由歧义和一致性隐患。

分片键类型约束

受限于 chunk 边界不可重叠的设计，MongoDB 不支持数组字段作为分片键。若以数组分片（如 [18,25,30]），则单文档可能同时命中多个 chunk 区间（分别对应三个年龄值），造成所属 chunk 不唯一，致使路由及数据一致性机制失效。因此，分片键必须为单一值字段或复合单一值字段组合，是分布式架构正确性的强制要求。

数据块与物理存储的区别

我们需要特别强调，chunk 纯属逻辑层级，用于元数据管理与路由决策，不等同于底层物理存放结构。很多同学会误以为，同一 chunk 内文档物理上必定邻接或聚集，实际上并不是这样。分片节点上的物理文档布局与普通 MongoDB 集合一致，chunk 信息仅存在于配置服务器元数据集，用于 mongos 的查询、写入路由和数据迁移协调。

这个流程图清晰地展示了查询路由和数据块管理的两个并行过程。上半部分展示了一个典型的查询是如何被路由到正确分片的，下半部分则展示了系统如何自动监控和管理数据块的大小。

数据块范围与分割策略

每个数据块都有明确的边界，这些边界决定了哪些文档属于该数据块，也影响了查询的路由效率和数据的分布均匀性。

数据块范围的定义规则

当我们首次对一个集合启用分片时，整个集合被视为一个巨大的数据块。这个初始数据块的范围是从负无穷到正无穷，在 MongoDB 的内部表示中对应着 $minKey 到 $maxKey 这样的特殊值。

随着数据的增长和写入操作的进行，这个初始数据块会在适当的时候被分割。分割总是在某个特定的分片键值处进行，我们称这个值为「分割点」。分割后，原来的大数据块变成了两个较小的数据块：一个包含从负无穷到分割点（不包含分割点）的文档，另一个包含从分割点（包含分割点）到正无穷的文档。

让我们通过一个具体的用户管理系统来理解这个过程。假设我们按年龄分片，初始时所有用户都在一个数据块中：

当这个数据块增长到需要分割时，可能在年龄 25 处进行分割：

如果块1继续增长并在年龄 12 处再次分割：

复合分片键的范围管理

当我们使用复合分片键时，数据块的范围管理变得更加复杂，但遵循的基本原理与单字段分片键相同。复合键的排序遵循 MongoDB 的复合索引排序规则，就像我们对多个字段进行排序时的逻辑一样。

考虑一个社交网络应用，我们使用 {username: 1, age: 1} 作为复合分片键。数据块可能会有如下的范围：

|
// 数据块 A
{
  min: { username: $minKey, age: $minKey },
  max: { username: "user107487", age: 73 }
}
 
// 数据块 B  
{
  min: { username: "user107487", age: 73 },
  max: { username: "user114978", age: 119

这种复合键的排序方式有一个重要的特点：mongos 可以高效地路由那些指定了用户名（或同时指定了用户名和年龄）的查询，但对于仅指定年龄的查询，可能需要检查多个甚至所有的数据块。这就是为什么分片键字段的顺序选择非常重要的原因。

数据块分割的触发条件

数据块的自动分割由各个分片的主节点负责监控和执行。当写入操作导致某个数据块的大小超过预设阈值时，该分片的主节点会检查是否可以进行分割。这个检查不仅包括数据块的大小，还要考虑是否存在合适的分割点。

分割点的选择有严格的限制条件。最重要的是，具有相同分片键值的所有文档必须位于同一个数据块中。这意味着数据块只能在分片键值发生变化的地方进行分割。

让我们通过一个实际的例子来说明这个限制。假设我们有一个按用户名分片的消息集合，其中包含以下文档：

|
{ username: "alice", message: "你好" }
{ username: "alice", message: "今天天气不错" }
{ username: "alice", message: "准备出门了" }
// 可以在这里分割
{ username: "bob", message: "工作中..." }
{ username: "bob", 

在这个例子中，所有属于 alice 的消息必须在同一个数据块中，所以分割只能在用户名边界处进行。如果大多数消息都来自同一个用户，那么即使数据块很大，也可能无法找到合适的分割点。

这个分割限制强调了选择合适分片键的重要性。一个好的分片键应该具有足够的值多样性，确保数据可以被均匀地分布到多个数据块中。 考虑以下几种分片键选择的对比：

不理想的分片键：状态字段

|
// 只有三种可能的值：active, inactive, pending
{ status: "active", userId: "12345", ... }

这种分片键最多只能创建三个数据块，限制了分片的扩展性。

较好的分片键：用户ID

|
// 具有很高的值多样性
{ userId: "507f1f77bcf86cd799439011", ... }

用户ID通常具有很好的分布特性，可以支持大量的数据块分割。

最优的分片键：复合键

|
// 结合了访问模式和分布特性
{ region: "asia", timestamp: ISODate("2023-10-01"), ... }

这种设计既考虑了查询的locality（同一区域的数据通常一起查询），又保证了足够的分割灵活性。

配置服务器可用性的关键影响

数据块分割过程对配置服务器的可用性有严格的依赖。当分片需要执行分割操作时，它必须能够连接到配置服务器来更新元数据信息。如果配置服务器不可用，分割操作就会失败。

更严重的是，如果配置服务器持续不可用，而分片继续接收大量写入请求，就可能出现「分裂风暴」的情况。在这种情况下，分片会反复尝试分割同一个过大的数据块，每次都因为无法更新元数据而失败，然后再次尝试。这种重复的失败尝试会消耗大量的 CPU 和 I/O 资源，严重影响分片的正常服务能力。

自动平衡与高级特性

MongoDB 分片集群不仅具备水平扩展能力，更具备自动化与智能管理特点。自动平衡器、多语言排序规则支持以及变更流等特性，共同构成高度自动化、企业级可靠性的分布式数据库平台。

自动平衡器

自动平衡器是 MongoDB 分片架构中负责分布式数据块迁移的关键后台服务。从 MongoDB 3.4 开始，平衡器作为单一进程运行于配置服务器副本集的主节点，有效消除了早期版本平衡器部署在多 mongos 进程导致的调度一致性难题。

平衡器持续监控各分片的数据块分布，通过动态衡量集群整体负载状况，自适应地设定迁移触发阈值。当检测到某一分片的数据块数量显著高于集群平均水平时，平衡器便自动协调迁移，将部分数据块转移至负载较低的分片，实现存储和流量的全局均衡。

自新版本起，平衡器支持并发数据迁移操作。每个分片在某一时刻可作为源或目标参与一次迁移，整个集群并发迁移数上限为分片总数的一半，大幅提升了大规模场景下的负载再平衡效率与响应速度。

数据迁移的高可用与一致性保障

MongoDB 分片环境中的数据块迁移过程对前端应用完全透明，真正实现了在线数据再分布。迁移过程中，相关读写操作依然通过 mongos 路由到原始分片，直至迁移与元数据切换全部完成，迁移窗口最小化对业务的影响。

元数据切换后，所有新请求自动路由到目标分片。若 mongos 访问到已迁移的数据块旧位置，会收到特定错误码，随后自动刷新路由信息并重试，保障数据一致性与服务连续性。

该异步数据迁移和分布式路由自动同步机制大幅降低了维护成本和操作风险。迁移行为及路由变更均有详细日志记录，可为故障排查和运维审计提供支撑。

多语言排序规则下的分片一致性设计

MongoDB 分片机制原生支持复杂多样的 Collation（排序规则），满足国际化、语言本地化业务场景下对字符串比对与排序的定制要求。

为确保集群范围的分片键比对拥有确定性，分片集合在应用自定义排序规则时须严格遵循：

1. 集合须声明一个以分片键为前缀的索引；
2. 该索引必须采用 "simple"（字节序）排序规则。

此规范可确保分片键比较在全局一致，避免排序规则差异引发的分片路由歧义及潜在数据异常。

例如，在国际化评论系统的应用场景下，评论内容字段可按需配置多语言排序，但分片键相关索引必须强制使用 simple 排序规则，以保障分布式环境下分片路由与查询的一致性与正确性：

|
// 创建支持中文排序的索引，但分片键部分使用simple排序
db.comments.createIndex(
  { userId: 1, content: 1 },
  { 
    collation: { locale: "zh", strength: 1 },
    partialFilterExpression: { content: { $exists: true } }
  }
)
 
// 分片键索引使用simple排序
db.comments.createIndex({ userId: 1 }, { collation: { locale: "simple" } })

实时变更流

变更流为分片集群提供了强大的实时数据监控能力。这个特性允许应用程序订阅数据库、集合或者整个集群的数据变更事件，比传统的 oplog 尾随方式更加安全和易用。

在分片环境中，变更流的实现面临着独特的挑战。由于变更可能发生在任何分片上，系统必须确保变更事件的全局顺序。MongoDB 通过全局逻辑时钟机制解决了这个问题，确保不同分片上的变更事件可以按照正确的时间顺序被应用程序接收。

当应用程序从 mongos 打开一个变更流时，mongos 会协调所有相关分片的变更事件。每当收到一个变更通知时，mongos 都会确认没有其他分片有更新的变更，然后才将事件推送给应用程序。这个确认过程保证了事件的顺序性，但也意味着变更流的延迟会受到集群规模和地理分布的影响。

在分片集群中使用变更流时，有几个重要的注意事项需要了解。首先，所有的变更流操作都必须通过 mongos 进行，不能直接连接到分片上。这个要求确保了变更事件的全局协调和正确排序。

其次，某些批量操作可能会产生意外的变更通知。例如，使用 multi: true 选项的更新操作在分片集合上执行时，可能会为一些孤立文档（orphaned documents）发送变更通知。这些孤立文档是数据迁移过程中的临时状态，通常会在后续的清理过程中被移除。

最后，如果在变更流开启期间有分片被移除，可能会导致变更流游标关闭，且这个游标可能无法完全恢复到之前的状态。在设计依赖变更流的应用程序时，需要考虑这种情况下的错误处理和恢复策略。

小结

MongoDB 分片集群作为高度复杂且工程化的分布式数据库系统，有效地将海量数据的横向扩展、负载均衡与高可用机制抽象为标准化的架构组件。配置服务器负责全局元数据和路由信息的集中管理，mongos 实现统一的查询路由与请求协调，自动平衡器则动态调整分片，保证数据分布的均衡性及系统的伸缩性。 各模块协同工作，确保了分片集群在高并发、海量数据场景下的稳定性和可扩展性。

这个命令有几个重要的要点需要理解。首先，"music.artists" 指定了要分片的集合，格式是「数据库名.集合名」。其次，{"name": 1} 定义了分片键，这里选择了 name 字段作为分片的依据，1 表示升序索引。