前面几篇多次提到 w: "majority"，这篇把它彻底讲清楚。读写关注（read/write concern）是 MongoDB 控制持久性和一致性的核心参数——它们决定了「一个写入要被几个节点确认才算成功」「一个读取从哪个节点读、读到什么程度的一致」。理解了它们，才能在不同业务场景下精准调出「够用且不浪费」的持久性/一致性档位。
先把机制边界说清楚
读写关注是三个相关但独立的参数：
- writeConcern（写关注）：写操作要被几个节点确认才算成功。控制持久性。
- readPreference（读偏好）：读操作发到哪个节点（主还是从）。控制读的分摊和落点。
- readConcern（读关注）：读到什么程度一致的数据。控制读的一致性。
三者可以独立组合。比如「写要 majority + 读从节点分担 + 读到已提交数据」就是一种组合。
writeConcern：写关注档位
writeConcern 的核心是 w 参数，控制写入要几个节点确认：
w: 0：不等任何确认，发出就算成功。最快，但可能丢（发出去主就崩了，没记下来）。只适合可丢失的数据：日志、埋点、缓存预热。
w: 1（默认）：等主节点确认（写到了主的内存/journal）。单机不丢（主崩了 journal 能恢复），但复制集下，如果主确认后还没同步到从就崩溃切换，这条写入可能回滚。所以 w: 1 是「单机持久，failover 可能回滚」。
w: "majority"：等多数节点确认写入。这是复制集下最强的不丢保证——多数节点都有这条数据，任何少数派故障都不会丢。代价是延迟：要等多数节点同步确认，通常是 w: 1 的两倍以上。
j: true：强制等 journal 刷盘（而不是只到内存）。配合 w 使用，如 w: 1, j: true 保证单机 journal 已落盘，w: "majority", j: true 是最强档位。journal 刷盘默认每 100ms，j: true 强制立即刷，增加延迟。
档位选择的核心判断是「这条写入能不能容忍丢失」：不能丢（订单、支付）→ w: "majority"；单机不丢即可（大多数业务）→ w: 1；可丢（日志）→ w: 0。
readPreference：读偏好
readPreference 决定读发到哪个节点：
primary（默认）：只读主，强一致（读到主最新写入）。适合一致性敏感的读。
primaryPreferred：优先主，主不可用才读从。兼顾一致性和可用性。
secondary：只读从节点，分担主压力。代价是最终一致（从有延迟，读到旧数据）。
secondaryPreferred：优先读从，从都没有才读主。读密集、对一致性不敏感的场景用。
nearest：读网络延迟最低的节点，不分主从。跨地域部署时用，降低读延迟。
读从节点要配合 maxStalenessSeconds——限制可接受的从节点延迟上限。比如设 90 秒，从节点延迟超过 90 秒就不读它（转读主），避免读到太旧的数据。
readConcern：读关注
readConcern 决定读到什么程度一致的数据：
local（默认）：读本节点最新数据。可能读到尚未提交到多数派的数据（主切换时会回滚），所以可能「读到了后来消失的数据」。
majority：只读已提交到多数派的数据。配合 w: "majority" 写，保证读到的数据不会因 failover 回滚消失。核心交易场景建议 majority 读写配对。
linearizable：强一致线性化读，最强但最慢。保证读到所有已确认的写入，且读操作线性一致。代价是延迟高，只在必要时用。
snapshot：事务里的快照读，看到事务开始时的一致快照。
怎么组合
实际业务的组合通常是几种模式：
核心交易（订单、支付）：w: "majority" 写 + readConcern: "majority" + 读主。最强不丢、最强一致，接受延迟。这是金融级的配置。
一般业务：w: 1 写 + 读主（默认）。单机不丢、强一致读，延迟低。绝大多数业务够用。
读密集、可容忍最终一致：w: 1 写 + readPreference: secondary 读从 + maxStalenessSeconds。分摊主压力，接受从的延迟。
可丢数据（日志、埋点）：w: 0 写。换最大吞吐。
跨地域读：readPreference: nearest，就近读降低延迟，接受跨地域复制延迟。
判断框架
- writeConcern 按「能不能丢」选档：不能丢
w:majority，单机不丢w:1，可丢w:0。 j: true是单机 journal 持久性强保证，绝对不能丢加它。- readPreference 按一致性需求选：强一致读主，分摊读从 + maxStalenessSeconds。
- readConcern 按「读到回滚数据能不能接受」选：不能接受用 majority。
- 核心交易：majority 写 + majority 读 + 读主，最强档。
- 读从 = 最终一致，永远记住这点，别用从节点读做强一致判断。
下一篇讲两地三中心，把高可用部署架构讲透。
关于十三Tech
我是十三，All in AI Agent 方向的架构师，专注 AI 工程实践。
我相信 AI 是程序员的最佳搭档，也希望帮助每一位开发者更好地驾驭 AI。
如果你想继续跟完这套「图解 MongoDB」，欢迎关注公众号 「十三Tech」。后续会按复制集、分片集群和架构选型这条线更新。
