Read Concern Majority 不能等同于强一致性，它仅保证读取已提交至多数节点的数据，但存在写入窗口期导致可能读到旧值；其作用范围限于单个分片内部，跨分片仍为最终一致。
Read Concern Majority 能否真正保证强一致性？
不能直接等同于强一致性，它只保证读取到已提交到大多数节点的数据，但不解决写入过程中的窗口期问题。比如写入刚被多数节点确认、但尚未完成所有节点同步时，另一个读请求若恰好落在尚未同步的节点上，仍可能读到旧值——除非你同时启用 readConcern: "majority" 且该节点当前能提供 majority 级别视图。
关键前提是：副本集必须有足够多的健康节点（如 3 节点集群至少 2 个在线），且写操作使用 writeConcern: {w: "majority"}；否则 readConcern: "majority" 会降级为本地读或报错 ReadConcernMajorityNotAvailableYet。
分片集群下 Read Concern Majority 的实际生效范围
它只在单个分片（shard）内部生效，不跨分片保证全局一致性。MongoDB 分片集群中，每个分片是一个独立的副本集，readConcern: "majority" 控制的是从该分片的主节点或满足 majority 条件的从节点读取，但不同分片之间的操作仍是最终一致的。
这意味着：
- 事务内跨分片读写才可能触发分布式事务协调器（通过
mongos），此时readConcern: "majority"才在事务上下文中统一约束各分片 - 普通非事务查询即使设了 majority，也无法避免 t1 时刻读 shard A 的新数据、t2 时刻读 shard B 的旧数据
- 如果你依赖跨分片的实时一致性，必须用 multi-document transaction（且所有操作落在同一分片，或开启
allowDiskUse: true并接受性能损耗）
常见错误配置导致 Read Concern Majority 失效
最典型的是未正确设置写关注，或者忽略了 WiredTiger 的 snapshot 机制限制。
以下情况会让 readConcern: "majority" 形同虚设：
- 写操作用了
writeConcern: {w: 1}（仅写入主节点），那么 majority 读永远只能看到这个“单点确认”的版本，毫无意义 - 副本集节点数为偶数（如 4 节点），又没配置
priority: 0或votes: 0的仲裁节点，可能导致无法形成 majority 投票，进而使 majority 读返回错误或回退 - 开启了
readConcern: "majority"，但集合未启用journal: true（默认开启），WiredTiger 可能因日志未刷盘而无法提供稳定 majority 视图 - 使用
find().readConcern({level: "majority"})但驱动版本过低（如 Node.js driver
替代方案与现实权衡
如果业务真需要跨分片强一致，readConcern: "majority" 不是解药，得换思路：
- 把关联数据设计为共属同一分片键（如
{userId: 1}），让相关读写落在一个分片内，再配合事务和 majority 读 - 接受最终一致，用变更流（
change stream）监听更新并异步修复不一致状态 - 在应用层加缓存+版本号（如
_v字段），读取时校验版本，失败则重试或降级
多数真实场景里，“多数节点已确认”已是可用性与一致性之间最务实的平衡点，但务必清楚它的边界在哪——它管不了分片间时序，也压不住网络分区下的脑裂风险。
