先给出几个判断，后续再详细探讨——在MongoDB分片集群中，若想同时确保数据的一致性与持久性，需要规避不少常见的陷阱。 一个典型的误解是：以为设置`readConcern: "majority"`就能读取到所有分片上一致的数据。实际上，该设置仅作用于单个分片内部。

readConcern: "majority" 在分片集群中仅对单个分片生效

设置了 `readConcern: "majority"` 后，跨分片读取时仍可能看到不一致的数据——这不是缺陷，而是设计初衷。每个分片本质上是独立的副本集，`readConcern: "majority"` 仅限定当前分片内部的读视图，不会协调其他分片的状态。 以下两个典型场景可以说明问题： - 在事务之外执行 `find().readConcern({level: "majority"})`，事务 t1 从 shard A 读到新值，而事务 t2 从 shard B 读到旧值。 - 直接使用 `mongosh` 连接某个 shard 的 mongod，手动设置 `readConcern`，结果返回 `ReadConcernMajorityNotA vailableYet` 错误。 出现这种情况的原因通常包括以下几点： - 该分片的副本集投票节点数量不合适——例如有4个节点但未配置仲裁节点（`votes: 0`），无法凑出 majority 投票。 - 写操作使用了 `writeConcern: {w: 1}`，导致 majority 视图始终落后于实际写入。 - WiredTiger 的 journal 被禁用（`storage.journal.enabled: false`），snapshot 机制无法获取稳定的 majority 级快照。

跨分片强一致性必须借助多文档事务

要实现跨分片的强一致性，必须显式启用事务。只有在开启事务，且所有操作落在同一个分片上（或通过 `allowDiskUse: true` 支持跨分片）时，MongoDB 才会启动分布式事务协调器（由 `mongos` 驱动），统一应用 `readConcern` 和 `writeConcern` 的约束。 实际应用中需注意以下几点： - 事务必须显式启动：调用 `session.startTransaction()`，不能依赖自动提交。 - 在分片集群中，事务内的所有集合操作必须满足“同分片”前提，否则会触发跨分片协调——性能明显下降，且要求同时使用 `writeConcern: {w: "majority"}` 和 `readConcern: "snapshot"`。 - 驱动版本需足够新：Node.js driver 至少 4.12 以上，旧版本不支持分片事务中 `snapshot` 级别的回滚语义。 一个常见错误：在代码中忘记传递 `session` 参数，或者在事务外部调用了 `updateOne`，导致事务降级为普通写入。

writeConcern: {w: "majority"} 是 readConcern 生效的必要条件

`readConcern: "majority"` 并非独立开关——它依赖于写操作已经获得了多数节点的确认。如果写入只等待主节点确认（`w: 1`），那么所谓的“多数视图”仅仅是主节点当前的瞬时状态，缺乏意义。 需牢记以下关键参数组合： - 副本集至少需要3个投票节点（奇数），且所有节点健康。如果是4节点集群，必须配置一个 `priority: 0, votes: 0` 的仲裁节点。 - 写操作必须显式指定：`updateOne(..., {writeConcern: {w: "majority"}})`，不要依赖连接字符串中的默认值。 - 在分片集群中，`mongos` 默认会将 writeConcern 转发给目标分片，但如果分片的副本集配置异常（例如某个 secondary 落后超过10秒），`w: "majority"` 可能超时失败。

崩溃恢复依赖 journal 与 fsync，而非 readConcern

`readConcern` 解决的是并发读写的可见性问题，并不负责处理宕机导致的数据丢失。持久性保障依赖于两个方面：journal 日志刷盘，以及定期的 fsync。 在 Ubuntu 系统中检查 journal 是否启用，可使用以下命令： ```bash mongod --version # 再检查 systemd service 文件里有没有 --journal 或 storage.journal.enabled: true ``` 几个容易被忽略的细节包括： - 即使启用了 journal，如果挂载磁盘使用了 `noatime,barrier=0` 等激进优化，WAL 日志仍可能丢失。 - `storage.syncPeriodSecs: 60`（默认值）意味着最多60秒未刷盘的数据可能丢失。生产环境建议设置为0或1。 - `validate` 命令（`db.runCommand({validate: "coll"})`）只能检测结构损坏，但无法发现因网络分区导致的逻辑不一致——例如某个分片漏同步了一段oplog。 要真正验证分片间的数据一致性，需使用 `dbHash` 对比各分片的校验和，或者通过 `sh.status()` 检查 chunk 的分布与迁移历史是否清晰。