分布式故障检测

在分布式系统中，故障检测（Failure Detection）是一个看似简单却极其深刻的问题。当我们说"某个节点故障了"，究竟是什么意思？如何判断一个节点是"故障"还是"只是响应慢"？这个问题触及了分布式系统理论的核心——FLP 不可能性定理告诉我们，在异步系统中无法完美地区分"慢"和"故障"。

故障检测的本质困境

同步系统 vs 异步系统

理解故障检测的困难，需要先理解同步系统和异步系统的区别。

**同步系统（Synchronous System）**有明确的边界：消息传输延迟有上限、节点处理速度有下限。在这种系统中，如果某个节点超过预设时间没有响应，我们可以确定它已经故障。判断是精确的、确定的。

**异步系统（Asynchronous System）**则没有这些保证：消息可能无限延迟、节点可能无限慢处理。在这种系统中，无论等待多久，我们都无法确定一个节点是"已经故障"还是"还在处理中"。这是故障检测的根本困境。

现实世界的分布式系统介于两者之间——部分同步（Partially Synchronous）。大部分时间是同步的，但偶尔会进入异步状态（如网络拥塞、GC 暂停）。这种"大部分正常、偶尔异常"的特性，让我们可以设计出实用的故障检测器。

故障检测的不可判定性

考虑这样一个场景：节点 A 向节点 B 发送请求，等待了 10 秒没有收到响应。此时，A 面临三种可能：

1. B 已经崩溃：进程终止，不再响应任何请求
2. 网络分区：B 仍在运行，但 A 和 B 之间的网络中断
3. B 在处理但很慢：B 正在执行耗时操作（如 GC、磁盘 I/O）

在异步系统中，A 无法区分这三种情况。无论选择"认为 B 故障"还是"继续等待"，都可能是错误的。

这种不可判定性不是工程问题，而是理论上的不可能。正如 FLP 定理所揭示的，在异步系统中，不存在能同时保证安全性和活性的确定性故障检测器。

实用的故障检测器

虽然完美的故障检测器不存在，但我们可以设计出足够好的实用故障检测器。关键在于接受"不确定性"，用概率来描述故障检测结果。

心跳机制

心跳（Heartbeat）是最基础的故障检测手段。基本思想是：被监控节点定期发送"我还活着"的消息，监控者在一定时间内没有收到心跳就认为节点故障。

节点B（被监控）          节点A（监控者）
     │                       │
     │──── heartbeat ───────>│ 时间 t1
     │                       │ 更新 lastHeartbeat = t1
     │                       │
     │──── heartbeat ───────>│ 时间 t2
     │                       │ 更新 lastHeartbeat = t2
     │                       │
     │     (网络延迟)         │
     │                       │
     │──── heartbeat ───────>│ 时间 t3 (延迟到达)
     │                       │
     │     (B 崩溃)          │
     │                       │
     │                       │ 时间 t4
     │                       │ 检查: t4 - lastHeartbeat > timeout
     │                       │ 判断: B 故障

固定阈值检测器的实现非常直观：

/**
 * 固定阈值心跳检测器
 * 简单但有问题：阈值难以设定
 */
public class FixedTimeoutFailureDetector {
    
    private final Map<String, Long> lastHeartbeat = new ConcurrentHashMap<>();
    private final long timeout;  // 固定超时时间
    
    public FixedTimeoutFailureDetector(long timeoutMillis) {
        this.timeout = timeoutMillis;
    }
    
    /**
     * 记录收到的心跳
     */
    public void heartbeat(String nodeId) {
        lastHeartbeat.put(nodeId, System.currentTimeMillis());
    }
    
    /**
     * 检查节点是否故障
     */
    public boolean isFailed(String nodeId) {
        Long last = lastHeartbeat.get(nodeId);
        if (last == null) {
            return true;  // 从未收到心跳，认为故障
        }
        return System.currentTimeMillis() - last > timeout;
    }
}

固定阈值的问题：

这种方法虽然简单，但存在一个两难困境：

• 阈值太短：在网络抖动或节点负载高时，容易产生误判（False Positive），将正常节点标记为故障
• 阈值太长：在节点真正故障时，需要很长时间才能检测到，影响系统可用性

实际系统中，网络延迟分布往往是长尾的——99% 的心跳在 10ms 内到达，但 0.1% 可能需要 1 秒甚至更长。固定阈值无法适应这种分布。

Phi Accrual 故障检测器

Phi Accrual Failure Detector 是一种更智能的故障检测方法，由 Naohiro Hayashibara 等人在 2004 年提出。它不给出"故障/正常"的二值判断，而是计算一个"故障嫌疑度"（Phi 值），让上层应用根据业务需求做决策。

核心思想：

将心跳间隔视为一个随机变量，通过历史数据建立其概率分布模型。当新的心跳间隔到来时，计算其"异常程度"。如果间隔显著偏离历史分布，则增加嫌疑度。

Phi 值的含义：
φ = 1  → 约 10% 的误判概率
φ = 2  → 约 1% 的误判概率
φ = 3  → 约 0.1% 的误判概率

应用可以根据对误判的容忍度，选择合适的阈值。

/**
 * Phi Accrual 故障检测器
 * 被广泛使用：Akka、Cassandra、Riak、ZooKeeper 等
 */
public class PhiAccrualFailureDetector {
    
    // 心跳间隔的历史统计
    private final DescriptiveStatistics stats = new DescriptiveStatistics();
    
    // 最小标准差，避免除零和过小的波动
    private static final double MIN_STD_DEVIATION = 500.0;  // 毫秒
    
    // 计算窗口大小
    private static final int WINDOW_SIZE = 1000;
    
    // 上次心跳时间
    private volatile long lastHeartbeatTime = -1;
    
    public PhiAccrualFailureDetector() {
        stats.setWindowSize(WINDOW_SIZE);
    }
    
    /**
     * 记录收到的心跳
     */
    public synchronized void heartbeat() {
        long now = System.currentTimeMillis();
        
        if (lastHeartbeatTime >= 0) {
            long interval = now - lastHeartbeatTime;
            stats.addValue(interval);
        }
        
        lastHeartbeatTime = now;
    }
    
    /**
     * 计算当前的 Phi 值
     * Phi 值越大，节点故障的可能性越高
     */
    public synchronized double phi() {
        if (lastHeartbeatTime < 0 || stats.getN() == 0) {
            return 0.0;  // 没有足够数据
        }
        
        long now = System.currentTimeMillis();
        long timeSinceLastHeartbeat = now - lastHeartbeatTime;
        
        // 获取历史统计
        double mean = stats.getMean();
        double stdDev = Math.max(stats.getStandardDeviation(), MIN_STD_DEVIATION);
        
        // 计算当前间隔的概率密度
        // 使用正态分布模型（实际中也可以使用其他分布）
        double probability = normalDistribution(timeSinceLastHeartbeat, mean, stdDev);
        
        // Phi = -log10(probability)
        // 概率越低，Phi 越大
        if (probability < 1e-10) {
            probability = 1e-10;  // 避免对数为负无穷
        }
        
        return -Math.log10(probability);
    }
    
    /**
     * 判断节点是否故障
     * @param threshold Phi 阈值，通常设为 8-16
     */
    public boolean isFailed(double threshold) {
        return phi() > threshold;
    }
    
    /**
     * 正态分布的概率密度函数
     */
    private double normalDistribution(double x, double mean, double stdDev) {
        double exponent = -Math.pow(x - mean, 2) / (2 * Math.pow(stdDev, 2));
        return Math.exp(exponent) / (stdDev * Math.sqrt(2 * Math.PI));
    }
    
    /**
     * 获取统计信息（用于调试和监控）
     */
    public synchronized String getStats() {
        return String.format("mean=%.2fms, stdDev=%.2fms, n=%d, phi=%.2f",
            stats.getMean(),
            stats.getStandardDeviation(),
            stats.getN(),
            phi());
    }
}

Phi 检测器的优势：

1. 自适应：自动学习网络延迟的分布特征，适应不同的网络环境
2. 可调节：应用可以根据对误判的容忍度选择阈值，不必修改检测器本身
3. 信息丰富：Phi 值是一个连续值，可以用于更复杂的决策逻辑

使用示例：选择合适的阈值

不同的应用场景对误判的容忍度不同：

/**
 * 不同场景的 Phi 阈值选择
 */
public class FailureDetectorConfig {
    
    /**
     * 场景1：分布式锁
     * 误判后果：锁被错误释放，可能导致数据不一致
     * 建议：使用较高的阈值，宁可晚检测也不误判
     */
    public static final double PHI_THRESHOLD_DISTRIBUTED_LOCK = 16.0;
    
    /**
     * 场景2：负载均衡
     * 误判后果：流量被转移到其他节点，轻微的负载不均
     * 建议：使用较低的阈值，快速隔离可能故障的节点
     */
    public static final double PHI_THRESHOLD_LOAD_BALANCER = 8.0;
    
    /**
     * 场景3：缓存失效
     * 误判后果：缓存失效后需要重新计算，性能下降
     * 建议：中等阈值
     */
    public static final double PHI_THRESHOLD_CACHE = 12.0;
}

故障检测器的形式化定义

Chandra 和 Toueg 在 1996 年的论文《Unreliable Failure Detectors for Reliable Distributed Systems》中，对故障检测器进行了形式化定义，这成为后续研究的理论基础。

完整性（Completeness）和准确性（Accuracy）

故障检测器的属性分为两类：

完整性（Completeness）：故障节点最终会被检测到。

• 强完整性（Strong Completeness）：每个故障节点最终被所有正确节点怀疑
• 弱完整性（Weak Completeness）：每个故障节点最终被某个正确节点怀疑

准确性（Accuracy）：正确节点不会被错误地怀疑。

• 强准确性（Strong Accuracy）：没有正确节点被怀疑过
• 弱准确性（Weak Accuracy）：某个正确节点从未被怀疑
• 最终强准确性（Eventually Strong Accuracy）：某个时刻之后，没有正确节点被怀疑
• 最终弱准确性（Eventually Weak Accuracy）：某个时刻之后，某个正确节点不再被怀疑

故障检测器的分类

根据完整性和准确性的组合，可以定义不同级别的故障检测器：

类型	完整性	准确性	说明
Perfect (P)	强	强	完美检测器，现实中不存在
Strong (S)	强	最终弱	可实现，用于解决共识问题
Eventually Strong (◇S)	强	最终弱	可实现，最常见的实用类型
Weak (W)	弱	最终弱	可实现，但用途有限

◇S 故障检测器与共识算法

最重要的实用结果是：使用 Eventually Strong (◇S) 故障检测器，可以在异步系统中解决共识问题。

这个结果的意义在于：即使故障检测器有时会犯错（错误地怀疑正确节点），只要它最终"改正"，共识算法就能正确工作。这为 Raft、Paxos 等算法在异步网络中的正确性提供了理论基础。

/**
 * 共识算法中使用故障检测器的示例
 * 基于 Chandra-Toueg 模型
 */
public class ConsensusWithFailureDetector {
    
    private final PhiAccrualFailureDetector failureDetector;
    private final double phiThreshold;
    
    // 提议值
    private Object proposedValue;
    private boolean decided = false;
    
    /**
     * 共识算法的一轮
     */
    public void consensusRound() {
        // 1. 检测故障节点，排除它们不参与投票
        Set<String> suspectedNodes = getSuspectedNodes();
        
        // 2. 向非故障节点发送提议
        for (String node : allNodes) {
            if (!suspectedNodes.contains(node)) {
                sendProposal(node, proposedValue);
            }
        }
        
        // 3. 收集投票，达到多数派则决定
        int votes = collectVotes(suspectedNodes);
        if (votes > allNodes.size() / 2) {
            decided = true;
        }
    }
    
    /**
     * 获取被怀疑的节点列表
     * 关键：◇S 检测器保证最终只有真正故障的节点被怀疑
     */
    private Set<String> getSuspectedNodes() {
        Set<String> suspected = new HashSet<>();
        for (String node : allNodes) {
            if (failureDetector.phi() > phiThreshold) {
                suspected.add(node);
            }
        }
        return suspected;
    }
}

实际系统中的故障检测

Apache Cassandra

Cassandra 使用 Phi Accrual Failure Detector 监控集群中其他节点的状态。当一个节点的 Phi 值超过阈值时，Cassandra 会将该节点标记为"down"，停止向它发送请求。

Cassandra 还引入了"故障确认"机制：当一个节点检测到另一个节点故障时，它会通知其他节点，让它们也验证这个判断。这减少了单个节点误判带来的影响。

# Cassandra 故障检测配置
phi_convict_threshold: 8
# 阈值越高，对网络抖动越容忍，但检测延迟越长

Akka

Akka 框架提供了内置的故障检测器，用于集群成员管理和路由决策。Akka 的实现考虑了多种因素：

• 心跳间隔的均值和方差
• 可配置的阈值
• 支持不同的时钟源（系统时钟、单调时钟）

// Akka 故障检测器配置
akka.cluster.failure-detector {
  heartbeat-interval = 1 s
  threshold = 8.0
  acceptable-heartbeat-pause = 10 s
}

etcd 和 Raft

etcd（以及大多数 Raft 实现）使用固定超时的心跳机制。Raft 算法要求 Leader 定期发送心跳，Follower 在一定时间内没有收到心跳就认为 Leader 故障，发起新的选举。

Raft 的关键设计是随机化的选举超时：每个节点的超时时间是 baseTimeout + random(0, maxRandom)。这降低了多个节点同时发起选举的概率，减少了选举冲突。

// etcd Raft 选举超时配置
// heartbeat-interval: 100ms
// election-timeout: 1000ms

// 选举超时 = electionTimeout + rand(electionTimeout)
// 默认情况下，超时范围是 1000ms ~ 2000ms

故障检测的最佳实践

1. 双向心跳 vs 单向心跳

单向心跳：被监控节点发送心跳，监控者接收并判断。

被监控节点 ──heartbeat──> 监控者

双向心跳：监控者发送探测，被监控者响应。如果超时无响应，则认为故障。

监控者 ──ping──> 被监控节点
监控者 <──pong── 被监控节点

双向心跳的优势是监控者可以主动控制检测节奏，更适合监控者数量少、被监控者数量多的场景。

2. 心跳与业务分离

将心跳流量与业务流量分离，避免相互干扰。可以使用：

• 独立的网络连接
• 独立的线程池
• 更高的 QoS 优先级

3. 避免级联故障

当检测到节点故障时，系统需要进行重配置（如选举新 Leader、迁移数据）。这些操作会增加剩余节点的负载，可能导致它们也"变慢"，触发更多的故障检测。

缓解措施：

• 逐个处理故障节点，不要同时处理多个
• 重配置时暂停新的故障检测
• 对负载增加进行限流

4. 外部监控与内部检测结合

内部故障检测（节点间互相检测）速度快，但可能受网络分区影响。外部监控（独立的监控系统）更客观，但延迟较高。

理想方案是两者结合：

• 内部检测用于快速响应（秒级）
• 外部监控用于确认和最终判断（分钟级）

/**
 * 混合故障检测器
 */
public class HybridFailureDetector {
    
    private final PhiAccrualFailureDetector internalDetector;  // 内部检测
    private final ExternalMonitorClient externalMonitor;       // 外部监控
    
    /**
     * 综合判断节点状态
     */
    public NodeStatus getStatus(String nodeId) {
        double phi = internalDetector.phi();
        ExternalStatus external = externalMonitor.getStatus(nodeId);
        
        // 内部检测发现问题，外部监控正常 → 可能是网络问题，暂不处理
        if (phi > threshold && external == ExternalStatus.HEALTHY) {
            return NodeStatus.SUSPECTED;
        }
        
        // 内外都认为故障 → 确认故障
        if (phi > threshold && external == ExternalStatus.DOWN) {
            return NodeStatus.CONFIRMED_DOWN;
        }
        
        // 内部正常，外部故障 → 可能是误判，继续观察
        if (phi <= threshold && external == ExternalStatus.DOWN) {
            return NodeStatus.MONITORING;
        }
        
        return NodeStatus.HEALTHY;
    }
}

小结

本章我们深入学习了分布式故障检测的核心概念和实践：

故障检测的本质困境：在异步系统中，无法完美区分"慢"和"故障"。这是分布式系统的基础理论限制。

实用的故障检测器：虽然完美的检测器不存在，但可以通过概率模型（如 Phi Accrual）设计出足够好的实用检测器。

形式化定义：Chandra-Toueg 模型定义了完整性和准确性属性，证明了 ◇S 检测器足以解决共识问题。

工程实践：心跳机制、自适应阈值、双向检测、内外监控结合等实践方法，帮助我们在真实系统中可靠地检测故障。

故障检测是分布式系统的基石——共识算法依赖它排除故障节点，分布式锁依赖它释放锁，数据复制依赖它选择新的 Leader。理解故障检测的本质和实现，是掌握分布式系统设计的关键一步。

如果你想深入学习这一主题，推荐阅读：

• 《Unreliable Failure Detectors for Reliable Distributed Systems》by Chandra & Toueg——故障检测器的形式化定义
• 《The ϕ Accrual Failure Detector》by Hayashibara et al.——Phi 检测器的原始论文
• 《Time, Clocks, and the Ordering of Events in a Distributed System》by Lamport——分布式系统时间问题的奠基之作