企业官网建设流程全解析

1. 一次主节点宕机，让"已成功的写入"原地消失

先讲一个我自己压测时遇到的场景。

某次给一套基于 MongoDB 的订单系统做故障演练，我用db.adminCommand({replSetStepDown: 60, force: true})强制把主节点降级，模拟网络抖动引发的主从切换。切换完成后，例行对账，发现一个诡异现象：业务日志里明明有一批订单返回了"写入成功"，可这几十条订单在从节点、新主节点上都查不到，彻底消失了。

一开始我怀疑是代码的异常处理有问题，后来翻复制集的 oplog，才发现这批写入在主节点上确实执行了，但还没来得及复制到从节点，主节点就被强制降级。按照 MongoDB 默认的写关注，主节点收到写入并写入内存后就会给客户端返回 ack，哪怕复制尚未发生。客户端以为成功了，实际上这些数据在故障瞬间可以随时被回滚丢弃。

这不是一个"极端到没人会踩"的场景。事实上，只要副本集存在，主节点宕机、网络分区、心跳超时就会导致主节点切换，而切换只需要一次投票，毫秒级。如果你从没主动设置过读写关注，可能一直在依赖 MongoDB 的默认配置，而这个默认配置在一致性上属于"尽力而为"。

1.1 复制集日志里藏着的默认行为

MongoDB 的复制机制核心是 oplog。主节点上的每次写操作，都会生成一条 oplog 记录，从节点通过同步这条记录来追数据。这里的关键点在于：主节点写 oplog 和应用写入是同一个事务里的动作，但从节点什么时候拉取、拉到哪一条，主节点完全不管。

默认的 write concern 是{ w: 1 }，意思是主节点自己写完就确认；默认的 read concern 是{ level: local }，意思是任意节点直接返回它本地当前能看到的数据。这两个默认值拼在一起，最直接的后果是：

• 写操作不需要等任何从节点确认，所以你无法确认这笔数据是否已经进入"多数派"的视角。
• 读操作只读当前节点的本地状态，不管这个状态是不是可能被回滚。

在单机或纯开发环境下，这样做没有任何问题，快得很。但一旦进入副本集，主节点故障切换就成了一种常态，而不是异常。故障切换的本质是：一个新的主节点从多数派节点中选举产生，如果旧主节点上有一部分写入还没同步到多数派节点，这部分写入会被新主节点丢弃。客户端已经收到的"成功"通知，就这样变成了一次幻觉。

1.2 读写关注到底解决的是哪两个问题

用一句话拆解：

• 写关注 (write concern) 解决的是"写操作返回成功时，数据到底有多少份保障"。
• 读关注 (read concern) 解决的是"一次读操作，可能读到哪个版本的提交数据"。

两者相互独立，实际业务中又必须配套使用。如果你只设置强写关注、把数据安全地复制到了多数派节点，但读的时候仍然用默认的local级别，并且把读请求打到从节点上，读到的数据可能已经过期；反过来，如果只设置强读关注，但写操作没有持久化到多数派，那么你根本读不到"稳定"的数据版本，因为尚未提交的数据随时会被回滚。

所以，这两种设置本质上是在回答两个问题："我写入的数据有多少副本实时在线？" 和 "我读到的数据是不是已经被多数派认可？" 下面两章分别展开讲。

2. write concern：你的写操作要等几份确认才算成功

先看 write concern 的庐山真面目。它由三个参数组成：

用 MongoDB shell 发一条带 write concern 的更新，大概是这样的：

db.orders.updateOne( { _id: 1001 }, { $set: { status: "PAID" } }, { writeConcern: { w: "majority", j: true, wtimeout: 3000 } } );

这段代码的意思是：这条更新必须被多数派节点确认，并且确认节点必须已经把这条写入落盘到 journal，整个等待时间不超过 3 秒。超过 3 秒仍然没凑够多数派确认，命令会抛出一个写关注超时错误。

2.1 w、j、wtimeout 的等待逻辑

要理解这个等待逻辑，关键是搞清楚主节点做了什么。

当主节点收到带 writeConcern 的写请求后，会先执行写入并写自己的 oplog。然后它开始向从节点"征求确认"。具体流程是：

1. 主节点把写入包装成一条 oplog entry，本地提交。
2. 从节点拉取到这条 oplog entry，应用到自己的数据集，并记录自己的同步位置。
3. 每个从节点通过心跳消息，把自己的同步进度告诉主节点。
4. 主节点统计当前已经同步到这条写入的节点数，如果达到w要求，就给客户端返回确认。

如果你设置了j: true，节点还必须把写入刷入磁盘上的 journal 文件，才算有效确认。这一步的作用是防止"确认之后，节点断电导致内存里的数据丢失"。注意，j: true会让每次写操作多一次磁盘刷写，对吞吐影响很大，在 SSD 上大概会增加 1 到 3 毫秒，但在机械盘或 IO 压力高的环境里可能增加几十毫秒。

wtimeout是容易让人误解的参数。很多人以为超时之后写入就会被回滚，其实不会。write concern 超时只代表客户端无法确认写入是否被多数派接收，写入本身在主节点上已经生效了，而且会继续等待复制，只是不再等待外部 ack。如果你在应用里捕获到超时异常后直接重试，就可能导致同一条更新被重复执行，所以必须根据业务幂等性设计补偿逻辑。

2.2 w=1、w=majority 与标签集合，性能差异有多大

从 w 的取值就能看出这是一套可以弹性调节的一致性刻度：

• w: 0：主节点不确认，客户端"发射后不管"。性能最好，但写入失败也完全感知不到，只能用于日志、埋点、监控打点这类允许丢一点数据的场景。
• w: 1：默认值。只要主节点本地写完，就返回成功。如果主节点发生故障且写入尚未复制，数据就丢了。
• w: 2、w: 3：等待指定数量的节点确认。适合三节点副本集，至少等待一个从节点确认，兼顾一点安全性。
• w: "majority"：等待大多数投票节点确认。在三节点副本集中是 2 个节点确认，在五节点中是 3 个。
• w: "dcMajority"这类标签集合：可以要求某个机房的多数派节点确认，主要用于跨中心部署时保证数据落在远端机房。

性能差异的核心在于网络往返。w: 1的写操作只需要主节点本地一次操作。w: "majority"则需要主节点等待至少一个从节点复制并回报进度，这至少多了一次内部网络 RTT。如果从节点在同一个机房，延迟可能只有 0.5 到 2 毫秒；如果跨机房，延迟会直接变成 30 到 80 毫秒，写操作的吞吐会肉眼可见地下降。

从运维角度，我一般建议：

• 三节点副本集，关键业务用w: "majority"，因为副本集天然就是围绕多数派设计的。
• 想要更多冗余但不想承担跨机房延迟，可以把额外从节点设为 hidden 或 priority 0，这样它们不参与投票，majority的确认数仍然是两个节点。
• w: 0只用在明确的"可丢数据"场景，不要因为性能压力头脑一热全局降级。

3. read concern：你读到的数据是不是"大多数人认可"的版本

read concern 比 write concern 更绕，因为它和"什么算已提交"这个概念绑得很紧。

在 MongoDB 中，一条数据只有在被多数派节点复制后，才能被称为"已提交"（committed）。这个"已提交"状态由副本集的复制进度决定。read concern 的每一个级别，本质上是让你选择从哪个快照版本里读数据。

各级别对照如下：

3.1 local 与 majority：一次查询的可见性分水岭

绝大部分应用都在这两个级别之间做选择。

readConcern: local是默认值。它不关心数据是否已经被多数派确认，直接返回当前节点本地可见的数据。在主节点上执行 local 读，能读到所有"刚写入、还没复制"的数据；在从节点上执行 local 读，能读到从节点当前同步到的数据，但可能比主节点落后。

readConcern: majority则要求 MongoDB 只返回已经被多数派节点确认过的数据。实现机制上，每个节点会维护一个"提交快照点"（majority commit point），只有 oplog 中位于这个快照点之前的数据，在 majority 读中被暴露。所以从节点上读 majority，不会读到那些"主节点有了、但从节点还没拉到"或"拉了但未追平多数派提交点"的数据。

举个例子：用户支付成功后跳转到订单详情页，详情页直接查订单状态。如果写操作用的是w: majority、读操作用的是local，而且读请求被路由到了从节点，那么存在一个时间窗口：用户看到订单还是"待支付"，尽管支付已经成功。这是因为写已经提交，但从节点还没追平。解决方法是把读也设成majority，或者让这个查询强制走主节点。

local和majority的性能差异在于：local完全没有额外等待，读到什么就是什么；majority需要检查数据的提交状态，在大多数情况下只是多做一次内存内的状态判断，不会等从节点，所以延迟差异通常不到 1 毫秒。真正贵的是linearizable，它需要跟主节点做一次额外的往返确认。

3.2 linearizable 与 snapshot：少数场景里的强一致读

linearizable是一个被低估但非常有用的级别。它的目标是：如果某个写操作在读取发起之前已经被客户端确认成功，那么这次读必须能看到这个写入的结果。哪怕读请求被路由到了复制滞后的从节点，MongoDB 也会让这个读请求跟随主节点确认当前最新的提交时间戳，再返回数据。

这个级别的代价是：每个读操作至少增加一次主节点往返，而且只能对单个文档使用，无法在多文档查询中使用。适合账户余额查询、验证码比对这类"绝对不允许读到旧值"的场景。

snapshot级别则需要和事务绑定。在事务里使用readConcern: snapshot可以保证整个事务基于同一个时间点的快照，不会因为其他并发写入导致幻读、不可重复读。MongoDB 4.0 引入多文档事务后，这个级别就成了复杂业务逻辑的标配。

4. 黄金平衡法则：按业务分级，给每个请求定制关注等级

讲了原理，接下来就是落地。我的判断依据很朴素：把数据分成"丢不起的"和"丢得起的"，把读操作分成"不能读旧的"和"读旧一点没关系"的，然后分别搭配。

4.1 强一致优先的场景组合

先说金融支付、账户余额、点券扣减这一类业务。

写操作必须用w: "majority"，部分账务类操作还要加上j: true。因为这类场景里，一旦发生"客户端显示成功但实际数据丢失"，后续对账成本和用户信任损失是不可接受的。

读操作分成两种情况：

• 用户钱包余额、支付状态查询：使用readConcern: "linearizable"，或者干脆用一个单独的readPreference: "primary"连接，强制从主节点读最新数据。这两者在一致性语义上接近，但linearizable的开销略高，适合那种"每次读都必须要最新"的接口。
• 后台对账、报表统计：用readConcern: "majority"就够了，读稍微旧一点没关系，但必须保证读到的数据是稳定的，不能被回滚。

如果业务涉及多文档更新，比如订单状态和库存数量必须同时变更，就一定要放进事务里，并使用readConcern: "snapshot"、writeConcern: "majority"的组合。否则两个文档各自满足了单条一致性，却无法保证跨文档的原子性。

4.2 吞吐优先的场景组合

再说日志、埋点、推荐流、访问计数这类海量写入场景。

写入量很大，每条数据的重要程度又很低。用w: "majority"会直接让写入吞吐掉一个量级，完全没必要。我的建议是：

• 日志、监控指标、埋点数据：w: 0，甚至可以在客户端直接关闭写确认。配合continueOnError批量写入，能非常高效地把数据灌进 MongoDB。
• 用户会话、购物车等可以容忍偶尔丢失的中间态数据：w: 1。
• 读操作统一用readConcern: "local"，让应用服务器上的 MongoDB 驱动自动选择合适的节点读取，保证最低延迟。

这里也有一个中间态：既想保留一定数据安全，又不想承担majority的额外 RTT。可以试试w: 2或w: 3。三节点副本集下，w: 2意味着主节点和一个从节点都确认了，故障切换时丢数据的概率大幅降低，但性能只损失一次内部 RTT，比majority快。缺点是一旦某个从节点临时不可用，写操作就需要等到wtimeout后才报错，所以必须设置合理的wtimeout，否则写延迟会突然飙升。

4.3 连接串、操作与集合的三个设置层级

读写关注可以在三个层级配置，优先级从低到高是：连接串级别、集合/会话级别、单条操作级别。

连接串级别适合设置全局默认值，一般写在 MongoClient 的配置里。比如 Java 驱动：

MongoClientSettings settings = MongoClientSettings.builder() .readConcern(ReadConcern.MAJORITY) .writeConcern(WriteConcern.MAJORITY) .build();

Python 驱动：

client = pymongo.MongoClient( "mongodb://localhost:27017/?readConcernLevel=majority&w=majority" )

但全局设置一定需要谨慎。一个应用里可能有几十种业务，有的需要强一致，有的只需要高吞吐。全部设成majority，日志写入也会被拖慢；全部设成local，支付接口又会冒险。

我的实践是：全局用比较保守的中间值，比如w: "majority"、readConcern: "majority"，然后在个别性能敏感的集合或操作上，用单条操作级别覆盖降级。单条操作级别使用很简单，依然以 Python 为例：

collection.with_options( write_concern=WriteConcern(w=1), read_concern=ReadConcern("local") ).insert_one(doc)

或者使用 MongoDB shell 直接执行：

db.runCommand({ find: "orders", filter: { _id: 1001 }, readConcern: { level: "local" } });

单条操作级别的覆盖，让同一套连接可以同时服务强一致和高吞吐两种完全不同的需求。

5. 落地中最常见的坑和判断依据

读写关注看着简单，实际落地时坑非常多。我踩过的、以及帮客户排查过的问题，可以汇总成几个高频雷区。

5.1 wtimeout、默认值、分片集群带来的噪音

第一个坑：wtimeout设置不合理。

很多人在生产环境把wtimeout设成 1000 毫秒甚至更短。平时一切正常，一旦某个从节点发生短暂卡顿或者网络抖动，主节点无法在 1 秒内凑够 majority 确认，写请求立刻超时。但注意，这条写入其实已经被主节点应用了，只是确认消息没传回来。应用收到超时异常后，如果是直接抛错给用户，用户会看到"系统繁忙，请稍后再试"，但实际数据可能已经写入成功，用户重试时就会创建重复订单。

所以wtimeout建议至少设置为 3000 到 5000 毫秒，或者把它当成"熔断信号"而非"业务失败信号"。真正要紧的是监控wtimeout的发生频率，如果频繁出现，说明副本集的复制能力或者网络已经出问题了。

第二个坑：MongoDB 4.4 之后的默认值变化。

从 MongoDB 4.4 开始，副本集的默认 write concern 从w: 1改成了w: "majority"。很多从旧版本升级上来的应用，可能突然发现写入变慢了，但并不知道是默认值变了。如果你的业务确实对写延迟敏感，应该在连接串上明确指定w: 1，而不是"被动接受默认值"。

第三个坑：分片集群里 majority 的语义更复杂。

在分片集群中，w: "majority"意味着所有分片上的相关副本都必须完成确认，因为一个分布式事务可能跨多个分片。跨分片写入的确认延迟是所有分片延迟的最大值，任何一个分片的从节点卡顿，都会拖慢整个事务。所以在分片集群里，不要把全局 writeConcern 设成 majority 然后指责 MongoDB 性能差，要根据分片拓扑和业务容忍度重新评估。

第五个坑，也是最隐蔽的：readConcern和readPreference的组合。

很多人以为设置了readConcern: "majority"就万事大吉，但读请求仍然可能被路由到复制滞后的从节点，然后报错（因为从节点同步位置落后于 majority commit point，它无法提供 majority 级别的数据）。实际上，MongoDB 会转发或重试这类读请求到主节点，但会有额外延迟。如果业务要求低延迟的强一致读，最好的办法是直接用readPreference: "primary"，让请求留在主节点，而不是在从节点上兜圈子。

5.2 用监控指标判断你的读写关注是否合理

最后分享几个我日常运维时重点盯的指标，可以判断读写关注设置是否合理。

• mongostat里的wtime和wt字段：如果看到wtime非零的频率增加，说明很多写操作在等待确认超时。这是"w 设置太高"或"从节点复制延迟"的直接信号。
• db.serverStatus().metrics.repl.apply和db.serverStatus().metrics.repl.buffer的字节数：如果复制积压量大，从节点追不上主节点，那么即使wtimeout没触发，majority 写也会变得慢吞吞。
• rs.status()里每个从节点的secondsBehind、lastHeartbeat时间戳：这个用来判断从节点健康度。如果某个从节点经常滞后超过 1 秒，它可能拖累所有 majority 写操作。
• 应用侧的写延迟分位数 (p99)：如果从w:1切到w:majority后 p99 延迟翻了数倍，说明从节点复制 RTT 很高，这时候需要考虑改用标签集合，让确认只发生在同机房的节点上。

我自己的习惯是给不同的读写关注组合起名字、做标签，然后在监控里按标签聚合延迟。慢慢地就能看出哪种业务适合哪种配置，而不是凭感觉拍脑袋。比如给"支付写入超高可靠"打上wc: major, rc: linearizable的标签，给"订单列表"打上rc: majority的标签，监控面板上一眼就能看到两类接口的延迟差异。

这些指标不需要每天都盯，但在做容量规划、故障复盘、写入性能调优之前，先看一眼复制相关的指标，往往能省掉很多无谓的"优化"动作。读写关注的本质不是单纯调一个参数，而是你对自己系统里每一份数据"命值多少钱"的认知。想清楚这一点，再回到配置文件里，你会发现自己已经知道该在哪一行写什么了。