基于 Raft 的一致性读写的延迟分析：磁盘 fsync 策略与网络往返的端到端建模
一、Raft 延迟的构成：每次写入跨越的 6 个系统边界
一个 Raft 写入请求的端到端延迟由以下阶段构成：客户端 → Leader 网络（0.11ms）、Leader 序列化（520μs）、Leader AppendEntries → Follower × N（网络 0.11ms）、Follower 磁盘 fsync（0.55ms SSD / 515ms HDD）、Follower 响应 → Leader（0.11ms）、Leader 提交 → 客户端响应（0.1~1ms）。
其中 fsync 是主导因子。NVMe SSD 的 fsync 延迟约 200500μs，SATA SSD 约 13ms，HDD 约 5~15ms。但关键细节是：Raft 的提交不需要等待所有 Follower 的 fsync 完成，只需多数（Quorum）。因此三节点集群的写入延迟 = max(fsync_leader, network + fsync_fastest_follower)，而非 sum of all。
这是 Raft 延迟模型的第一个被忽略的要点：流水线化。Leader 的 AppendEntries 是并行发送的，不是串行的。写入延迟 = Leader fsync + 网络 RTT（取最小的多数 Follower 的响应时间）。
流水线化的另一个好处是：Leader 不需要等待前一轮的 AppendEntries 确认就可以发送下一轮的日志条目。这显著提高了吞吐，特别是在高延迟网络中。但流水线化增加了内存占用（需要缓存未确认的日志条目）和复杂性（需要处理乱序响应）。
磁盘调度的合并效应也很重要。现代 SSD 的 FTL（Flash Translation Layer）会将多个 fsync 请求合并为一次物理写入（Write Coalescing）。在 Raft 的批量提交场景中（如 etCD 的 batch 窗口 = 10ms），多个日志条目的 fsync 可能被合并，实际磁盘延迟接近单次 fsync 而非累加。这使得 Raft 的吞吐在 batch 模式下显著提升，而延迟仅增加少量。
二、Raft 写入的延迟分解模型
在例子中，Follower 1 的 fsync 耗时 1ms，Follower 2 耗时 3ms（假设 SSD 忙碌）。Leader 在 Follower 1 响应后即获得多数（Leader + Follower 1），总延迟 = 1.22ms（Leader fsync 1ms + 网络传输 0.2ms + apply 0.02ms）。
关键洞察：Raft 的多数提交机制天然对慢副本有容忍性——只要超过半数节点响应即可提交。一个慢副本不会阻塞整个集群。
但延迟的尾部（P99/P999）受最慢的多数派影响。在 5 节点集群中，多数派 = 3，P999 延迟取决于第 3 快的 Follower 的响应时间。如果集群中有 1 个慢节点（如磁盘老化），P999 延迟会显著上升。解决方案：使用 PreVote 防止慢节点成为 Leader，或配置 CheckQuorum 自动 step down 慢 Leader。
网络不对称性的影响也不容忽视。在跨可用区（Cross-AZ）部署中，Leader → Follower 1（同 AZ）的网络 RTT 为 0.2ms，Leader → Follower 2（跨 AZ）的网络 RTT 为 2ms。此时，即使 Follower 2 的 fsync 更快，网络延迟也会主导总延迟。生产部署应尽量将 Follower 分布在同 AZ 的不同机架，而非跨 AZ。
三、Rust 中的 Raft 延迟测量工具
use std::sync::Arc;
use std::sync::atomic::{AtomicU64, Ordering};
use std::time::{Duration, Instant};
use std::collections::VecDeque;
use parking_lot::RwLock;
/// 延迟样本
#[derive(Debug, Clone)]
struct LatencySample {
/// 阶段名称
phase: &'static str,
/// 耗时（微秒）
duration_us: u64,
/// 时间戳
timestamp: Instant,
}
/// Raft 写入延迟追踪器
///
/// 追踪以下阶段：
/// 1. serialize: Leader 序列化日志条目
/// 2. fsync_leader: Leader 的本地持久化
/// 3. network_to_follower: Leader → Follower 网络
/// 4. fsync_follower: Follower 的本地持久化（Per Follower）
/// 5. network_to_leader: Follower → Leader 网络响应
/// 6. apply: Leader Apply 到状态机
/// 7. respond: 响应客户端
struct RaftLatencyTracker {
/// 各阶段的延迟样本队列（用于 P50/P99 计算）
samples: RwLock<VecDeque<LatencySample>>,
/// 当前总样本数
total_samples: AtomicU64,
/// 分 Follower 的 fsync 延迟
follower_fsync: RwLock<Vec<VecDeque<u64>>>,
}
impl RaftLatencyTracker {
fn new(num_followers: usize) -> Self {
RaftLatencyTracker {
samples: RwLock::new(VecDeque::with_capacity(10000)),
total_samples: AtomicU64::new(0),
follower_fsync: RwLock::new(vec![VecDeque::new(); num_followers]),
}
}
/// 记录单个阶段的延迟
/// 设计原因：使用 RwLock 而非 Mutex，允许多个线程并发写入
/// 但 VecDeque::push_back 需要写锁，因此实际是互斥的
/// 高并发场景下应改为 per-thread buffer + 定期聚合
fn record(&self, phase: &'static str, duration: Duration) {
let mut samples = self.samples.write();
samples.push_back(LatencySample {
phase,
duration_us: duration.as_micros() as u64,
timestamp: Instant::now(),
});
// 限制队列大小（保留最近 10000 个样本）
// 设计原因：防止长时间运行后内存无限增长
// 10000 个样本约占用 320KB（每个样本 32 字节）
while samples.len() > 10000 {
samples.pop_front();
}
self.total_samples.fetch_add(1, Ordering::Relaxed);
}
/// 记录 Follower 的 fsync 延迟
fn record_follower_fsync(&self, follower_id: usize, duration: Duration) {
let mut followers = self.follower_fsync.write();
if let Some(queue) = followers.get_mut(follower_id) {
queue.push_back(duration.as_micros() as u64);
while queue.len() > 1000 {
queue.pop_front();
}
}
}
/// 计算各阶段的 P50/P99 延迟
fn latency_percentiles(&self) -> Vec<(String, u64, u64)> {
let samples = self.samples.read();
// 按阶段分组
let mut phases: std::collections::HashMap<&str, Vec<u64>> =
std::collections::HashMap::new();
for s in samples.iter() {
phases.entry(s.phase).or_default().push(s.duration_us);
}
let mut results = Vec::new();
for (phase, mut durations) in phases {
durations.sort_unstable();
let p50 = durations[durations.len() / 2];
let p99 = durations[(durations.len() as f64 * 0.99) as usize];
results.push((phase.to_string(), p50, p99));
}
results
}
/// 计算端到端延迟模型
///
/// 模型：e2e = leader_fsync + min(majority_of_follower_latency) + apply + respond
/// 其中 follower_latency = network_rtt/2 + fsync_follower
fn estimate_e2e_latency(
&self,
leader_fsync_p50: u64,
network_rtt_p50: u64,
apply_time: u64,
respond_time: u64,
) -> u64 {
let followers = self.follower_fsync.read();
// 收集所有 Follower 的 P50 fsync 延迟
let mut follower_latencies: Vec<u64> = followers.iter()
.filter(|q| !q.is_empty())
.map(|q| {
let mut sorted: Vec<u64> = q.iter().cloned().collect();
sorted.sort_unstable();
sorted[sorted.len() / 2] + network_rtt_p50 / 2
})
.collect();
// 排序取最小的 majority
follower_latencies.sort_unstable();
let majority = (followers.len() + 1) / 2;
let min_majority = follower_latencies.iter()
.take(majority)
.max()
.copied()
.unwrap_or(0);
leader_fsync_p50 + min_majority + apply_time + respond_time
}
}
/// 磁盘 fsync 性能基准测试
struct FsyncBenchmark;
impl FsyncBenchmark {
/// 测量 fsync 的 P50/P99 延迟
///
/// 测量方法：
/// 1. 创建临时文件
/// 2. 写入 4KB（典型 Raft 日志条目大小）
/// 3. fsync 并计时
/// 4. 重复 1000 次
/// 5. 计算分位数
fn measure(samples: usize) -> (u64, u64) {
use std::io::Write;
let mut durations = Vec::with_capacity(samples);
let path = "/tmp/raft_fsync_bench.tmp";
for _ in 0..samples {
let mut file = std::fs::OpenOptions::new()
.create(true)
.write(true)
.truncate(true)
.open(path)
.unwrap();
let data = [0u8; 4096]; // 4KB 日志条目
let start = Instant::now();
file.write_all(&data).unwrap();
file.sync_all().unwrap(); // fsync
let elapsed = start.elapsed().as_micros() as u64;
durations.push(elapsed);
}
durations.sort_unstable();
let p50 = durations[samples / 2];
let p99 = durations[(samples as f64 * 0.99) as usize];
// 清理
let _ = std::fs::remove_file(path);
(p50, p99)
}
/// 不同存储介质的 fsync 延迟参考值
fn reference_latencies() -> Vec<(&'static str, u64)> {
vec![
("NVMe SSD (Optane)", 50), // 50μs
("NVMe SSD (TLC)", 300), // 300μs
("SATA SSD", 2000), // 2ms
("HDD 7200RPM", 8000), // 8ms
("EBS gp3 (AWS)", 2000), // 2ms (典型)
]
}
}
/// Raft 写入延迟模型：分析各因素对总体延迟的贡献
#[derive(Debug)]
struct LatencyBudget {
/// 总预算（目标延迟）
budget_us: u64,
/// 各阶段分配
leader_fsync: u64,
network_rtt: u64,
follower_fsync: u64,
apply: u64,
}
impl LatencyBudget {
/// 给定目标延迟，反推各阶段的上限
fn decompose(target_p99_us: u64) -> Self {
// 经验分配比例（基于 AWS EC2 同 AZ 部署的实测）
LatencyBudget {
budget_us: target_p99_us,
leader_fsync: target_p99_us * 40 / 100, // 40%
network_rtt: target_p99_us * 25 / 100, // 25%
follower_fsync: target_p99_us * 25 / 100, // 25%
apply: target_p99_us * 10 / 100, // 10%
}
}
/// 检查当前硬件是否满足预算
fn validate(&self) -> Vec<String> {
let mut warnings = Vec::new();
// Leader fsync 必须 < 预算的 40%
let (_, p99_fsync) = FsyncBenchmark::measure(100);
if p99_fsync > self.leader_fsync {
warnings.push(format!(
"Leader fsync P99={}μs exceeds budget {}μs. Need faster disk.",
p99_fsync, self.leader_fsync
));
}
// 网络 RTT 必须 < 预算的 25%
// （实际应从网络监控采集，此处简化）
warnings
}
}
fn main() {
// 测量 fsync 性能
let (p50, p99) = FsyncBenchmark::measure(1000);
println!("=== Disk fsync Benchmark ===");
println!("P50: {}μs, P99: {}μs", p50, p99);
// 参考值
println!("\n=== Reference fsync Latencies ===");
for (medium, latency) in FsyncBenchmark::reference_latencies() {
println!("{: <25} {: >6}μs", medium, latency);
}
// 追踪器初始化
let tracker = RaftLatencyTracker::new(2);
// 模拟一次写入
let start = Instant::now();
let serialize = Duration::from_micros(10);
tracker.record("serialize", serialize);
let leader_fsync = Duration::from_micros(300); // NVMe SSD
tracker.record("fsync_leader", leader_fsync);
let network_to_followers = Duration::from_micros(200);
tracker.record("network_to_follower", network_to_followers);
tracker.record_follower_fsync(0, Duration::from_micros(350));
tracker.record_follower_fsync(1, Duration::from_micros(420));
let apply = Duration::from_micros(20);
tracker.record("apply", apply);
let e2e = start.elapsed().as_micros() as u64;
println!("\n=== E2E Latency ===");
println!("Total: {}μs", e2e);
// 延迟模型估算
let estimated = tracker.estimate_e2e_latency(300, 400, 20, 50);
println!("Estimated: {}μs", estimated);
// 延迟预算分解
let budget = LatencyBudget::decompose(5000); // 目标 P99 ≤ 5ms
println!("\n=== Latency Budget (target P99 ≤ 5ms) ===");
println!("Leader fsync: {}μs", budget.leader_fsync);
println!("Network RTT: {}μs", budget.network_rtt);
println!("Follower fsync: {}μs", budget.follower_fsync);
println!("Apply: {}μs", budget.apply);
let warnings = budget.validate();
for w in warnings {
println!("WARNING: {}", w);
}
}
FsyncBenchmark::measure 使用临时文件而非预分配文件的原因是模拟 Raft 日志追加的真实场景——日志条目追加到日志文件末尾，每次写入后 fsync。对比 O_DIRECT 和 Buffered I/O：Buffered I/O 的 write 返回后数据在 Page Cache 中，fsync 才刷到磁盘。O_DIRECT 绕过 Page Cache，但需要 512 字节对齐。
延迟预算分解模型将 P99 目标拆分为各阶段上限，用于硬件选型决策。例如要求 Raft 写入 P99 ≤ 5ms，则 Leader fsync 的 P99 必须 ≤ 2ms——这意味着必须使用 NVMe SSD（P99 < 1ms），不能用 SATA SSD（P99 可达 3~5ms）。
四、Raft 延迟优化的工程手段
Raft 延迟优化的工程手段：
减少 fsync 频率：
- 批量写入（Batch）：将多个日志条目合并为一次 fsync
- 代价：单条日志的尾延迟增加（等待批次满）
- 建议批次大小：10~100 条（根据延迟目标和吞吐需求）
- etcd 的 batch 窗口默认为 10ms，可在吞吐和延迟间取得良好平衡
Pipeline 优化：
- Raft 原生支持 Pipeline：Leader 在收到前一批次的响应前发送下一批次的
AppendEntries - 窗口大小（Window Size）需要根据带宽-延迟积（BDP）调整
- 窗口过大导致内存占用高，窗口过小无法充分利用网络带宽
- 经验公式：Window_Size = Bandwidth × RTT / Log_Entry_Size
Read Index 优化：
- 只读请求不需要 fsync，通过 Read Index 保证线性一致性
- Read Index 的延迟仅需一次心跳往返（~1ms），远低于写入
- 在 Raft 论文中称为
Read Index Read，etcd 的实现称为Raft Read Index
Lease Read 优化：
- Leader 在当选后获取 Lease（租约），Lease 有效期内无需走 Quorum Read
- 延迟接近 Local Read（< 100μs），但需要时钟同步（NTP）
- 时钟跳变会导致 Lease 失效，退化为 Read Index
Pre-Vote 优化：
- 防止网络分区后的孤立节点频繁触发选举，导致正常 Leader 被推翻
- Pre-Vote 要求候选者先确认多数节点可接受其成为 Leader，再增加 term 并发起选举
- 这不直接降低写入延迟，但减少选举导致的可用性中断
五、总结
- Raft 写入延迟 = Leader fsync + min(多数 Follower 的网络+磁盘延迟) + apply。多数提交机制使慢副本不阻塞整体。
- fsync 是延迟主导因子（40%），NVMe SSD P50=300μs、SATA SSD P50=2ms、HDD P50=8ms，决定了延迟下限。
- 流水线化使
AppendEntries并行发送，延迟取最快多数而非累加。三节点集群仅需最快的一个 Follower 响应。 - 延迟预算分解模型将 P99 目标拆分为各阶段上限，用于指导存储选型：若目标 P99 ≤ 5ms，磁盘 fsync P99 必须 ≤ 2ms。
- 批量 fsync 和 Pipeline 是降低单条延迟的主要手段，但需在吞吐和延迟间权衡。Read Index 使只读请求免于 fsync 开销。
转载自 CSDN-专业IT技术社区
原文链接：https://blog.csdn.net/2301_81410839/article/details/162969209
