分布式存储如何发现数据损坏？
简化版
分布式存储通过分层 checksum、读取校验和后台 scrub 发现静默损坏：写入时为块或对象计算校验值并与数据分开可靠保存，读取或巡检时重算比较。发现损坏后先隔离副本，再从校验通过且版本正确的副本修复；checksum 只能证明字节是否变化，不能判断业务语义是否正确，也不能把多数副本简单当成真值。
详细版
损坏可能来自磁盘位翻转、内存错误、控制器、网络传输、软件 bug 或错误运维。只依赖磁盘 I/O 返回成功会漏掉静默损坏。
常见做法是在页、块、SSTable、对象或日志段上保存 CRC32C、xxHash 或密码学哈希。CRC 适合高效检测随机错误，安全对抗场景才需要 SHA-256 等强哈希。
读路径发现 mismatch 时不能把坏数据返回，也不能立刻覆盖所有副本。先核对对象 ID、版本、长度和 commit 信息，选择可信健康副本，修复后再次校验，并保留审计证据。
后台 scrub 负责发现冷数据问题；若 10 PB 数据以 5 GB/s 扫描，理想完整周期约 23 天，还没计算前台限速和重试，因此必须按风险分层安排频率。
完整版教学
一、什么是静默数据损坏
显式磁盘错误容易发现，危险的是设备返回“读取成功”但字节已经变化。若系统没有端到端校验，错误可能被复制、备份甚至进入快照，最终所有副本都变成一致的错误。校验必须覆盖从写入、传输、落盘到读取的完整路径。
二、Checksum 放在哪一层
小粒度校验定位精确，但元数据和 CPU 成本更高；大粒度校验开销小，却可能为修一个小错误重传整个大对象。工程上常组合使用页/块 CRC、文件级哈希和清单级 Merkle Tree。
| 粒度 | 优点 | 代价 |
|---|---|---|
| 4～64 KB 块 | 精确定位修复 | 校验元数据较多 |
| SSTable/段文件 | 实现简单 | 损坏定位粗 |
| 对象整体 | 适合对象 API | 大对象重传成本高 |
| Merkle 分层 | 快速比较副本差异 | 构建和维护树成本 |
三、写入与读取校验流程
写入端基于确定的字节序列计算 checksum，将数据、长度、版本和 checksum 原子关联。网络层可以再次校验传输，落盘后按风险决定是否 read-after-write。读取时先验证元数据，再读数据重算；不匹配则标记副本 suspect。
write bytes -> checksum -> durable data+metadata
read bytes -> recompute -> compare -> return / quarantine如果 checksum 与数据保存在同一可能被错误覆盖的结构中，软件 bug 可能同时改坏二者。关键系统会使用不可变清单、独立元数据、端到端对象哈希或签名增强可信度。
四、后台 Scrub 为什么必要
热数据能在读取时被动发现问题，冷数据可能几年无人访问。Scrub 周期性读取并校验所有数据，让潜伏错误在其他副本也损坏前暴露。频率应按介质故障率、数据价值、副本数和恢复时间设置。
例如 10 PB 数据按 5 GB/s 连续扫描，完整一轮约 10 PB / 5 GB/s ≈ 23 天。若只能使用 20% 带宽，周期接近 115 天。应给关键元数据更短周期，并在设备 SMART 异常后提高优先级。
五、发现损坏后如何选真值
三副本中 A checksum 失败、B/C 校验通过且版本相同，可以隔离 A 并从 B 或 C 修复。但 B/C 内容不同或版本不一致时，不能简单多数投票；要结合共识日志、对象版本、提交证据和权威清单判断。
修复采用 copy-on-write：下载到临时位置，校验长度和 checksum，fsync 后原子替换。原损坏文件应保留必要取证信息，避免自动修复掩盖系统性软件 bug。
六、Checksum 的能力边界
checksum 检测字节是否与记录值一致，却无法发现“应用本来就写错金额”或“所有副本都复制了同一错误”。这类语义错误需要状态机不变量、审计流水和业务对账。非密码学 CRC 也不能防恶意篡改，因为攻击者可同时重算 CRC。
监控包括 checksum_error_total、scrub 覆盖率与最老未检时间、按设备/机架聚类、修复成功率、重复损坏率和隔离容量。短期内同型号设备集中报错应触发批次风险调查。
记忆钩子：先“发现字节不对”，再“证明哪个版本正确”，最后“原子修复并复验”；这三步不能合成一句“从副本拷回来”。
七、常见误区与追问
- 误区：磁盘有 ECC 就不需要应用 checksum。 错误可能发生在控制器、内存、传输和软件层。
- 误区：副本多数相同就一定正确。 同一软件 bug 或错误复制可能污染多数，需版本与提交证据。
- 误区：CRC 可以防恶意篡改。 CRC 面向随机错误，不具备密码学抗伪造性。
- 追问：为什么需要后台 scrub？ 冷数据不会经过读路径，潜伏错误必须主动发现。
- 追问：修复时为何先写临时文件？ 避免中断留下半份数据，并便于校验后原子切换。
- 追问：所有副本都坏了怎么办？ 从可信快照/备份恢复，并调查共同故障和恢复点。
八、加强记忆
数据完整性是一条闭环：写时生成校验，读时与后台巡检负责发现，版本和提交证据负责选真值，隔离加原子替换负责修复，最后再次校验。checksum 是字节完整性的传感器，不是业务正确性证明，也不是备份的替代品。