事务与副本集与分片与 Balancer

• 多文档事务需在副本集/分片集群上运行，读关注默认 local、可选 majority
• WiredTiger 提供 MVCC 快照隔离，事务读写自洽快照
• 事务提交依赖多数派写入与 prepare 阶段

MongoDB 4.0 起支持副本集上的多文档事务，4.2 起支持分片集群上的跨分片事务。事务底层基于 WiredTiger 存储引擎的 MVCC（多版本并发控制）：当事务开始时，WiredTiger 为事务创建一个快照，事务内所有读操作都基于该快照，保证可重复读（repeatable read）级别，事务之间互不干扰；写入通过版本链实现，旧版本保留供其他读事务使用。事务提交时，数据先写入 WiredTiger 的 prepare 状态，再通过副本集多数派确认（replicate to majority）后真正提交，保证持久化与一致性。若事务超时或冲突，MVCC 会检测写冲突并回滚。多文档事务的原子性以"事务"为单位，可跨多个文档、多个集合（4.2 起可跨分片）。

多文档事务的核心是 WiredTiger 的 MVCC 快照隔离。快照隔离让事务内读取稳定一致，写冲突检测让并发事务不会互相覆盖。提交依赖多数派写入，把原子性与持久性绑定到副本集多数派。理解 MVCC 快照 + 多数派提交两个环节，是理解 MongoDB 事务实现的关键。事务的原子性范围从单文档扩展到多文档，代价是性能与锁开销。

• 选举在 primary 不可达时触发，基于多数派选举协议
• 类似 Raft 的 term、心跳、投票，但非严格执行 Raft
• priority 与 votes 影响选举结果

MongoDB 副本集的选举机制借鉴了 Raft 共识算法的思想，但并非严格实现 Raft。当 primary 因网络分区、崩溃或滞留超过选举超时时间（默认 10 秒）时，secondary 会发起选举：节点通过心跳（heartbeat）感知 primary 失联，可投票成员（votes 非 0）进行投票，获得多数派（超过半数可投票成员）投票的节点成为新 primary。选举结果受 priority（优先级）影响，priority 高的 secondary 更可能当选；若候选节点与多数派不可达（如网络分区），则无法当选，集群进入只读或延迟状态。MongoDB 的选举机制与 Raft 类似但有自己的实现（如使用 term、epoch、选举锁定），被称为"类 Raft"协议。

MongoDB 选举是"基于多数派的类 Raft 协议"。多数派投票保证不会出现两个 primary（防止脑裂），priority 控制选主倾向，超时机制触发选举。理解多数派与 priority 是选举的关键。与 Raft 的差异在于 MongoDB 的 term/epoch 与投票实现细节，因此说"类 Raft"而非"严格 Raft"。选举期间写入会失败，需应用端重试。

• mongos：路由与查询分发，对应用透明
• config server：存储元数据（分片范围、chunk 分布）
• shard：实际数据存储，每个 shard 是一套副本集

MongoDB 分片集群由三部分组成：mongos（路由）、config server（元数据）、shard（数据分片）。mongos 是应用访问的入口，负责把查询路由到正确的分片，对应用透明，应用只需连接 mongos；config server 是集群元数据存储，保存所有 chunk 的分片范围、分片键与数据分布等元数据，一般以副本集形式部署（3 个节点）；shard 是真正存储数据的单位，每个 shard 通常是一个副本集，存储数据的一部分 chunk。当应用写入时，mongos 根据分片键计算文档应属于哪个 chunk，再路由到对应 shard；读取时 mongos 把查询广播到相关 shard 并合并结果。三者协作实现分布式扩展与路由。

分片集群是"路由 + 元数据 + 数据"三层架构。mongos 无状态、可横向扩展，负责路由；config server 保存元数据，保证路由正确；shard 承载数据并按分片键分布。理解 mongos 的路由与 config 的元数据，是理解分片集群的关键。分片让数据水平扩展，但查询与事务复杂度随之上升。

• 基数：分片键取值种类要多，保证分布均匀
• 频率：避免高频热点值集中于一个分片
• 单调性：单调递增键会使写入集中在最新分片，造成热点

分片键的选择直接决定数据在分片间的分布质量，需评估三个特性：基数（cardinality）——分片键应有足够多的不同取值，否则无法把数据分散到多个分片；频率（frequency）——避免某个取值被大量文档频繁使用（热点），否则该取值所在的分片会成为热点；单调性（monotonicity）——单调递增的分片键（如自增 ID、时间戳）会使新数据总是写入最后一个分片，造成写入热点，因此常用哈希分片键或对单调键做哈希打散。好的分片键应"高基数、低频率、非单调"（或用哈希分片），使数据与写入均匀分布到各分片。分片键一旦选定不可更改，需谨慎设计。

分片键是分片集群的"分布规则"，其核心目标是"均匀"。基数决定可分散度，频率决定是否热点，单调性决定是否写入集中。哈希分片是应对单调键的常用手段。分片键不可更改是其最重要约束，选错后果严重。理解三个特性，才能选出均匀分布的分片键。

• Primary：唯一处理写操作，数据同步给 Secondary
• Secondary：复制数据，可读（readPreference 可读），可入选
• Arbiter：仅参与选举，不存数据

副本集由多个 mongod 节点组成，有 Primary、Secondary、Arbiter 三类角色。Primary 是唯一接受写操作的节点，所有写入都经它，并异步/同步复制到 Secondary；Secondary 复制 Primary 的数据（通过 oplog），可用作读（设置 readPreference）、可参与选举成为新 Primary，也用于备份与故障转移；Arbiter 是只参与选举投票、不存储任何数据的轻量节点，用于在只有两个数据节点的部署中凑足多数派（如 2 数据节点 + 1 Arbiter = 3 个投票节点），保证选举公平。故障时 Secondary 通过选举成为新 Primary，写入自动切换。Arbiter 不提供数据，不承担读写。

副本集是三角色分工：Primary 写、Secondary 复制可读、Arbiter 凑票不存数据。Arbiter 的价值在于用最低成本获得多数派，避免双节点脑裂。理解写入只能走 Primary、多数派决定写可见性，是理解副本集的核心。Secondary 可用于读与故障转移，但读一致性需注意。

• chunk 是数据迁移与分布的最小单位，超限自动分裂
• Balancer 按 chunkSize 均衡各分片
• jumbo chunk 无法分裂/迁移，导致不均衡与性能下降

分片集群把数据按分片键划分为多个 chunk，每个 chunk 覆盖一段分片键范围，是数据分布与迁移的最小单位。当某个 chunk 超过配置的 chunkSize（默认 64MB）时，mongos 会自动把该 chunk 分裂成两个更小的 chunk，使数据更均匀。Balancer 会在各分片间迁移 chunk，使每个分片的数据量大致均衡。jumbo chunk 是无法被分裂的 chunk（因为其分片键范围内所有文档都指向同一个分片键值，无法再按分片键拆分），它会导致该分片数据超过均衡阈值、无法迁移，造成数据倾斜与查询集中在热点分片，严重时影响查询性能。chunkSize 越小，chunk 越多，均衡粒度越细但迁移频繁；过大则迁移在大粒度进行，均衡不精细。

chunk 的"分裂 + 均衡"是分片集群自动分布数据的机制。分裂受 chunkSize 驱动，均衡由 Balancer 完成。jumbo chunk 是分裂与均衡的"死穴"，由分片键取值单一导致，会破坏均衡并降低查询性能。理解 chunkSize 对分裂与均衡粒度的影响、jumbo chunk 的成因，是评估分片集群健康的关键。

• 跨分片事务由 mongos 作为协调者，采用两阶段提交
• 第一阶段 prepare：各分片准备并持久化事务
• 第二阶段 commit：多数派确认后提交

MongoDB 跨分片事务（4.2+）由 mongos 充当协调者，实现类似两阶段提交的协议。第一阶段 prepare：mongos 把事务发送到参与的所有分片，各分片执行写入并进入 prepare 状态，持久化事务日志（为可恢复性），返回 prepare 成功；第二阶段 commit：当所有参与分片都 prepare 成功后，mongos 向各分片发送 commit 指令，各分片提交本地事务并写副本集多数派确认。若在 prepare 或 commit 阶段发生协调者（mongos）或分片故障，事务依赖各分片持久化的 prepare 事务状态与协调者恢复机制，通过事务的唯一标识（transaction id）在故障后重新协调：已 prepare 的事务可被提交或回滚（abort），未完成 prepare 的事务被回滚，保证最终一致性。MongoDB 用事务协调器（transaction coordinator）与持久化事务日志保证恢复。

跨分片事务的核心是"协调者 + 两阶段提交 + 持久化事务状态"。协调者（mongos）负责 prepare 与 commit 两阶段，各分片持久化 prepare 状态使事务可恢复，故障时通过事务 id 重新协调提交或回滚。理解"prepare 持久化可恢复"与"协调者重试"是回答故障恢复的关键。跨分片事务的一致性以最终提交/回滚保证，但性能与复杂度较高。

• 事务读关注默认 local（未显式设置时逐级回退到客户端默认值）
• 可选 majority 读关注以避免读到可能被回滚的数据
• write concern 决定提交所需确认副本数

MongoDB 事务的读关注（read concern）默认是 local：事务级未设置时回退到会话级，会话级未设置时回退到客户端级，而客户端默认读关注为 local。local 读关注下，事务可以读到自己的未提交写入，但读到的其他并发事务写入可能随后被回滚；因此若事务需要避免读到"可能被回滚"的数据，可将事务读关注设置为 majority：majority 读关注保证只读已被多数派确认（已提交）的数据，避免读到脏数据。事务内的 write concern 决定提交时需多少副本确认（如 w:1 或 w:majority），影响持久化强度与性能；read concern 决定事务读取的可见性（local 读取本地已写、majority 读取多数派已提交）。组合影响：write concern 越高，提交越慢但更持久；read concern majority 更安全但需等待多数派确认，增加延迟。事务内建议用 write concern majority 保证持久性；读关注默认 local，强一致场景可设 majority（或 5.0+ 的 snapshot），两者都增加等待，需在性能与一致性间权衡。

事务读关注默认是 local；使用 majority 读关注是为了"避免读到已回滚数据"。理解 write concern 控制"写多持久"，read concern 控制"读多可见"，是权衡的关键。用 majority 会导致读取等待多数派确认，性能下降。因此 majority 读关注常用于一致性要求高的场景，接受性能代价。

• Balancer 是后台进程，负责在各分片间迁移 chunk
• 通过比较各分片 chunk 数量决定迁移
• 迁移在低峰期执行，可配置窗口

Balancer 是分片集群中的后台进程，负责在各分片间自动迁移 chunk 以保持数据均衡。它定期比较各分片的 chunk 数量，当某个分片的 chunk 数明显多于其他分片（超过均衡阈值）时，Balancer 选一个 chunk 从多分片迁移到少分片。迁移过程：源分片把 chunk 的数据复制到目标分片，复制完成后更新 config server 的元数据，把该 chunk 的归属切换过去，并删除源分片上的副本。迁移是异步的，可配置在指定时间窗口（如低峰期）执行，迁移期间会占用网络与 IO 带宽，影响读写性能。Balancer 可手动开关（sh.startBalancer()/sh.stopBalancer()）。

Balancer 的核心是"按 chunk 数量均衡 + 异步迁移 + 元数据更新"。迁移的代价是带宽与 IO，因此建议配置迁移窗口避开高峰。理解"迁移 = 复制 + 元数据切换 + 删除"，以及迁移对线上性能的影响，是管理分片集群的关键。

• config server 存储集群元数据（chunk 范围、分片键、配置）
• 以副本集形式部署，保证元数据高可用
• mongos 读取 config server 做路由

config server 是分片集群的元数据中心，存储集群的所有元数据：分片键、chunk 的范围与归属、各分片的信息、集合的配置等。mongos 启动时从 config server 加载元数据，之后查询时根据分片键在本地缓存元数据决定路由。config server 通常以副本集形式部署（3 个节点），保证元数据的高可用与一致性，避免元数据丢失导致集群不可用。若 config server 故障，集群无法做路由与元数据变更，但已缓存的路由与数据访问可能受影响。因此 config server 的可用性至关重要，需独立且高可用部署。

config server 是分片集群的"大脑"，保存路由所需的元数据。理解它"以副本集高可用"与"mongos 依赖其路由"两点，是理解分片集群的关键。config server 故障会导致整个集群无法正常路由，因此其高可用部署是硬性要求。

• 回滚发生在旧 primary 恢复后，其未复制到新 primary 的写入
• 通过 oplog 比较，回滚的写入被丢弃或保存到 rollback 目录
• 回滚数据的恢复方式

副本集回滚发生在旧 primary 恢复并重新加入集群时。当旧 primary 在故障期间写入了数据但未能复制到新 primary（因为多数派已选新 primary），旧 primary 的这些写入与多数派不一致，需回滚。回滚时，MongoDB 比较旧 primary 的 oplog 与新 primary 的 oplog，找出旧 primary 独有的写入（不在新 primary 上的），丢弃这些写入，使旧 primary 与集群多数派一致，然后作为 secondary 重新同步。被回滚的写入会保存到节点的 rollback 目录（BSON 文件），可用于人工恢复。回滚只发生在写入未被复制到多数派且旧 primary 重新当选失败的情况，回滚后数据以多数派为准。

回滚是"多数派覆盖少数派"的机制。旧 primary 的未复制写入在恢复后回滚，保证集群一致。理解回滚的触发条件（旧 primary 未复制写入 + 故障恢复）与结果（数据以多数派为准），是理解副本集一致性的关键。为减少回滚风险，写入应使用 w:majority。

• 基于 WiredTiger MVCC 快照隔离
• 事务提交依赖多数派写入
• 4.0 副本集、4.2 分片集群

MongoDB 多文档事务的实现基于 WiredTiger 存储引擎的 MVCC 快照隔离。事务开始时创建快照，事务内所有读取基于该快照，保证可重复读；写入通过版本链管理，冲突检测通过写锁实现。事务提交时，数据通过副本集多数派确认（write concern majority）持久化后才算提交，保证不会在故障后丢失。事务的原子性覆盖多个文档、多个集合，4.0 起支持副本集，4.2 起支持分片集群（跨分片事务用两阶段提交协调）。事务读关注默认 local（客户端默认值），需要避免读到可能被回滚的数据时可指定 majority。事务有超时（默认 60 秒）与写集大小限制。整体是"MVCC 快照 + 多数派提交 + 可恢复协调"的实现。

事务实现的三支柱是 MVCC 快照、多数派提交、协调恢复。MVCC 提供隔离，多数派保证持久一致，协调恢复保证跨节点原子性。理解这三个支柱，就能把握事务的正确性与性能代价。事务在一致性与性能间取舍，牺牲部分性能换取强一致。

• 哈希分片：均匀分布，适合单调键，但范围查询低效
• 范围分片：按分片键值区间分布，支持范围查询，但易热点
• Zone：按标签把数据分片到指定区域，实现数据本地化

MongoDB 提供三种分片策略。哈希分片（Hashed）：对分片键做哈希后按哈希值范围分片，数据分布均匀，适合单调递增等易热点键，但无法做范围查询（范围查询需广播到所有分片）。范围分片（Ranged）：按分片键的实际值区间划分 chunk，支持高效的范围查询（仅在相关分片查询），但单调键会导致写入热点，需要选择低热点键。Zone 分片：通过给分片设置标签（zone/tag），把特定分片键范围的数据路由到指定分片，实现数据本地化（如多租户隔离、合规要求、按地域存储）。三者适用场景不同：哈希保均匀、范围保范围查询、Zone 保本地化。

三种分片策略分别优化不同的目标：哈希解决分布均匀，范围解决范围查询，Zone 解决数据本地化。选型取决于业务：注重写入均匀且无范围查询用哈希，注重范围查询用范围（需注意热点），注重数据本地化/合规用 Zone。理解三者的取舍，是选择分片策略的关键。

• 跨分片事务 4.2+ 支持，但性能受限
• 事务内读偏好限制（必须路由到主节点）
• 聚合在分片集群的限制

跨分片事务在 MongoDB 4.2 起支持，但性能与功能有边界。性能上，跨分片事务需要 mongos 协调多个分片，采用两阶段提交，提交延迟高、网络开销大，且事务内涉及的分片越多，失败概率与性能下降越大，因此应避免大事务跨多分片。读偏好上，事务内的读操作必须路由到主节点（primary），不能使用 secondary 读偏好，因为事务需一致快照与可回滚的写；这限制了事务的读扩展。聚合在分片集群上，跨分片的 $group/$sort 等需要把数据合并到 merge 分片，内存与网络开销大，有 100MB 内存限制（可 allowDiskUse），部分阶段不能在分片间直接执行。跨分片事务适合一致性要求高的少量跨分片操作，不适合高吞吐。

跨分片事务的边界来自"协调多个分片的一致性保证"。性能瓶颈是两阶段提交的协调开销，读偏好限制是事务需主节点快照，聚合限制是跨分片合并的代价。理解这些边界，才能合理设计事务范围与查询，避免把大事务、跨多分片聚合放到高频路径。

• moveChunk 迁移期间占用网络与 IO，导致读写抖动
• 路由可能短暂放大（广播）或延迟
• 配置迁移窗口避开高峰

Balancer 迁移 chunk（moveChunk）期间，源分片需把 chunk 数据传输到目标分片，占用网络带宽与磁盘 IO，同时迁移期间 mongos 对涉及该 chunk 的查询可能因元数据切换而变慢或产生额外路由，造成读写抖动（moveChunk 抖动）。迁移也会让目标分片临时负载上升。为降低影响，可配置迁移窗口（balancer window），把迁移限定在业务低峰期（如凌晨），避开高峰读写；也可通过限流参数控制迁移带宽。对高频关键查询，避免在高峰期迁移，并及时监控迁移状态。迁移完成后元数据更新，路由恢复正常。

moveChunk 抖动的本质是"迁移占用资源 + 元数据切换的间歇性路由开销"。管理手段是配置迁移窗口、限制迁移带宽、监控迁移。理解"迁移是资源密集的异步操作"，才能规划好迁移窗口避开高峰。迁移窗口是分片集群运维的常用手段。

• priority 决定节点当选的优先级
• votes 决定节点是否参与投票
• votes 为 0 的成员不参与投票，且因 priority 必须为 0 而无法被选举为 primary

副本集节点的 priority 决定其当选 primary 的优先级，priority 越高，选举时越倾向当选；votes 决定该节点是否参与投票（votes 为 0 或 1）。votes 为 0 的成员不参与投票，同时 MongoDB 要求 votes 为 0 的节点 priority 必须为 0，而 priority 为 0 的节点不会被选举为 primary，因此 votes 为 0 的成员既不能投票也不能当选。这类节点通常用于跨数据中心部署中的"非投票数据节点"（如偏远机房节点），不参与选举多数派计算，避免影响主数据中心的选主，只承担数据复制与读服务，不作为主节点候选。priority 与 votes 需结合理解：priority 控制"想不想当"，votes 控制"能不能投票"，两者共同决定节点在选举中的角色。

priority 与 votes 是选举的两个维度：priority 控"想不想当"，votes 控"能不能投票"。votes 为 0 的节点必须同时把 priority 设为 0，因此既不能投票也不能被选举，只能作为非投票数据节点提供复制与读服务。理解"投票权"与"被选举权"都由这两个参数决定，是回答选举配置的关键。这类配置常用于多数据中心与特殊网络拓扑。

• zone 把分片键范围映射到指定分片
• tag 为分片打标签
• 实现多租户隔离、合规数据本地化

MongoDB 分片集群通过 zone 与 tag 实现数据本地化。zone 是分片键值范围的映射，可把某个分片键范围的数据"锁定"到指定分片；tag 是给分片打上的标签。先给分片设置 tag（如 region 标签），再创建 zone 并把分片键某个范围绑定到该 zone，则对应范围的数据会被路由到打有该 tag 的分片。这样可实现多租户隔离（不同租户的数据分片到不同分片）、合规要求（数据需存储在特定地域）、数据本地化（按地域就近存储）。实现时需在配置中 addShardTag 与 addShardZone 绑定，并指定分片键范围。zone 是数据本地化的关键机制。

zone/tag 的本质是"把分片键范围映射到分片"，实现数据按业务维度（租户、地域）本地化。理解"tag 打标分片 + zone 绑定分片键范围"两步，是配置数据本地化的关键。多租户与合规场景强烈依赖 zone 实现数据隔离与就近存储。

• mongos 维护到各分片的连接池
• 会话（session）用于事务状态跟踪
• 事务需在会话内路由到正确分片

mongos 是分片集群的路由层，它维护到各分片的连接池，复用连接以降低开销。对于事务，MongoDB 使用会话（session）机制：事务必须在一个会话内执行，会话标识事务的状态；mongos 通过会话的 transactional 状态跟踪事务，确保同一事务内的所有读写路由到正确的分片，并协调 prepare/commit。会话亲和性指同一事务的多次操作需在相同会话与路由上下文中进行，以保证事务的一致协调。mongos 无状态，但通过会话维护事务上下文，支持跨分片事务。连接池与会话是 mongos 支持事务与高吞吐的基础。

mongos 的连接池负责连接复用，会话（session）负责事务状态跟踪与路由。理解"会话承载事务上下文"，是理解 mongos 为何能协调跨分片事务的关键。会话亲和性保证事务内操作的一致路由。连接池提升并发，会话保证事务正确。

• 事务写集需缓存在内存中，超过 WiredTiger 缓存限制报错
• 事务写集大小限制（默认约 100MB 或缓存限制）
• 通过拆分批次、缩小事务范围避免

MongoDB 事务会把所有写入的数据（写集）缓存在 WiredTiger 的缓存中，事务提交前不能被驱逐。当事务的写集过大，超过 WiredTiger 缓存可容纳的阈值（默认通过 cache 限制，事务写集上限约为缓存的一定比例，实际约 100MB 或更小），就会报 TransactionTooLargeForCache 错误。这是为了防止大事务撑爆缓存、阻塞其他操作的驱逐。设计上应拆分批次：把大批量写入拆成多个小事务，每个小事务只处理一部分数据，控制写集大小；同时避免在单个事务内处理过多文档或跨过多分片。合理设置事务范围（只包含必要操作）、分批提交，是规避该错误的关键。

TransactionTooLargeForCache 的根因是"写集需常驻缓存，过大撑爆缓存"。理解缓存限制与写集关系，才能设计出合理的事务规模。拆分批次、缩小事务范围是标准做法。处理大事务时，应评估写集大小并按批次提交，避免单个事务过大。