前言

在分布式系统中，节点故障是常态而不是例外。为了保障高可用性与最终一致性，很多系统引入了一种重要机制：Hinted Handoff（提示式转交）。它被广泛应用于如 Amazon Dynamo、Apache Cassandra 等分布式数据库系统中，是容错设计的关键一环。

定义

Wiki 定义如下：

Hinted handoff is a technique used in distributed computing to ensure eventual consistency when a node in the system is temporarily unavailable.

简单来说：当某个目标节点不可用时，数据会“暂存”在其他节点，一旦目标节点恢复，再将数据“提示式”转交回去。

工作原理

一句话：临时将写入操作保存于非目标节点中，等目标节点恢复后再“转交”给它。

详细流程：

  1. 客户端发起写请求；
  2. 某些副本节点宕机，无法接收写入；
  3. 其他可用节点代为接收，并标记这些数据的“Hint”；
  4. 后台线程定期扫描 Hint 并检查目标节点是否恢复；
  5. 一旦节点恢复，Hint 数据会被转交回去，完成数据同步；
  6. Hint 数据被清除。

属性与指标

关注的 Hinted Handoff 属性与指标包括：

  1. Hint 保留时间（Hint TTL） Hint 会在本地缓存中保留一定时间，超过后会丢弃。

  2. Hint 存储容量 太多 Hint 占用资源，需防止磁盘/内存爆炸。

  3. 交付频率 多久检查目标节点是否恢复，以及多久交付一次 Hint。

  4. 一致性延迟 提高可用性但可能影响短期内一致性。

  5. 写可用性增强度 在 N 个副本中，即使某些节点挂掉，写操作仍可成功。

  6. Hint 重放失败率 如果 Hint 未能正确重交，会导致永久不一致。

  7. 写入放大（Write Amplification） 存储了额外的 Hint 数据，增加 IO 负担。

类型

按节点行为划分

  1. 正常写入路径 所有副本节点在线，Hint 不会触发。

  2. 降级写入（Degraded Write） 某些副本不可用，Hinted Handoff 被触发。

  3. Hint 清理路径 节点恢复后自动同步 Hint 数据并删除 Hint。

按实现方式划分

  1. 本地存储型 Hint Hint 存储在写入节点本地磁盘中（如 Cassandra 中每个节点的 Hint 文件）。

  2. 内存式 Hint Hint 数据短暂驻留在内存中，适用于轻量级系统。

  3. 批量合并回传 Hint 数据以批量方式合并后再回传，提高效率。

存储位置

Hint 数据通常存储在如下几类介质中：

  1. 磁盘日志文件（hint log）
  2. 内存缓存（如 memtable）
  3. 专用列族或 keyspace（如 Cassandra 的 system.hints）
  4. 队列系统中（如 Kafka 中的延迟处理机制）

Hinted Handoff 与程序关系

根据 Hint 与程序执行关系，可以区分为：

  1. 自动后台机制 多数系统在后台透明执行，无需用户干预。

  2. 用户感知型 Hint（如 Metrics、监控告警） 开发者可通过指标监控 Hint 的堆积与处理情况。

  3. 配置式控制 用户可调节 Hint TTL、写入限制、并发交付数等参数。

常见支持 Hinted Handoff 的产品

以下系统广泛支持 Hinted Handoff 或类似机制：

  1. Apache Cassandra 实现细致且高度可配置的 Hint 管理机制。

  2. Amazon Dynamo / DynamoDB 最早提出该机制的系统之一。

  3. Riak 支持 Hinted Handoff 作为故障恢复策略的一部分。

  4. ScyllaDB 对 Cassandra 的高性能替代实现，同样支持 Hint。

  5. CockroachDB（通过 Raft 变种实现类似效果） 严格一致性，但也包含延迟同步特性。