前言

在分布式系统中，数据被多副本存储是常见做法，用于提升容错与可用性。然而，多副本之间的数据一致性维护是一个复杂的问题。**Read Repair（读修复）机制，正是实现最终一致性（eventual consistency）**的重要手段之一。

定义

Wiki 定义如下：

Read repair is a technique used in eventually consistent distributed data stores to ensure consistency by comparing and fixing data during read operations.

简而言之：当读取多个副本时，发现副本间数据不一致，则顺便修复它们。

工作原理

一句话：通过读取多个副本，发现不一致后，在后台悄悄修复陈旧副本。

工作流程如下：

  1. 客户端发起读请求；
  2. 系统读取多个副本（通常大于等于读的 quorum）；
  3. 比较副本数据的时间戳或版本号；
  4. 若发现某些副本数据落后，则主动将最新的数据写回这些副本；
  5. 对客户端返回最新数据，同时完成副本修复。

属性与指标

关注的 Read Repair 属性与指标包括：

  1. 触发频率 是否每次读都修复？（见“类型”）

  2. 修复延迟 修复操作在后台完成，可能存在一定延迟。

  3. 一致性提升能力 Read Repair 能大幅提升系统的最终一致性。

  4. 额外开销 每次读取副本数增加，可能导致网络或 CPU 开销上升。

  5. 数据冲突处理策略 使用时间戳、版本号、或向量时钟决定哪个副本更“新”。

  6. Repair 成功率 是否成功更新所有落后副本，是否有修复失败统计。

类型

按触发方式划分

  1. 同步读修复（Synchronous Read Repair） 读取时立即修复，客户端等待修复完成后返回结果。 ✅一致性高，但延迟也高。

  2. 异步读修复（Asynchronous Read Repair） 读取数据后后台修复副本，客户端无需等待。 ✅性能好，但修复可能延迟。

  3. 概率性读修复（Speculative Read Repair） 仅对一部分读请求触发修复（如 Cassandra 默认每 10% 请求执行）。 ✅权衡一致性与性能。

按执行策略划分

  1. Majority Compare 读取多数副本进行比较，以多数为准。

  2. Full Compare 所有副本全部参与，精度更高但代价更大。

存储位置与操作方式

Read Repair 不涉及额外持久化位置，但它操作如下：

  • 从多个副本读取数据；
  • 比较元数据（如时间戳）；
  • 发起额外写请求以修复落后副本；
  • 可配置 repair 并发度与速率。

Read Repair 与程序关系

从系统设计角度，Read Repair 与程序关系如下：

  1. 开发者透明 系统自动触发，开发者通常无需介入。

  2. 监控指标可见 可通过监控系统看到 repair 请求频率、冲突修复率等。

  3. 调优项丰富 Cassandra 提供如下调优参数：

    • read_repair_chance
    • dc_local_read_repair_chance
    • repair_thread_count
    • hinted_handoff_enabled

常用支持 Read Repair 的系统

以下分布式系统广泛支持 Read Repair：

  1. Apache Cassandra 最经典实现之一，支持同步/异步/概率性修复。

  2. Amazon Dynamo Read Repair 是其“eventual consistency”核心机制之一。

  3. ScyllaDB 基于 Cassandra 架构，进一步优化了修复性能。

  4. Riak 使用 vector clock 进行副本修复判断。

  5. Couchbase / MongoDB（部分场景） 支持弱一致性读取和副本检查修复。