在分布式存储系统中，如何处理DataNode宕机导致的故障？请描述故障检测、数据恢复、业务影响缓解的流程，并结合360业务场景（如安全日志中断）分析。

1) 【一句话结论】

分布式存储系统通过心跳检测故障、副本复制/故障转移恢复数据、业务层面读取从其他副本获取、写入重试，以最小化360安全日志等业务的中断影响，确保数据可靠性和业务连续性。

2) 【原理/概念讲解】

老师口吻：在分布式存储中，DataNode宕机处理核心是“检测-恢复-缓解”三步。

• 故障检测：DataNode定期向NameNode发送心跳包（如每3秒一次），若超时（如10秒），NameNode标记为故障。这像“人的脉搏”，心跳正常则节点存活，超时则疑似故障。
• 数据恢复：若副本数≥2（如HDFS的副本因子≥2），故障DataNode的数据由其他正常DataNode复制（副本复制）；若副本不足，启动新DataNode并重建数据（故障转移）。这像“多个备份”，一个备份损坏，其他备份继续工作。
• 业务影响缓解：读取操作从其他正常副本获取数据（如安全日志查询），写入操作重试到其他DataNode（如日志写入），避免业务中断。这像“换人继续工作”，故障节点退出后，业务由其他节点承接。

3) 【对比与适用场景】

故障检测方法对比

方法	定义	特性	使用场景
心跳检测	DataNode定期向NameNode发送心跳包	简单，延迟低，但可能漏检（心跳正常但实际故障）	适用于对延迟敏感的场景（如实时日志）
日志检查	NameNode定期检查DataNode的日志文件（如操作日志）	更可靠，能检测实际故障，但延迟稍高	适用于对可靠性要求高的场景（如关键数据）

数据恢复策略对比

策略	定义	特性	使用场景
副本复制	故障DataNode的副本数据由其他正常DataNode复制	快速恢复，需足够副本数（如HDFS的副本因子≥3）	适用于副本数足够的情况（如360安全日志，通常副本因子≥2）
重建	故障DataNode的数据从其他副本重建（如HDFS的副本重建）	慢，但保证数据一致性，适用于副本数不足的情况	适用于副本数不足或数据量大的场景

4) 【示例】

以HDFS为例，DataNode宕机处理流程：

• 故障检测：NameNode定时（3秒）检查DataNode心跳，若超时（10秒），标记故障。
• 数据恢复：若副本数≥2，NameNode将故障DataNode的副本标记为“待复制”，其他DataNode（如副本1的节点）将数据复制到新节点。
• 业务影响缓解：读取请求从其他正常副本获取数据；写入请求重试到其他DataNode。

伪代码（故障检测）：

function checkDataNode(nodeId) {
    if (lastHeartbeatTime(nodeId) + heartbeatTimeout > now()) {
        markNodeAsFailed(nodeId);
        if (replicaCount(nodeId) >= 2) {
            readFromOtherReplicas(nodeId);
        } else {
            triggerReplicaReplication(nodeId);
        }
    }
}

5) 【面试口播版答案】

在分布式存储系统中，处理DataNode宕机主要分三步：首先通过心跳机制检测故障（DataNode定期向NameNode发送心跳，超时则标记故障）；然后根据副本数量恢复数据（若副本数≥2，读取从其他副本获取，写入重试；若副本不足，触发副本复制）；最后缓解业务影响（如360安全日志，读取从其他副本，写入重试，确保日志不中断）。具体来说，比如360的安全日志存储在HDFS中，当DataNode宕机，心跳超时后，NameNode标记故障，若副本数≥2，读取操作直接从其他副本获取日志数据，写入操作重试到其他DataNode，这样就能快速恢复数据并保证业务连续性。

6) 【追问清单】

• 问题1：心跳超时时间如何设置？
  回答要点：心跳间隔和超时时间需平衡，间隔短则检测快，但增加网络开销；超时时间通常设为心跳间隔的3-5倍（如心跳3秒，超时10秒）。
• 问题2：副本因子为2时，宕机后是否还能恢复？
  回答要点：副本因子≥2时，宕机后至少有一个副本可用，读取操作正常；若副本因子为1，宕机后数据丢失，需重建，但重建时间较长。
• 问题3：多个DataNode同时宕机时的处理？
  回答要点：系统优先标记故障节点，按顺序处理副本复制，若故障节点过多，可能暂停部分写入操作，避免资源耗尽。
• 问题4：数据一致性如何保证？
  回答要点：采用最终一致性（如HDFS），读取可能读到旧数据，写入后最终同步；若需强一致性，可增加一致性协议（如ZAB）。
• 问题5：故障转移的延迟？
  回答要点：复制时间取决于数据量和网络带宽，小文件快，大文件可能需几分钟，业务写入会重试，确保数据最终一致。

7) 【常见坑/雷区】

• 坑1：只说检测，不提恢复策略。错误：仅描述心跳检测，未说明如何恢复数据，导致业务中断。
• 坑2：忽略副本数量要求。错误：假设所有副本都可用，实际副本不足时无法恢复数据。
• 坑3：业务影响缓解不具体。错误：仅说读取从其他副本，未提及写入重试，导致写入中断。
• 坑4：假设故障检测100%准确。错误：心跳正常但实际故障（如网络问题），导致漏检。
• 坑5：忽略故障转移的延迟。错误：认为故障转移立即完成，实际需要时间，导致业务中断时间过长。