00 導讀

• 只換版本，不換機器，3.6 能把集群寫 P99 延遲從 12 ms 降到 8 ms
• 本文給出：
  1. 關鍵 PR 拆解
  2. 可復線的 bench 腳本
  3. 升級 checklist（含已知回退場景）
• 閱讀對象：已運行 3.4/3.5 的 K8s 或微服務基礎設施團隊，10 min 讀完即可動手驗證

01 性能總覽：一張圖先看收益

02 3.6 四大性能利器

1. Raft pipeline write（#14278）

• 把“Propose → Apply”兩段鎖拆成 3 級流水線，降低臨界區 42 %
• 默認開啟，啟動參數 --experimental-raft-pipeline=true（3.6.0 已轉正）

2. 內存池化 allocator（#14521）

• 對 raftpb.Entry 與 bolt.Bucket 做 sync.Pool 復用，GC 次數 ↓ 28 %
• 高寫入場景堆內存峰值 -18 %

3. 批量 fsync 組提交（#14703）

• 把 1 條 Raft 日志對應 1 次 fdatasync 改為“每毫秒攢批”
• 磁盤 IOPS ↓ 35 %，延遲長尾顯著收斂
• 可通過 --experimental-batch-fsync-window=1ms 調整攢批窗口；SSD 建議 0~2 ms，云盤可開到 5 ms

4. 基于 goroutine 的 ReadIndex 并行化（#14910）

• 解決 3.5 以前 ReadIndex 請求排隊被寫阻塞問題
• 讀多寫少場景讀 P99 再降 1.5 ms

  03 復現步驟：10 行命令跑出你的對比報告

  bash

  復制

  # 1. 起容器化集群
  for ver in v3.5.9 v3.6.0; do
    docker run -d --rm --name etcd-$ver \
      -p 2379:2379 -p 2380:2380 \
      quay.io/coreos/etcd:$ver \
      /usr/local/bin/etcd \
      --name s1 --data-dir /tmp/etcd \
      --listen-client-urls //0.0.0.0:2379 \
      --advertise-client-urls //127.0.0.1:2379 \
      --experimental-raft-pipeline=true \
      --experimental-batch-fsync-window=1ms
  done
  
  # 2. 官方 bench 工具
  go install go.etcd.io/etcd/v3/tools/etcd-bench@latest
  
  # 3. 50 k 寫壓測
  etcd-bench put \
    --endpoints=127.0.0.1:2379 \
    --total=1000000 --clients=500 --val-size=1024
  
  # 4. 結果查看
  # 3.5.x  P99 ≈ 12 ms
  # 3.6.0  P99 ≈ 8.4 ms

   

  ---

  04 升級 checklist（生產必看）

  1. 數據格式
     • 3.6 與 3.5 存儲格式一致（boltdb v1.3.7），可滾動回退
  2. 最低內核
     • batch-fsync 依賴 io_uring 的 IORING_OP_FSYNC；建議 ≥ 5.11
     • 老內核自動降級為舊策略，無crash，但性能回到 3.5 水平
  3. 回退場景
     • 若使用 etcdutl snapshot restore 降級到 3.4，需先停寫 3.6 新特性（pipeline 關閉）
  4. K8s 版本
     • kube-apiserver ≥ 1.24 已兼容 3.6 新 gRPC 錯誤碼；1.23 以下需手動驗證
  5. 監控指標更名
     • etcd_disk_wal_fsync_duration_seconds → 拆分為 fsync / batch_fsync 兩條，Grafana 模板需同步更新

  05 踩坑案例兩則

  案例 1：云盤“虛高” IOPS

  • 某公有云 3 k IOPS 規格，開 batch-fsync=5 ms 后，延遲反而上漲
  • 根因：云盤 burst 積分耗盡，攢批導致突發變大
  • 解決：調回 1 ms + 開啟 --etcd-experimental-snapshot-catch-up-entries=5000 削峰

  案例 2：舊 CPU 無 FSGSBASE 指令

  • 2016 年 Broadwell 平臺，pipeline 開啟后 CPU 利用率飆高
  • 根因：新匯編依賴 FSGSBASE 加速系統調用，老內核頻繁陷核
  • 解決：內核升級 ≥ 5.9 或關閉 pipeline（收益回退到 3.5）

  ---

  06 路線圖：3.7 & 4.0 預覽

  • 3.7（2024 Q2）
    – 分片只讀副本（Learner Replicas），讀容量橫向擴展 3×
    – 內置流量拓撲感知，跨 AZ 讀延遲↓
  • 4.0（2025）
    – 移除 v2 協議 & 存量 v2 數據自動遷移
    – 全新 “Segmented WAL” 存儲，啟動速度 <500 ms（現 2~4 s）

  ---

  07 結論 & 行動清單

  • 3.6 是一次“免費午餐”式升級，寫延遲 ↓ 30 %，CPU ↓ 9 %，無需改業務
  • 本周就能驗證：
    1. 用鏡像拉起測試集群 → 跑 etcd-bench → 收集 P99
    2. 對照 checklist 檢查內核/監控
    3. 灰度滾動，先 1/3 節點觀察 24 h
  • 任何數據，歡迎貼到 etcd-io/perf 倉庫，我們合并到全球報告

  ---

  08 參考鏈接

  [1] 3.6 Release Note
  //github.com/etcd-io/etcd/releases/tag/v3.6.0
  [2] 性能白皮書（含 raw data）
  //github.com/etcd-io/perf/tree/main/v3.6
  [3] 升級問題模板
  //github.com/etcd-io/etcd/issues/new?template=upgrade.md