readConcern可选值有local、majority、linearizable和available；local读取节点本地最新数据但可能回滚，majority读取多数节点确认的持久化数据，linearizable确保读取操作开始前所有多数写入完成且不可逆，available为降级兜底读取可用数据但可能返回孤立文档。
readConcern 有哪些可选值，各自代表什么语义
readConcern 控制读操作返回的数据“有多新、多可靠”。MongoDB 副本集支持的常见级别有：local、majority、linearizable 和 available（仅限 4.4+）。它们不是性能排序，而是语义强弱排序：
-
local：只保证读到该节点内存/磁盘上已有的最新数据，不关心是否被其他节点确认。延迟最低，但可能读到之后回滚的数据 -
majority：只返回已被大多数副本集成员（含 primary）持久化写入的数据。能规避回滚风险，是多数强一致性场景的底线选择 -
linearizable：在majority基础上加锁 + 强制主节点最新 oplog 时间戳检查，确保“绝对最新且不可逆”。但会显著增加延迟，且要求客户端带 causal consistency session -
available：类似local，但在某些故障场景（如 primary 不可用时 secondary 提升中）允许读取未同步的旧快照 —— 很少主动用，多用于降级兜底
什么时候必须用 majority，什么时候可以退回到 local
业务是否容忍“刚写完就读不到”或“读到后来被回滚的数据”，是关键分水岭：
- 必须用
majority：金融类事务查询（如查余额）、状态机驱动流程（如订单状态变更后立即查）、任何依赖“写后必读到”的链路 - 可以接受
local：用户 feed 流、日志归档查询、报表后台聚合、搜索索引同步等对实时性不敏感、允许短暂 stale 的场景 - 特别注意：即使设置了
majority，如果副本集只有 2 个节点（1 primary + 1 secondary），w: "majority"实际等价于w: 2，一旦 secondary 宕机，所有majority读会阻塞或失败 —— 这不是配置错了，是拓扑本身不支撑该语义
URI 里配 readConcernLevel 和代码里显式指定，哪个优先级更高
优先级顺序固定为：操作级 > 集合级 > 数据库级 > 客户端级 > 连接 URI。这意味着：
- 连接字符串里写
?readConcernLevel=majority，只是客户端默认值，会被后续collection.find().readConcern("local")覆盖 - Node.js 驱动中，
db.collection("x").find({}).readConcern("local")有效；但 Java/C# 驱动需通过FindIterable.readConcern()或构造ReadConcern对象传入 - 事务内
readConcern必须在startTransaction()时声明，不能在事务执行中途动态改 —— 否则抛MongoClientException
readConcern=linearizable 的真实代价和限制
它不是“更强的 majority”，而是一套独立机制，代价明显：
- 每次读都触发一次 primary 的 oplog 时间戳比对 + 全局读锁等待，P95 延迟可能翻倍甚至更高
- 要求客户端开启 causal consistency session（即调用
startSession({causalConsistency: true})），否则直接报错InvalidOptionsError: linearizable read concern requires causal consistency session - 不支持
snapshot读或聚合管道中的$lookup跨库引用 —— 这些会在解析阶段被拒绝 - 真正需要它的场景极少：比如银行核心系统中“客户转账后立刻要求柜员打印凭证”，且凭证内容必须与最终落库结果 100% 一致
readConcern 不是越“高”越好，它本质是用延迟换确定性。很多团队踩坑在于把 majority 当成银弹，却忽略了自己副本集节点数、网络 RTT、以及业务是否真需要那一秒内的强一致 —— 这些比参数本身更决定效果。
