【Rocksdb实现分析及优化】事务之Pessimistic ①

【Rocksdb实现分析及优化】事务之Pessimistic ①本文源自:https://kernelmaker.github.io/Rocksdb_transaction_1之前对Rocksdb都是关于它主体实现的介绍,最近在看他的事务实现,还没全看完,打算边看边记录,用几篇博客详

【Rocksdb实现分析及优化】事务之Pessimistic

本文源自:https://kernelmaker.github.io/Rocksdb_transaction_1

之前对Rocksdb都是关于它主体实现的介绍,最近在看他的事务实现,还没全看完,打算边看边记录,用几篇博客详细写一下Rocksdb Transaction相关的原理及实现。这一篇先不展开细节实现,简单介绍一下它的Pessimistic Transaction。

1. Pessimistic vs Optimistic

Rocksdb的事务实现包括Pessimistic(悲观)和Optimistic(乐观)。

Pessimistic transaction会在进行的过程中,当需要对某个key做Write操作时,首先对其加行锁,确保这个key在Commit或Abort之前不会被其他并行事务修改,然后在最终Commit或Abort后对所有行锁进行释放。当并发事务较高,并且事务间执行Write操作的key重叠度较高时,此时就需要采用Pessimistic transaction通过行锁来实现事务间的操作隔离。当然他的代价就是额外的锁操作。

Optimistic transaction则相反,Commit之前的所有Write操作都不需要加锁,冲突检测会在Commit时来执行,没有冲突则Commit成功,有冲突则Commit失败。当并发事务之间Write操作的key重叠度较低时,如果采用Pessimistic transaction反而会因为引入额外的锁操作反而降低性能,这里更适合使用Optimistic。Rocksdb默认是Pessimistic。

2. ACID

数据库事务需要满足ACID(Atomic、Consistency、Isolation、Durability)。这些正常应该是MyRocks或者InnoDB关心并实现的特性,而Rocksdb身为MyRocks的基础引擎,没有要求说一定得满足ACID,不过这里我们尝试强行套一下概念,来看看Rocksdb满足了哪些?

  1. Atomic:原子性通过Rocksdb已有的WriteBatch就可以实现,事务在Commit之前所有的Write操作都只是写到WriteBatch当中,在最终Commit时只需要如下一个Write(…)即可:
Status WriteCommittedTxn::CommitWithoutPrepareInternal() {
  Status s = db_->Write(write_options_, GetWriteBatch()->GetWriteBatch());
  return s;
}
  1. Consistency:一致性似乎不需要Rocksdb做什么,应该是MyRocks需要解决的事情;
  2. Isolation:隔离性通过行锁、Snapshot配合来实现,一会下面单独说;
  3. Durability:持久性,这个比较尴尬,我翻看代码,并没有看到上面Commit时Write调用传入的WriteOptions::sync被打开,也就是WAL走的是默认的刷盘策略(前面的博客有介绍),在机器掉电时会有丢失的可能。这就需要使用者在BeginTransaction时,将传入的WriteOptions中的sync手动设置为true;

可以看到Rocksdb的Transaction已经基本实现了AID;

3. 怎么用

Pessimistic transaction怎么用,和普通的事物一样,一开始需要TransactionBegin,最后需要Commit或者RollBack。下面看几个例子:

  1. 打开DB:
Options options;
TransactionDBOptions txn_db_options;
options.create_if_missing = true;
TransactionDB* txn_db;

Status s = TransactionDB::Open(options, txn_db_options, kDBPath, &txn_db);
assert(s.ok());
  1. 开启事务:
Transaction* txn = txn_db->BeginTransaction(write_options);
assert(txn);
  1. 读写:
// 在事务中读取一个key
s = txn->Get(read_options, "abc", &value);
assert(s.IsNotFound());

// 在事务中写一个key
s = txn->Put("abc", "def");
assert(s.ok());

// 在事务外读取一个key
s = txn_db->Get(read_options, "abc", &value);

// 在事务外写一个key
// 这里并不会有影响,因为写的不是"abc"
// 如果是"abc"的话
// 则Put会一直卡住直到等待事务Commit或者超时(本例中会超时)
s = txn_db->Put(write_options, "xyz", "zzz");
  1. 提交:
s = txn->Commit();
assert(s.ok());
  1. 析构事务:
delete txn;
  1. 最后析构DB:
delete txn_db;

4. Isolation

一般数据库事务隔离级别从弱到强分为:

  1. Read Uncommited:最弱的隔离级别,对读操作不加锁,对写加锁,会造成脏读
  2. Read Commited:读的时候加读锁,读完立刻放锁,写的时候加写锁,事务结束后放锁。这样的隔离级别会有不可重复读的问题
  3. Repeatable Reads:读的时候加读锁,事务结束后放锁,写的时候加写锁,事务结束后放锁。因为读锁在加锁后直到事务结束后才释放,所以其他事务无法修改对应key,这样就可以支持重复读,但还会存在幻读(Phantom Reads)问题
  4. Serializable:这事最严格的隔离界别,读的时候对加读锁,事务结束后放锁,写的时候对表加写锁,事务结束后放锁,由于都是对表加锁,所以没有幻读问题

知道了上述隔离级别的基本区别后,我们来看看Rocksdb的Pessimistic transaction在这方面是怎么做的。

  1. PessimisticTransaction的Put 会在一开始对key加写锁,直到事务结束后才释放
  2. PessimisticTransaction的Get 则不会对key加锁,它能读到什么数据完全取决于Options传入的Snapshot

开始看这里代码的时候,心里OS:“什么鬼?Get连锁都没有…”,后来发现还有一个GetForUpdate

  1. PessimisticTransaction的GetForUpdate 则会对key加读锁,直到事务结束后才释放。这个才是在事务中应该使用的读取操作,配合Put的写锁来实现一定程度上的隔离性。同样它能读到什么值也要取决于Options传入的Snapshot

有了Put和GetForUpdate的加锁,我们对比上面列出的隔离界别实现原理,可以发现:

Rocksdb Pessimistic Transaction的隔离界别是Repeatable Reads(当然也不可能是Serializable,一是因为Rocksdb暴露的接口不会造成幻读,所以不需要一把大锁来强行Serialize,二是Rocksdb也没有表的概念)

我们发现,Rocksdb对于加锁的时机是在需要读写某个key之前才加锁,这样的方式可以满足绝大多数的事务隔离场景,当然在有些极端场景下,用户希望在事务一开始就对所有接下来需要读写key加锁,直到事务结束后再释放。这个该如何实现呢?

要实现这个,有一个需要解决的问题:

无法在事务一开始就知道接下来要读写哪些key,所以无法提前对它们加锁

Rocksdb通过SetSnapshot来间接解决,BeginTransaction后,用户可以立刻调用SetSnapshot,这样该事务会记录当前DB的最新Sequence,然后再接下来事务的每一次Put操作时,会检查DB中该key的最新Sequence是否大于事务之前记录的Sequence,如果大于,则证明事务外部有对该key做了写操作,那么事务对应的Put则会返回失败。

可以看到,在这里Rocksdb采用相对乐观的处理方式,通过对Snapshot来取代提前对所有需要的key加锁,不过这样的处理方式可能会造成事务最终失败(事务外部修改某个key后会导致接下来事务内部修改失败)。

前面总说事务外部读写,这里除了其他事务可能读写外,也有可能是用户直接使用DB接口来读写,也就是:TransactionDB::Put和TransactionDB::Get,具体实现中也是将它们当成一个独立的事务(只有一条操作Put或Get)来处理。

5. 其他

看代码中发现一些有趣的功能:

  1. WriteBatchWithIndex:事务的Get和GetForUpdate操作可以读取到本事务中之前写过但还没有写入到DB中(未Commit)的最新值,具体实现就是通过WriteBatchWithIndex,它其实就是在WriteBatch基础之上加一个关于index的skiplist,这样就Get时可以在读Memtable之前先读在WriteBatch中查查看有没有最新写入。这个不止可以在Transaction中用,Rocksdb把它暴露了出来,如果在使用Rocksdb的时候有中途在WriteBatch里查找key的需求,就可以使用。
  2. SetSavePoint & RollbackToSavePoint:在事务的进行中,可以随时调用SetSavePoint来打记录点,然后在接下来可以随时回滚到上次打的记录点上。具体实现就是在SetSavePoint是记录一下事务的状态信息(如snapshot、num_puts、num_deletes、num_merges)以及对WriteBatch设置记录点(Record个数,rep当前size),然后在Rollback时恢复他们即可。
  3. 所有的锁操作默认不会无限卡死等待,会有超时时间,超时后将错误返回给用户来处理,这样更为合理。另外如果需要的话,可以开启事务Options的detect_deadlock_来强制在加锁前进行死锁检测

6. 总结

PessimisticTransaction就是一个事务的标准实现,之后再细扣下实现细节,以后提到事务的时候终于不再只是理论上的谈谈了,有了实践体会会更深。

日常PS:DB全局递增Sequence之前觉得不起眼,谁都能想到的东西,现在来看感觉真是一个NB的设计,大大简化了Snapshot和Transaction的实现。

今天的文章【Rocksdb实现分析及优化】事务之Pessimistic ①分享到此就结束了,感谢您的阅读。

版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。
如需转载请保留出处:https://bianchenghao.cn/68025.html

(0)
编程小号编程小号

相关推荐

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注