MongoDB分片是否会引发最终一致性？启用分片有何损失？

分片是否会导致最终一致性？ #

MongoDB分片本身不会直接触发最终一致性，一致性模型的核心取决于你配置的写关注（Write Concern）和读关注（Read Concern），和是否启用分片没有必然关联。

默认情况下，MongoDB的写关注为1（仅确认主节点写入成功）、读关注为local（读取当前节点的最新数据），这种配置下无论是否分片，都可能出现读操作未获取到从节点同步完成的数据的情况，表现出最终一致性。但如果将写关注设为majority（等待大多数副本集节点确认写入）、读关注设为majority（读取已被大多数节点确认的数据），即使在分片集群中，也能实现强一致性读——前提是你的分片单元是副本集（这也是分片集群的标准部署方式）。

启用分片后查询是否变为最终一致性？ #

不会，查询的一致性模型依然由读写关注配置决定，和分片无关：

• 若配置majority级别的读写关注，查询能获取到已被集群大多数节点确认的写入数据，属于强一致性范畴；
• 若保持默认配置，无论是否分片，都可能出现最终一致性的表现。

启用分片的主要损失（未引入最终一致性的前提下） #

如果保持强一致性配置，分片带来的主要额外成本包括：

• 架构复杂度飙升：需要管理mongos路由节点、配置服务器集群、分片副本集三类角色，部署、监控、故障排查的难度远高于单副本集；
• 跨分片查询性能损耗：当查询条件不包含分片键时，mongos需要向所有分片广播查询请求，再合并结果，性能远不如单副本集下的定向查询；
• 分片键设计成本：分片键选择失误会导致数据倾斜、热点分片，直接拖垮集群性能，需要结合业务访问模式、数据分布做深度评估；
• 事务能力受限：分片集群中的多文档事务，在4.2版本前要求所有涉及文档处于同一分片；4.2+支持跨分片事务，但会带来显著的性能开销；
• 数据迁移与维护成本：后续扩容、调整分片键需要执行数据迁移，过程会占用集群CPU、带宽资源，可能对业务造成影响。

内容的提问来源于stack exchange，提问作者user7340