DSS故障容错机制

在故障容错机制中：

如果写操作失败：

1. 重写 (Rewrite): 系统会尝试重新写入出错的部分。
2. 不完全一致的块 (Inconsistent Chunks):
   • 块副本可能不是完全一致的（即副本内容可能不同步）。
   • 使用**校验和 (Checksum)**来标记和跳过有问题的文件区域，确保数据的完整性。

如果一个Chunkserver失败：

1. 检测失败 (Detect Failure):
   • Master通过“心跳”机制检测Chunkserver是否失联。
2. 更新副本计数 (Update Replication Count):
   • Master会减少丢失的Chunk副本计数。
3. 再复制 (Re-replication):
   • Master会在其他Chunkserver上重新创建缺失的副本。

故障容错总结：

1. 高可用性 (High Availability):
   • 快速恢复 (Fast Recovery)：
     • Master和Chunkserver可以在几秒内重启。
   • 块复制 (Chunk Replication)：
     • 默认每个块有3个副本。
   • 影子Master (Shadow Master)：
     • 在主Master失效时接管其功能。
2. 数据完整性 (Data Integrity):
   • 每个Chunk的64KB部分都会计算校验和，检测和避免数据损坏。

这些机制共同确保了系统即使在硬件故障或写操作失败时，仍然能够快速恢复并保证数据的可靠性。

通俗来讲：

如果写操作失败

• **怎么办？**系统会再试一次，不会放弃数据写入的努力。
• **写进去的内容不完全一样怎么办？**用“校验和”这套工具来检查哪些地方有问题，只处理有问题的部分，其他没问题的就不用动，尽量减少重复劳动。

如果一个存储块的服务器挂了（Chunkserver失败）

• **怎么知道挂了？**Master像“班主任”一样，定时点名（心跳检测），发现谁没响应就知道出问题了。
• 挂了之后呢？
  1. 班主任会标记哪些块缺了副本。
  2. 然后Master会指派其他服务器再重新存一份，确保总副本数量够用。

总的来说

1. 高可用性：

   • 系统“脑子”（Master）和存储“成员”（Chunkserver）都很快能重启，不会长时间瘫痪。
   • 每份数据都有多个副本（通常是3份），就算一个服务器坏了也没关系，其他两份还能顶上。
   • 有备用Master（“影子Master”），如果主Master挂了，影子Master马上接管，系统不至于“没人管”。

2. 数据完整性：

   • 系统会像“检查作业”一样，每64KB的数据都做个“校验和”，确认数据没被损坏。

**总结一下：**系统不怕硬件坏，不怕数据出错，有“多份副本”和“随时检查”的策略保证系统稳定运行，哪怕出问题也能迅速解决，像一个非常谨慎且行动力强的管家。