raft共识系统性能测试需聚焦多节点协同下的时序敏感行为：选举延迟、日志复制耗时、提交滞后及网络分区恢复能力，核心是验证高负载下一致性保障不被破坏，而非单纯追求qps峰值。
Go语言编写分布式共识系统（如Raft或Paxos）的性能测试，不能只测单节点吞吐，必须覆盖多节点协同下的时序敏感行为：选举延迟、日志复制耗时、提交滞后、网络分区恢复能力。关键不是压QPS，而是验证一致性保障不被高负载破坏。
聚焦共识核心指标的压测设计
共识系统的性能瓶颈不在CPU或内存，而在节点间通信延迟、日志落盘IO、任期同步开销。测试需量化以下指标：
-
Leader选举完成时间中位数与P99：模拟网络抖动后，集群多久恢复可用；建议用
time.Since()在Candidate状态切换前后打点 - 日志从Propose到Committed的端到端延迟：在客户端发起请求时埋入唯一traceID，由Leader写入Log.Entry.Cmd，并在Follower Commit时回传；避免仅测RPC往返
- 吞吐稳定性（非峰值QPS）：持续发送1000条/秒写请求5分钟，观察CommitIdx增长是否线性、有无卡顿或倒退（说明出现脑裂或回滚）
-
异常注入下的正确性：用
tc-netem对某节点加200ms延迟+10%丢包，验证读写是否仍满足线性一致性（如使用linearizability checker工具校验历史）
客户端压测器必须带状态追踪
普通HTTP压测工具（如Vegeta）无法感知共识状态，需自研压测客户端，具备：
- 每个goroutine持有一个独立
clientID和单调递增seq，请求体包含{"cmd":"set","key":"x","val":"v","seq":123} - 响应中必须返回
committed_index和leader_id，用于后续断言：所有已确认请求的seq必须≤该节点当前CommitIdx - 用
sync.Map缓存未确认请求，超时（如3s）后标记为failed并记录原因（timeout / rejected / no_leader）
服务端可观测性必须内置
共识节点需暴露可聚合的运行时指标，不依赖外部APM：
- 通过
net/http/pprof暴露/debug/pprof/goroutine?debug=2，检查是否存在无限重试协程（如反复发RequestVote但收不到响应） - 自定义
/metrics端点，输出：raft_term{node="n1"}、raft_commit_lag_seconds{node="n2"}（当前Term内最长未提交日志年龄）、raft_rpc_dropped_total{type="append_entries"} - 启用
raft.Logger级别为Debug，将关键事件（如start election in term 5、append entries success to n3）写入结构化日志，便于用jq做时序分析
环境与配置必须贴近真实部署
容器化部署下易忽略的干扰项要主动控制：
- Docker启动时显式设置
--cpus=2 --memory=2g，并在节点内调用runtime.GOMAXPROCS(2)，避免NumCPU()返回宿主机核数导致调度失真 - 禁用TCP延迟确认：
echo 1 > /proc/sys/net/ipv4/tcp_delack_min，防止小日志包因Nagle算法堆积 - etcd或自研Raft存储层若用boltdb，需开启
Options.InitialMmapSize = 1GB并预分配，避免压测中mmap触发STW
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
