副本集与一致性

5.1oplog：幂等操作日志

oplog 是 primary 上一个 capped 集合（local.oplog.rs），记录幂等的操作条目，secondary 主动拉取重放。

底层机制（深一层）：oplog 条目被设计成幂等——$inc 被转写成绝对值 $set，一条改多文档的操作被拆成逐文档条目——所以重复重放同一批不会出错。secondary 用一个 OplogFetcher exhaust cursor 按 optime tail primary，主动 PULL，primary 从不 push。oplog window（大小 ÷ 写入速率）决定 secondary 最多能落后多久；落后超窗口就要 full resync。对照 Postgres：既不是物理 WAL ship，也不是逻辑解码，而是一个可查询的、幂等的操作日志，由状态机重放。

下面是同一条写入操作在 primary 执行后落进 oplog 的样子。注意 o 字段里已经是绝对值。

// 应用层发的是相对操作
db.counters.updateOne({ _id: "page" }, { $inc: { hits: 1 } })

// primary 执行后，落进 oplog 的条目（节选）——已转写为绝对值
db.getSiblingDB("local").oplog.rs.find().sort({ $natural: -1 }).limit(1)
// {
//   op: "u",                       // update
//   ns: "app.counters",
//   ts: Timestamp(1717300000, 1),  // optime：secondary 按它 tail
//   o:  { $v: 2, diff: { u: { hits: 42 } } },  // 绝对值 42，非 +1
//   o2: { _id: "page" }            // 定位目标文档
// }

5.2选举与协议：像 Raft，但不是 Raft

副本集用 protocolVersion 1，借了 Raft 的 term 与单 leader 思想，但在复制方式、提交点计算、选举细节上都不同。

底层机制（深一层）：与 Raft 的差异要明确列出——(1) 日志条目是幂等操作，不是状态机命令；(2) 复制是 secondary pull，不是 Raft 的 AppendEntries push；(3) commit point 由 primary 轮询多数节点的 lastDurable/lastWritten 算出，而不是逐条计票；(4) 增加了 priority takeover（高优先级节点上线后抢主）和 dry-run election（选赢之前不 bump term，避免无谓的 term 膨胀）。心跳每 2s，10s 超时触发选举。rollback 用 WiredTiger 的 recover-to-stable-timestamp 回到公共点，而不是截断日志。

dry-run election 是一个容易被忽略的细节：候选人在真正发起选举、bump term 之前，先问一轮"若此刻发起选举，能否拿到多数票"。

// 选举触发与 dry-run 的次序（伪代码，描述协议行为）
onHeartbeatTimeout() {                 // 10s 收不到 primary 心跳
  if (dryRunElection().wonMajority()) {  // 1) 试选：不 bump term
    bumpTerm();                          // 2) 真选才 +1，避免 term 膨胀
    requestVotes(currentTerm);           // 3) 正式拉票
  }
  // 试选失败：term 保持原值，集群不被一次无谓选举打扰
}

// priority takeover：高优先级节点追平 oplog 后主动抢主
if (this.priority > primary.priority && this.isCaughtUp()) {
  callElection();                        // 把主导权交还给更高优先级节点
}

5.3write concern / read concern

writeConcern 决定一次写要多少节点确认才返回，readConcern 决定一次读看到哪个一致性级别的数据。

底层机制（深一层）：w:majority 在多数节点 durable 后才返回；primary 跟踪 lastCommittedOpTime（majority commit point）。readConcern 的层级：local（不保证已提交，存在回滚风险）/ majority（读 majority commit point 的 WiredTiger 快照，不会被回滚）/ snapshot（钉住一个集群级多数提交时间戳，事务用）/ linearizable（额外发一个 no-op majority 写来确认自己仍是 primary，给实时线性读）。read preference：primary/secondary/nearest——从 secondary 读会读到滞后数据。

// 写：等多数节点 durable 才返回（不丢、不被回滚）
db.accounts.updateOne(
  { _id: 7 },
  { $set: { balance: 100 } },
  { writeConcern: { w: "majority" } }
)

// 读：只看已被多数提交的快照，读到的值不会被 rollback
db.accounts.find(
  { _id: 7 }
).readConcern("majority")

// 实时线性读：linearizable 会额外发一个 no-op majority 写，
// 确认本节点仍是 primary，代价最高，只能读 primary
db.accounts.find({ _id: 7 }).readConcern("linearizable")

把常见组合摊开看保证与代价。表里每一行是一个真实会被选用的搭配。

5.4因果一致性、HLC，与"持久性 ≠ 可见性"

一个写在本地持久，不等于它已对多数可见；这两件事被 write/read concern 分开调。

底层机制（深一层）：HLC（Hybrid Logical Clock）生成 $clusterTime，随每条消息 gossip，并且 HMAC 签名防客户端伪造逻辑时间；afterClusterTime 让读等节点追上某个 cluster time，给 read-your-writes / 单调读。HLC 选型：胜过 Lamport 钟（无物理时间亲和）、向量钟（消息 O(N) 膨胀）、纯墙钟（要时钟同步）。

因果一致性的用法是开一个会话，让连续操作携带并推进 $clusterTime，读端用 afterClusterTime 等节点追平。

// 因果一致性会话：写后读保证 read-your-writes
const s = db.getMongo().startSession({ causalConsistency: true });
const coll = s.getDatabase("app").profiles;

coll.updateOne({ _id: 7 }, { $set: { nick: "lin" } },
               { writeConcern: { w: "majority" } });

// 同一会话内的读携带上一步的 $clusterTime（HMAC 签名，不可伪造），
// 读端用 afterClusterTime 等本节点追平该 cluster time 再返回
coll.find({ _id: 7 }).readConcern("majority");  // 必读到 nick: "lin"
s.endSession();