Rocksdb事务

发表于 分类于

Rocksdb事务

该篇主要通过网上文章和deepseek问答的方式学习与记录

总览

  1. 提供了一系列的事务API，和快照api:GetSnapshot()
  2. 原理跟mysql类似，存在多版本mvcc，使用悲观锁，key级别锁，死锁回滚等
  3. 无主动的死锁检测（图检测算法），而是通过获取key的锁超时（默认1秒）来回滚前一个事务。

与mysql的事务对比

首先，关于行级锁。RocksDB的事务确实在悲观模式下会对涉及的键加锁，类似于MySQL的行锁，防止其他事务修改相同的数据。但MySQL的InnoDB不仅有行锁，还有间隙锁等，而RocksDB的锁更简单，只是针对具体的键，没有间隙锁的概念。

接下来是版本链。RocksDB使用MVCC，通过序列号来维护版本信息，但并不是每个键都有显式的版本链元数据。相反，它利用LSM-Tree的结构，旧版本的数据保留在SST文件中，直到被压缩清理。而MySQL的InnoDB则在行中存储版本信息，通过undo log构建版本链。两者的机制不同。

然后是死锁检测。RocksDB的悲观事务确实有死锁检测，通过锁管理器和超时机制来处理。MySQL则使用等待图算法主动检测死锁，并回滚代价较小的事务。

RocksDB 和 MySQL 在事务实现的核心机制上存在本质差异。以下从锁机制、版本管理、死锁检测三个维度详细对比：

一、锁机制对比

特性 RocksDB MySQL InnoDB
锁粒度 Key 级别锁（仅悲观事务） 行锁 + 间隙锁（Next-Key Locking）
锁类型 简单独占锁（写锁） 共享锁(S)、排他锁(X)、意向锁
锁管理器 内置分片锁表（TransactionLockMgr） 全局锁表 + 事务上下文
锁升级 不支持 支持行锁升级为表锁
锁冲突检测 超时机制（lock_timeout） 主动死锁检测（等待图算法）

关键差异：

  • RocksDB 没有真正的行锁，只有键锁，且缺乏间隙锁，无法防止幻读。
  • MySQL 的锁机制更复杂，支持多粒度锁和锁升级策略。

二、版本管理对比

特性 RocksDB MySQL InnoDB
MVCC 实现 全局序列号（Sequence Number） 事务ID + 回滚段（Undo Log）
版本链存储 LSM-Tree 多版本数据物理保留 行内隐藏字段（DB_TRX_ID, DB_ROLL_PTR）
可见性判断 基于快照的序列号范围过滤 基于事务ID和Read View
旧数据清理 Compaction 时物理删除 Purge 线程异步清理 Undo Log

关键差异：

  • RocksDB 的版本是隐式的（由 LSM-Tree 的不可变性天然支持），而 MySQL 需要显式维护版本链。
  • RocksDB 的 MVCC 无法实现完整的快照隔离（Snapshot Isolation），而 MySQL 的 RR 级别通过间隙锁+MVCC 解决幻读。

三、死锁检测对比

特性 RocksDB MySQL InnoDB
检测方式 超时回滚（无主动检测） 主动检测（等待图算法）
检测粒度 键锁等待链 行锁等待关系
处理策略 超时后强制回滚 选择代价小的事务回滚（innodb_deadlock_detect）
分布式扩展 无内置支持 通过 XA 协议支持分布式死锁检测

关键差异：

  • RocksDB 的死锁处理更简单粗暴，而 MySQL 有精细的主动检测和回滚策略。
  • RocksDB 的锁管理器设计更适合单机高并发，MySQL 的锁机制为分布式场景留有扩展性。

四、实现原理深度解析

1. RocksDB 事务实现

  • 版本管理：
    • 每个写入操作分配全局递增的 SequenceNumber
    • 读取时通过 GetSnapshot() 获取当前序列号，过滤掉更高版本的数据
    • 旧版本数据在 Compaction 时被物理删除

2. MySQL InnoDB 事务实现

  • Undo Log 管理：
    • 每个行修改记录旧版本到 Undo Log
    • Purge 线程根据最老活跃事务ID清理过期版本

死锁回滚原理

RocksDB 默认的事务实现（悲观事务）没有内置的主动死锁检测机制，它主要依赖 锁超时（Lock Timeout） 策略来解除死锁。但可以通过一些扩展或自定义策略实现类似主动检测的功能。

一、RocksDB 默认的死锁处理机制

1. 锁等待超时（Lock Timeout）

  • 参数：通过 transaction_options.lock_timeout 设置（默认值：1000ms）
  • 触发条件：事务在等待锁时超过指定时间未获取到锁
  • 行为：事务自动回滚并返回 Status::TimedOut 错误
  • 示例配置：
    1
    2
    3
    rocksdb::TransactionOptions txn_options;
    txn_options.lock_timeout = 500; // 超时时间设为500ms
    rocksdb::Transaction* txn = db->BeginTransaction(write_options, txn_options);

2. 锁重试机制（Retry on Conflict）

  • 参数：通过 transaction_options.deadlock_detect_retries 控制重试次数（默认0次）
  • 行为：在超时后自动重试获取锁，而非立即回滚
  • 示例配置：
    1
    txn_options.deadlock_detect_retries = 3; // 最多重试3次

二、RocksDB 无主动死锁检测的设计原因

  1. 性能考量：

    • 主动死锁检测（如等待图算法）需要全局状态跟踪，对高并发场景性能影响较大。
    • RocksDB 作为嵌入式存储引擎，更注重低延迟和高吞吐。

  2. 锁管理器简化：

    • RocksDB 的锁管理器（TransactionLockMgr）采用分片设计（num_stripes），无跨分片的全局锁信息。
    • 分片锁表难以高效构建全局等待图（Wait-for Graph）。

  3. 适用场景假设：

    • 预期在键值存储中，事务冲突概率较低（尤其是宽列数据模型）。
    • 死锁主要由应用层逻辑错误导致，而非高频随机锁竞争。

三、生产环境建议

  1. 优化锁竞争：

    • 对事务访问的键进行排序（避免交叉锁请求）。
    • 使用更细粒度的键设计减少冲突。

  2. 参数调优：

    1
    2
    3
    4
    5
    6
    7
    // 增加锁分片减少竞争
    rocksdb::TransactionDBOptions txn_db_options;
    txn_db_options.num_stripes = 64; // 默认16

    // 缩短超时时间 + 允许重试
    txn_options.lock_timeout = 100;  // 100ms
    txn_options.deadlock_detect_retries = 2;

  3. 监控与告警：

    • 监控指标：rocksdb.deadlock_retries、rocksdb.lock_timeouts
    • 日志分析：定期扫描 LOG 文件中的 Timeout waiting for lock 条目。

四、锁分片设计（Lock Sharding）详解

1. 锁分片的核心思想

锁分片是一种 通过哈希将锁资源分散到多个独立组（分片）中以减少竞争 的并发控制技术。RocksDB 的锁管理器（TransactionLockMgr）通过分片设计，将所有的键（Key）分配到多个分片中，每个分片独立管理自己的锁集合。
这种设计的核心目标是 减少多线程访问锁时的竞争开销，从而提升高并发场景下的吞吐量。

2. 分片设计的具体实现

a. 分片分配逻辑
  • 分片数量：由 TransactionDBOptions::num_stripes 参数控制（默认值：16）。
  • 哈希函数：对 Key 进行哈希运算，将结果模分片数（hash(key) % num_stripes），决定 Key 属于哪个分片。
  • 示例：
    1
    2
    3
    4
    5
    // 初始化分片式锁管理器
    rocksdb::TransactionDBOptions txn_db_options;
    txn_db_options.num_stripes = 64; // 分片数设为64
    rocksdb::TransactionDB* txn_db;
    rocksdb::TransactionDB::Open(options, txn_db_options, "/data", &txn_db);
b. 分片锁表结构

每个分片包含一个独立的锁表（LockMap），其数据结构如下：

1
2
3
4
struct LockMapStripe {
  std::mutex stripe_mutex;           // 分片级互斥锁
  std::unordered_map<std::string, LockInfo> keys; // Key到锁信息的映射
};
  • 锁表操作：
    当一个事务尝试获取 Key 的锁时：
    1. 计算 Key 所属分片（stripe_idx = hash(key) % num_stripes）。
    2. 获取对应分片的 stripe_mutex。
    3. 在分片锁表中检查该 Key 的锁状态：
      • 若未被锁定，则记录事务持有锁。
      • 若已被其他事务锁定，则进入等待队列或触发超时。

3. 超时检测机制

a. 分片级超时检测（非逐 Key 检测）

RocksDB 不会为每个 Key 单独维护超时检测槽，而是通过以下方式实现超时控制：

  1. 事务级超时计时：每个事务在请求锁时记录起始时间戳。
  2. 分片锁检查：当其他事务尝试获取同一分片中的锁时，若发现锁被占用且超时，则触发回滚。
  3. 被动超时触发：没有独立的后台线程主动扫描超时，依赖后续事务的锁请求驱动检测。
b. 超时检测示例
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
// 事务尝试获取 Key 的锁
Status TransactionLockMgr::TryLock(Transaction* txn, const std::string& key) {
  int stripe_idx = hash(key) % num_stripes_;
  LockMapStripe& stripe = lock_map_[stripe_idx];
  
  std::lock_guard<std::mutex> lock(stripe.stripe_mutex);
  auto it = stripe.keys.find(key);
  if (it != stripe.keys.end()) {
    // 检查锁是否超时
    if (Now() - it->second.acquire_time > txn_options_.lock_timeout) {
      // 强制释放超时锁并回滚持有者事务
      it->second.txn->Rollback();
      stripe.keys.erase(it);
    } else {
      return Status::TimedOut();
    }
  }
  // 授予锁
  stripe.keys[key] = LockInfo(txn, Now());
  return Status::OK();
}

4. 分片设计的优势与不足

a. 优势
  • 减少锁竞争：将全局锁竞争分散到多个分片，提高并发性能。
  • 内存高效：无需为每个 Key 单独维护锁结构，分片内哈希表按需扩展。
  • 扩展性：通过调整 num_stripes 适应不同规模的硬件（CPU核心数、并发线程数）。
b. 不足
  • 哈希冲突：不同 Key 可能落入同一分片，仍可能引发竞争。
  • 无全局死锁检测：分片隔离导致无法跨分片检测死锁环。
  • 被动超时机制：依赖后续事务触发超时回滚，可能延迟死锁解除。

5. 分片参数调优建议

场景 优化建议
高并发写入 增大 num_stripes（如设为 CPU 核心数的 4 倍）以降低分片内竞争。
长事务占比高 增加 lock_timeout 避免误杀，但需权衡系统响应速度。
Key 分布不均匀 使用更均匀的哈希函数（如 XXH3）减少分片负载倾斜。

6.总结

  • 锁分片设计：通过哈希将锁资源分散到多个分片，是 RocksDB 实现高并发事务的核心优化，但并非为每个 Key 单独维护锁状态。
  • 超时检测：依赖被动触发而非主动扫描，牺牲了死锁处理及时性以换取更高吞吐。
  • 调优方向：合理配置 num_stripes 和 lock_timeout，结合业务负载特征平衡性能与可靠性。