系统架构 · 一致性与共识

场景 1 · 给自研配置系统写一个 200 行的 Raft 最小骨架(选举 + 日志)

自研元数据服务第一版不需要完整 Raft, 但"随机超时选举 + 日志复制 + 多数派提交"三件必须先跑通, 否则后面全是空中楼阁。下面是最小可讲解骨架。

// 最小 Raft 骨架(省略持久化/快照/成员变更, 仅为讲机制)
func (r *Raft) tick() {
    if r.role == Follower && time.Since(r.lastHeartbeat) > r.electionTimeout {
        r.role = Candidate; r.term++          // 先投自己, 再并行拉票
        for _, p := range r.peers {
            go r.requestVote(p, r.term)       // 多数派同意才当选
        }
    }
}
func (r *Raft) Propose(cmd []byte) error {
    r.log = append(r.log, Entry{Term: r.term, Cmd: cmd})
    return r.replicateAndWait(r.log[len(r.log)-1].Index) // 等多数派 ack 才返回客户端
}

面试口径就三句: term 是逻辑时钟; 当选要多数派; 提交也要多数派——两条"多数派"缺一就会出现双主或丢数据。

场景 2 · 订单表从 ONE 提到 QUORUM, 支付状态不再"闪回"

Cassandra 默认 ONE 在副本抖动时会读到旧支付状态, 客服天天接到"我明明付款了"的工单。按 keyspace 定 RF, 按会话定 CL, 写路径带上时间戳。

-- cqlsh 会话级: 读写都走多数派(N=3 时 = 2 副本)
CONSISTENCY QUORUM;
-- → Current consistency level is QUORUM.

-- 每数据中心 3 副本, 让 QUORUM 有得算
ALTER KEYSPACE orders WITH replication =
  {'class': 'NetworkTopologyStrategy', 'dc1': '3'};

-- 高频覆盖字段用客户端时间戳做 LWW 裁判(前提: 服务器 NTP 已校准)
INSERT INTO orders (order_id, status) VALUES ('A1024','PAID')
  USING TIMESTAMP 1777000000123456;  -- 微秒, 服务端生成, 不用手机时钟

场景 3 · 用户改完昵称刷新还是旧昵称(写后读闪回 30 分钟工单)

写走主库、读随机副本、复制延迟 300ms——用户 5 秒内刷新三次, 有时新有时旧。正解不是压复制延迟, 而是给"刚写过的会话"一个读主窗口。

// 网关路由中间件: 写后 5s 内把该用户的读粘到主库
func (m *Router) Pick(userID string, isWrite bool) *Pool {
    if isWrite {
        m.written.Set(userID, time.Now())
        return m.primary
    }
    if t, ok := m.written.Get(userID); ok && time.Since(t) < 5*time.Second {
        return m.primary      // 读己之写窗口: 这 5 秒别把读交给副本
    }
    return m.replica
}

上线后"改了又变回去"类工单归零; 副本池流量只少了几个百分点, 主库压力可忽略。

场景 4 · 评论楼回复跑到了原帖前面(时钟偏差打脸 LWW 排序)

回帖落在 replicaA、原帖落在 replicaB, 按 server 时间戳排序时两台机器钟差 80ms, 楼里出现"回复先于原帖"的灵异现场。把因果依赖固化进数据结构, 而不是赌时钟。

-- 不赌全局时钟: 楼中楼永远挂在父评论分组内, 结构即因果
CREATE TABLE comments (
  thread_id  bigint,
  parent_id  bigint,      -- 根评论 parent_id = 0; 回复必须携带父 id
  created_at timeuuid,    -- timeuuid 自带毫秒时序, 免跨机时钟对齐
  body       text,
  PRIMARY KEY (thread_id, parent_id, created_at)
);
-- 读楼: 先取 parent_id=0 一页, 再按需展开子楼 → 因果序由结构保证

场景 5 · 笔记应用用客户端时钟做 LWW, 用户丢了一小时的编辑

手机时钟手动回拨一小时, 这一小时内的每次保存都"输给"历史版本。冲突字段改成版本号 LWT(Lightweight Transaction, 底层走 Paxos), 只在真正的热点冲突上用。

-- 错法: USING TIMESTAMP 信任客户端时钟 → 回拨机器的写永远输
-- 正解: 版本号单调才接受, 冲突字段用 LWT(注意: LWT 有共识开销, 慢 3~5 倍)
UPDATE notes SET body = :body, rev = :rev
  WHERE note_id = :id IF rev < :rev;
-- → [applied] = True 才落盘; False 说明来了更新的版本, 返回 409 让客户端合并

场景 6 · 点赞计数用 G-Counter, 三机房互不覆盖还不出锁

全球三机房各自累加再异步对账, 用分布式锁同步每次点赞等于自杀。G-Counter 每机房一格, max 合并, 天然无冲突。

type GCounter struct { mu sync.Mutex; cells map[string]uint64 }

func (g *GCounter) Inc(dc string) { g.mu.Lock(); g.cells[dc]++; g.mu.Unlock() }

func (g *GCounter) Merge(other map[string]uint64) {
    g.mu.Lock(); defer g.mu.Unlock()
    for k, v := range other { if v > g.cells[k] { g.cells[k] = v } }
}

func (g *GCounter) Value() (n uint64) { for _, v := range g.cells { n += v }; return }
// → dc1:{dc1:120,dc2:98} 与 dc2:{dc1:120,dc2:98} 各自读到 218, 无需共识

场景 7 · 注册中心选型: etcd(CP) 还是 Eureka(AP), 配置长什么样

服务发现要的是"网络抖动时别把幸存实例全摘掉", 属 AP 场景; 配置/选主要的是"全集群同一份真值", 属 CP 场景。两边真实配置对照。

# Eureka(AP): 分区时保可用, 宁可留着可能过期的实例
eureka:
  server:
    enable-self-preservation: true       # 自我保护: 不再激进剔除实例
    renewal-percent-threshold: 0.85      # 续约低于阈值 85% 触发保护
  client:
    registry-fetch-interval-seconds: 30  # 客户端容忍最多 30s 旧注册表
# etcd(CP): 分区时少数派直接拒写—— 要的正是"宁拒不错"

场景 8 · 京沪深三机房部署 Quorum, 写延迟从 2ms 涨到 50ms 的账

共识成员跨广域网, 每笔写都要等多数派往返; 把多数派留在同城、跨机房只放异步副本, 延迟立刻回血。

-- 部署 A: 北京×2 + 上海×1 → 本地(北京)多数派凑得齐, 写 ≈ 2ms RTT
-- 部署 B: 京/沪/穗各 1 台 → 每写跨 1300km ≈ 25ms RTT × 共识往返 → 50ms+
-- Cassandra 的解法: 本地写本地确认, 跨 DC 异步追平
CONSISTENCY LOCAL_QUORUM;   -- 只等本 DC 的 2/3, 远端机房不进写关键路径
-- 代价: 异地机房读本地副本可能落后毫秒级 → 跨地读要接受最终一致

场景 9 · 单调读 SDK: 客户端记住版本号, 读倒退就换节点(正确用法模板)

Leaderless 存储读多副本, 想要单调读不能只靠服务端, 客户端 SDK 保留"已见版本下界"是标准模板。

func (s *Session) Read(key string) (string, error) {
    for i := 0; i < 3; i++ {
        v, rev, err := s.pool.Any().Get(key)
        if err != nil { return "", err }
        if rev >= s.lastRev {            // 至少和上次一样新才接受
            s.lastRev = rev
            return v, nil
        }
        time.Sleep(20 * time.Millisecond) // 慢副本没追上, 重试/换节点
    }
    return "", ErrMonotonicViolated  // 读倒退 → 上报, 而不是退回旧值
}

场景 10 · 共识集群上 3 台还是 7 台: 先算多数派再谈高可用

每次写延迟 ≈ 一个多数派 RTT, 节点越多越跨越慢; 容错数 = (N-1)/2。别为了"更稳"盲目堆节点。

# 挂 N/2 向下取整台仍可写: 3→容忍1, 5→容忍2, 7→容忍3
# 延迟: 7 节点跨机架 > 5 节点同机房 > 3 节点同机架 — 越大越慢
# etcd 官方运维口径: 奇数成员, 大多数场景 3 或 5 就够
$ etcdctl endpoint status --cluster -w table
# → 列出 IS LEADER / RAFT TERM / DB SIZE: 扩容前先看谁在当 leader