Apache Kvrocks 数据库 API 改进：引入 Context 参数提升一致性与隔离性

背景与问题分析

在分布式键值存储系统 Apache Kvrocks 中，当前的数据库 API 设计存在一个潜在的一致性问题。当执行包含多个读操作或嵌套调用的复杂操作时，系统可能会使用不同的快照来执行这些读操作。这意味着在单个操作过程中，后续的读操作可能看到与之前读操作不一致的数据状态，破坏了操作的原子性和一致性。

这种问题在需要"读后写"或"写后读"的场景中尤为明显。例如，当一个命令先写入数据然后立即读取时，由于快照不一致，可能无法正确读取到自己刚刚写入的数据。类似的情况也出现在 Lua 脚本执行和事务处理中。

技术解决方案

为了解决这个问题，我们提出了在数据库 API 中引入 Context 参数的设计方案。Context 结构体将包含以下关键组件：

struct Context {
  explicit Context(engine::Storage *storage);
  
  engine::Storage *storage_ = nullptr;
  const rocksdb::Snapshot *snapshot_ = nullptr;
  rocksdb::WriteBatchWithIndex* batch_ = nullptr;

  rocksdb::ReadOptions GetReadOptions();
  const rocksdb::Snapshot *GetSnapShot();
};

这个设计的核心思想是：

1. 固定快照：通过 Context 传递一个确定的快照，确保在整个调用过程中使用相同的快照视图
2. 写操作可见性：使用 WriteBatchWithIndex 结合 GetFromBatchAndDB 方法，使操作能够看到自己批处理中的修改
3. 隔离性保证：实现快照隔离(Snapshot Isolation)级别，确保单个或多个写操作能看到相同的快照

实现挑战与解决方案

在实现过程中，我们遇到了几个关键技术挑战：

1. 批量写操作处理

现有的代码大量使用 WriteBatch 进行批量写操作。我们需要考虑如何将这些操作与新的 Context 机制集成。经过分析，有两种可能的方案：

• 操作追加：通过 WriteBatch::Iterator 将操作逐个追加到 WriteBatchWithIndex
• 基类转换：使用 WriteBatchBase 基类统一处理不同类型的批量操作

经过评估，第一种方案虽然实现复杂但能保持更好的兼容性，而第二种方案在某些特殊操作(如 DeleteRange)上存在限制。

2. DeleteRange 操作的特殊处理

DeleteRange 是一个性能优化操作，但在新机制下会带来实现复杂性。我们决定：

• 在事务中禁用 DeleteRange 操作
• 对于必须使用 DeleteRange 的场景(如 kvrocks2redis、RDB 等)，转换为逐个删除操作
• 在性能敏感路径上保持原有实现

3. 锁机制与隔离级别

现有的锁机制(LockGuard)保护了写操作涉及的键，但需要与新的快照机制协同工作。我们确认：

• 写锁继续保护关键资源
• 目标隔离级别为快照隔离(SI)
• 确保单个或多个写操作能看到相同的快照

实施路径与进展

目前实施工作已取得以下进展：

1. 完成了 Context 结构体的基本设计
2. 实现了 WriteBatch 操作到 WriteBatchWithIndex 的转换机制
3. 处理了 DeleteRange 操作的特殊情况

在测试过程中发现了一些环境相关的问题(如特定 GitHub Action 环境下的 Go 测试超时)，正在排查解决。

未来工作

接下来的工作重点包括：

1. 完善 Context 参数的全面集成
2. 优化批量操作的处理性能
3. 确保与现有事务机制的兼容性
4. 解决测试中发现的环境问题

这项改进将显著提升 Apache Kvrocks 在复杂操作场景下的数据一致性，为上层应用提供更可靠的基础存储服务。