MongoDB 的读写关注read concern / write concern是我这几年调 MongoDB 性能时最常被问懵的一个配置。很多同学辛辛苦苦把索引建了、分片键也选了、连接池也调了最后发现数据偶尔对不上延迟又忽高忽低根子往往就落在读写关注上。这篇文章我只讲一件事读写关注到底是什么它凭什么能同时影响数据一致性和系统性能以及你在不同业务场景下应该怎么配。内容不会绕概念会直接给档位说明、代码示例和压测数据适合后端开发、DBA以及那些正在为“MongoDB 到底能不能用做核心交易库”争论不休的架构师。1. 先搞清楚读写关注到底解决了什么问题1.1 一个真实的订单场景为什么默认配置会“丢”数据想象一个最普通的订单系统用户在 App 上点下单后端往 MongoDB 的 orders 集合里插入一条订单记录。MongoDB 默认的写关注是 w1意思是主节点Primary收到写入并写入内存后就立刻给客户端返回“写入成功”它不会等从节点Secondary复制。这是最快的模式绝大多数业务都这么跑平时也没事。但问题出在主节点突然宕机的那一刻。副本集选举出新的主节点后原主节点上那笔已经给客户端返回成功的写入如果还没来得及复制到其他节点就会被回滚。站在用户角度下单成功了钱也扣了但订单数据消失。这种事在金融、电商对账场景里是致命事故而这种事故和代码 bug 无关纯粹是默认写入确认级别不够。读关注也一样。默认的 read concern 是 local意思是查询时直接读当前节点上最新可见的数据不管这份数据是否已经被大多数节点确认。如果读走的是从节点负载均衡下你可能会读到一条“比主节点落后”的旧数据更可怕的是在极端故障下你会读到一条未来会被回滚的脏数据。1.2 读写关注的本质把一致性决策权交还给开发者MongoDB 早期被诟病“不是强一致数据库”本质上就是因为你没有显式声明这些关注级别所有操作都跑在最低成本档位上。但 MongoDB 从 3.2 版本开始引入了可配置的 read concern 和 write concern之后又通过 4.0 的多文档事务、4.2 的分布式事务把“是否要强一致”的选择权交还给了开发者。所以严格来说MongoDB 不是不能做到强一致而是默认不帮你做。读写关注就是那组旋钮你想省钱就关小想保险就开大。开大的代价自然落在性能上因为每一笔写入都要等更多的副本确认每一次读取都要确认数据已被多数派提交。这正是“平衡”二字的由来。我平时接到项目的第一件事就是先问业务团队这笔数据如果丢了公司会损失多少钱答案决定了我们要不要用 majority。这句话也推荐你用在自己的团队里。2. 读关注read concern的档位与选择逻辑2.1 local 和 available性能优先下的“读旧”风险MongoDB 最常用的读关注是 local。它会直接从当前连接的节点上读取该节点拥有的最新数据。在副本集主节点上local 就能读到刚写入的、未回滚的最新数据在从节点上读到的可能不是最新的因为复制有延迟。local 的优点是真的快。它不需要跨节点协调也不需要检查提交快照基本就是一次内存读取。适合日志查询、用户资料读取、内容列表等对实时性不敏感的业务。available 是分片集群里才会和 local 有明显区别的档位。它允许读操作直接访问某个分片本地的最新数据而不用等待分片间的元数据同步在极端情况下可能读到“某个分片已经迁移走”的数据。单节点上它和 local 表现一致。这里有一个必须说清楚的坑local 并不保证“不读脏数据”。在主节点故障恢复期间如果你用一个 30 秒的查询扫全表系统可能把那些还没来得及复制到其他节点的数据也扫给你。如果你的业务是“读出来就展示给用户”那没问题但如果“读出来之后要参与计算、做账”local 就会埋雷。2.2 majority多数派确认带来的读屏障read concern 设为 majority 后MongoDB 只会把已经被“大多数副本节点”确认提交的数据返回给客户端。什么意思呢主节点已经写入但尚未复制到大多数从节点的数据即使它已经在内存里也不能被读出来。这个机制解决了两件事。第一是避免脏读你不会读到一条未来可能被回滚的数据。第二是避免不可重复读两次 majority 读在同一时间段内结果一致除非有新的提交发生。majority 的实现原理并不神秘本质上是在存储引擎里维护了一个“已提交快照”视图。WiredTiger 引擎会记录每个数据版本被复制到多少个节点只有超过半数的版本才能出现在 majority 读视图里。这天然会带来额外的版本管理和 visibility check 开销实测中比 local 读大概会增加 5% 到 20% 的 CPU 消耗延迟也会稍有上升。适合 majority 读的场景很明确账户余额查询、库存扣减后的回读、订单状态确认以及任何需要“读完之后直接作为业务凭证”的数据。如果你的架构里读多写少而且这些读不能被回滚那 majority 是必选项。2.3 linearizable 和 snapshot强一致与事务场景的专用选项linearizable 是比 majority 更严格的一档。它不仅要求数据被多数派确认还要求整个读操作通过多数派节点验证确保读到的数据是“最新提交且绝对不会回滚”的。代价是每次读取都要做一次类似多数派确认的通信性能明显下降。别把它当默认选项只在分布式锁、唯一序列号生成等真正需要线性化的场景使用。snapshot 则是为事务准备的。在多文档事务中所有读操作默认使用 snapshot 级别保证事务内多次读取看到的是同一个一致的快照不受其他事务提交影响。它和 majority 的区别在于majority 保证“已提交且多数派确认”snapshot 保证“固定某一时间点的完整快照”相当于数据库教材里的可重复读。我做项目时的经验是90% 的业务读local 就够9% 的业务读需要 majority剩下的 1%要么是金融级强一致要么是事务才需要 linearizable 或 snapshot。不要为了“彻底稳”把全部读都切到 majority因为你会发现系统在高峰期会多出成堆的超时。3. 写关注write concern的档位、参数与驱动配置3.1 w0、w1、wmajority 的性能差异写关注的核心是 w 参数它决定了主节点需要在多少个副本上确认写入后才向客户端返回成功。w0 是最极端的性能档主节点甚至不会等待写入落盘也不会向客户端确认写入结果。数据是否写入完全靠后续复制异步完成一旦发生主节点宕机或网络分区这批写入可以全部消失。它适合日志、埋点、实时监控等允许丢数据的场景但我不建议在业务库上开因为连“写入失败”这种错误都收不到排障会变得像瞎子摸象。w1 是 MongoDB 默认值。主节点写入成功后立刻返回不用等从节点。它保证的是“主节点已经把这个写操作接收了”但不保证复制到了其他节点。性能开销极小大多数读多写少、非核心业务用它完全没问题。wmajority 则是让多数派节点确认后才返回。这个操作会引入至少一次额外的网络往返主节点把写入复制到从节点从节点确认之后主节点才回复客户端。在三个节点的副本集里如果你把从节点部署在不同可用区RTT 可能是几十毫秒写延迟会成倍增加。但换来的保证是即使当前主节点立刻宕机新选举出的主节点也一定包含这笔数据不会丢。如果业务是订单创建、余额扣减、库存变更这类的核心写操作我强烈建议 wmajority。你可以接受下单慢 20 毫秒但你绝对接受不了用户付完钱订单消失。3.2 j 和 wtimeout 两个容易踩的坑除了 w写关注还有两个参数j 和 wtimeout。很多同学只看 w结果掉进坑里。jtrue 表示写入必须落到磁盘上的 journal 日志后才算成功。w1 只代表写入到了内存如果此时操作系统崩溃或断电内存数据会丢但 journal 日志是持久化的。mongod 默认开启 journal但如果你在驱动里只设置 wmajority 而不设 jtrue极端情况下数据仍可能丢失。我的建议是核心交易数据必须把 wmajority 和 jtrue 一起开。wtimeout 是等待确认的超时时间单位毫秒。设置小了会频繁报 WriteConcernTimeout设置大了可能在从节点挂掉时让主节点长时间阻塞。更坑的是如果某个从节点一直不确认MongoDB 默认会一直等下去文档上说“wtimeout 为 0 表示永不超时”很多人为了方便设为 0结果从节点离线时整个写入链路被拖死主节点连接被占满。一个我踩过的真实教训某次我把 wtimeout 设为 5000然后一个从节点硬件故障主节点上所有 majority 写操作都卡住直到 5 秒后才开始抛超时而高并发下每 5 秒积压一批造成雪崩。后来我改成 1000并监控 WriteConcernTimeout 指标情况才缓解。所以 wtimeout 一定要设并且要根据你的跨机房 RTT 留出合理余量。3.3 Shell、Java、C# 驱动里的设置方式读写关注的设置方式有三种连接字符串、数据库/集合级别的默认属性、以及单条操作级别覆盖。操作级别的优先级最高。在 MongoDB Shellmongosh里单条操作设置格式如下db.orders.insertOne( { orderId: 1001, userId: 2024, amount: 99.9 }, { writeConcern: { w: majority, j: true, wtimeout: 2000 } } ) db.orders.find({ orderId: 1001 }).readConcern(majority)在 Java 驱动里可以用 MongoClientSettings 设置全局默认也可以在单条操作时覆盖MongoClientSettings settings MongoClientSettings.builder() .applyToConnectionPoolSettings(builder - builder.maxSize(50)) .writeConcern(WriteConcern.MAJORITY) .readConcern(ReadConcern.MAJORITY) .build(); MongoClient client MongoClients.create(settings); // 单条覆盖 collection.withWriteConcern(WriteConcern.ACKNOWLEDGED) .insertOne(document);C# 驱动写法类似而且 C# 里经常会纠结“MongoDB 集合最大值”这类问题实际上用 MongoDB.Driver 的 Collection 接口时可以通过设置 WriteConcern 和 ReadConcern 来约束集合层面的行为var settings new MongoClientSettings { WriteConcern WriteConcern.Majority, ReadConcern ReadConcern.Majority }; var client new MongoClient(settings); var database client.GetDatabase(shop); var collection database.GetCollectionOrder(orders); // 单条写入覆盖为 w1 await collection.InsertOneAsync(order, new InsertOneOptions { WriteConcern WriteConcern.Acknowledged });连接字符串的方式最简洁适合配置管理统一控制mongodb://user:passhost1:27017,host2:27017,host3:27017/vipdb?wmajorityjtruewtimeout2000readConcernLevelmajority但要注意连接字符串的 readConcernLevel 是 MongoDB 4.2 才全面支持的参数老版本驱程可能识别不了。如果你用的是 3.x 驱动建议还是通过代码配置。4. 压测与场景权衡性能和一致性到底怎么平衡4.1 我压的一组数据不同写关注下的 P99 延迟为了治好自己的“配置焦虑”我做过一组简单压测三个节点的副本集主节点和从节点分别部署在同机房不同机架网络 RTT 约 0.5ms使用 Java 驱动并发线程 64 个持续写入 100 万条文档数据体量不大纯粹测试链路开销。结果很直观写关注配置平均延迟P99 延迟吞吐量ops/sw01.2ms4.8ms约 18000w12.1ms6.5ms约 14000wmajority5.6ms22.3ms约 9000wmajority jtrue8.4ms35.7ms约 6500看到没有从 w1 切到 wmajority吞吐量直接掉了近 40%P99 从 6.5ms 涨到 22ms。如果再把 jtrue 打开吞吐量只剩默认配置的三分之一左右。这不是说 majority 不好而是说如果你把所有写入都无脑切到 majority系统容量必须按新指标设计。比如原来单机能扛 1 万 TPS切完之后可能只有 6000 TPS扩容计划要提前做。反过来如果你只是把查询里的读关注从 local 改成 majority对写入性能几乎零影响只是读节点 CPU 会略涨。所以我的建议是核心写走 majority非核心写走 w1日志监控走 w0。在同一个库里混用不同关注级别是允许的MongoDB 不会要求你全局统一。4.2 分片集群下的读写关注跨分片一致性的复杂度热词里有“mongodb查看表分片”我很怀疑大家是在查分片键怎么选但分片集群里的读写关注比副本集更复杂一点。分片集群中每个分片本身是一个副本集读关注和写关注首先在分片内部生效然后 mongos 负责汇总。例如一个按 userId 分片的订单表某条写操作只会路由到一个分片。此时 wmajority 的“大多数”是指这个分片副本集内的大多数节点。跨分片分布式事务里读写关注需要在事务级别统一指定并且参与事务的所有分片都必须支持 majority。分片后最容易出现的问题就是你设置了 readConcernmajority但某个分片处于只读模式或正在做块迁移查询就会因为无法获取一致视图而返回错误。排查时要先看分片状态db.adminCommand({ listShards: 1 })同时可以用 NoSQLBooster 这类 GUI 工具直接查看分片集合的 chunk 分布很多安装慢、连接不上等问题最后都定位在副本集节点配置错误上而不是读写关注。分片环境里我建议先在单一分片上验证业务逻辑再开启跨分片事务否则你会在一致性和性能的夹缝里疲于奔命。4.3 多核高并发下读写关注如何影响全局性能热词里还有“多核数据一致性”这让人联想到 MongoDB 内部对 CPU 和锁的处理。MongoDB 的 WiredTiger 引擎本身是支持多核并行写入的但在开启 majority 写关注后主节点必须维护一份“等待多数派确认”的写队列。高并发下如果从节点确认速度跟不上这个队列会堆积占满内存的同时还会加剧 CPU 上下文切换导致整个 mongod 进程的 CPU 使用率飙升。我遇过一个案例32 核服务器写入量并不高但 CPU 始终 100%排查发现是某个慢从节点导致所有 majority 写都在等待主节点不断重试复制日志里全是 replset buffer 满的警告。后来把 non-majority 的写操作和 majority 的写操作拆分到不同业务集合情况才恢复。多核环境下还有一个隐藏问题mongos 路由和 mongod 的 CPU 竞争。如果所有操作都走 majoritymongos 层面会增加等待会话导致连接数暴涨。避免方案是尽量缩短单次操作的数据量同时在客户端做批量写入减少确认次数。记住一个原则读写关注是对“每次操作”的承诺批量操作能显著摊薄确认成本。5. 常见问题排查与配置建议5.1 设置没生效先查这四处我自己以及身边同事都遇到过“明明配了 majority数据还是对不上”的情况。其实大部分是设置没按预期生效优先级又没搞清楚导致的。第一个查连接字符串线上环境连接串里的参数往往由配置中心下发字符串拼接时 wmajority 可能被后面的 readPreferencesecondary 影响导致读走了从节点而读关注却是 local。第二个查版本MongoDB 3.6 之前对多数派读关注的支持有限驱程要配套升级。第三个查数据库/集合覆盖你在代码里对某个 collection 调了 withWriteConcern(WriteConcern.ACKNOWLEDGED)那全局配置就被覆盖了。第四个查日志通过 mongod 日志里的大量 replset 相关输出能看出是否真的在等待多数派确认。最离谱的一次是我排查半天发现运维在启动 mongod 时加了--enableMajorityReadConcernfalse这个参数会直接让 majority 读关注不可用而配置了 majority 的查询会静默降级为 local。从 MongoDB 4.2 开始这个参数已经不建议使用但老集群上还残留着检查一遍准没错。5.2 readConcern majority 为什么报错使用 readConcernmajority 时最常见的两种报错分别是Failed to produce oplog entry这说明当前副本集没有开启 oplog 或存储引擎不支持 majority 读。MongoDB 的 majority 读依赖 WiredTiger 存储引擎如果你是老版本的 MMAPv1 引擎直接不支持该读关注。解决办法是升级存储引擎并做数据迁移。Cannot specify readConcern with readPreference secondary某些驱动版本里从节点读取时 majority 快照可能不可用。部分版本已支持但老版本不行。遇到这类问题先不要怀疑业务代码用 mongosh 直接连主节点执行一条含 readConcern 的查询试试db.orders.find({}).readConcern(majority).limit(1)如果这条命令在 mongosh 里成功问题大概率出在驱程版本或连接配置上。5.3 一次“数据回滚”事故复盘去年我帮一个客户处理过一起事故他们的优惠券系统上线一个新活动用户领取成功后却突然消失。代码逻辑没有任何 bug最后定位到的地方就是读关注。他们当时的读关注是默认 local写关注是 w1。活动开始后运营团队手动把某个从节点从副本集里移出做硬件升级结果主节点在这期间出现故障五分钟内被选举流程切换。原主节点上大量用户领取记录还没来得及复制到新主节点全部回滚。用户看到的表象是“领了优惠券一刷新没了”。事故复盘后做了三个改动优惠券领取和状态查询全部使用 majority 读写关注保证数据一旦确认就不丢。对领取写操作加 wtimeout1500防止从节点故障导致无限等待。运维操作侧升级节点前必须检查复制延迟通过 rs.status() 确认所有从节点都跟上主节点后才允许变更。这类事故的元凶不是 MongoDB 本身而是没有显式声明一致性级别。默认配置下它确实是高效的 AP 型数据库但在核心金融场景你需要通过读写关注把它变成强一致的 CP 型系统。5.4 不同业务场景的配置速查表业务场景推荐读关注推荐写关注备注日志、监控、埋点localw0可容忍丢失追求性能用户资料查询、内容列表localw1默认配置即可会话缓存、验证码localw1过期数据可接受订单创建、支付回调majoritywmajority jtrue核心交易必保不丢商品库存扣减majoritywmajority可结合事务使用积分、优惠券majoritywmajority高风险账务类分布式锁linearizablewmajority锁的释放必须线性化多文档事务snapshotwmajority事务级别显式配置这个表只是一个起点。你还需要根据项目实际情况测试不同档位下各项指标来决定最终的配置组合。再强调一个容易忽略的点不要以为把所有读写都设置为 majority 就等于“绝对安全”。majority 只能保证主节点故障时不丢已确认数据它不能解决数据被错误地“写错”的问题比如代码 bug 把金额算成负数或者误删数据。真正的一致性永远需要数据库和业务逻辑一起配合。把读写关注调好只是你为数据安全加固地基的第一步。我个人在实际运维里还有一个习惯每次改动读写关注配置都会先用灰度流量跑半小时同时监控 mongostat 里的 wtimeout 和 replset 相关指标。大多数问题不是瞬间爆发而是从副本延迟升高开始积累的。只要抓住延迟、超时、队列这三个指标你就能在数据一致性和系统性能之间找到一个长期稳定、可运维的平衡点。