rosedb 事务实践
一、前言
事务是传统关系型数据库中必不可少的功能,例如 Mysql、Oracle、PostgreSql 都支持事务,但是在 NoSQL 数据库中,事务的概念比较弱化,在实现上也没有关系型数据库那么复杂。
但是为了数据的完整一致性,大多数 k-v 都会实现事务的基本特性,例如 k-v 数据库的两大鼻祖 LevelDB 和 RocksDB,一些 Go 语言实现的开源 k-v 也都支持事务,例如 Bolt,Badger 等。
rosedb 的事务目前刚实现了一个初级的版本,代码还比较简单,只不过在我的预期构思内,后续可能会慢慢演化得更加复杂。
需要说明的是,在实现 rosedb 的事务之前,我对事务的理解也仅限于 ACID 这些基础概念,所以这次实现完全是摸着石头过河,可能存在一些槽点,大家有什么疑问可以指出来,我后面也会继续学习并完善。
二、基本概念
说到事务,就很容易想到事务的 ACID 特性,带大家回顾一下:
原子性(Atomicity):一个事务中的所有操作,要么全部完成,要么全部失败,不会在中间环节结束。如果事务执行过程中发生错误,能够被回滚至事务开始之前的状态。
一致性(Consistency):在事务开始前和结束后,数据库的完整性没有被破坏,这意味着数据状态始终符合预期。
隔离性(Isolation):隔离性描述的是多个执行中的事务相互影响的程度,有常见的四种隔离级别,表示事务之间不同的影响程度:
读未提交(read uncommitted):一个事务还未提交,另一个事务就能看到它所做的修改(存在脏读)
读提交(read committed):一个事务对数据的修改,只能等到它提交之后,其他事务才能看到(没有脏读,但是不可重复读)
可重复读(repeatable read):一个事务在执行过程中获取到的数据,和事务开始时的数据一致(没有脏读,可以重复读,但是有幻读)
串行化(serializable):读写互斥,避免事务并发,一个事务必须等到前一个事务提交后才能执行(无脏读,可重复读,无幻读)
持久性(Durability):一个事务提交之后,它所做的修改是永久的,即使数据库崩溃之后也能够保证安全。
ACID 的概念看起来挺多,但并不难理解,要实现事务,其实就是保证在数据读写时,满足事务的这几个基本概念,其中 AID 是必须保证的。
而 Consistency 即一致性,可以简单理解为它就是事务的最终目标,数据库通过 AID 来保证一致性,而我们在应用层面也要保证一致性,假如我们写入的数据本身逻辑上就是错误的,那么即使数据库事务再完善,也无法保证一致性。
三、具体实现
在讲解事务实现之前,先来看看 rosedb 当中事务的基本用法:
首先还是会打开一个数据库实例,然后调用 Txn
方法,这个方法的入参是一个函数,事务的操作都在这个函数中完成,在提交的时候一次性执行。
像这样使用的话,事务会自动提交,当然也可以手动开启事务并提交,并且在有错误发生时手动回滚,如下:
当然还是推荐第一种用法,省去了手动提交事务和回滚。
Txn
方法表示的是读写事务,此外还有一个 TxnView
方法,表示的是只读事务,使用方式完全一致,只不过在 TxnView
方法内的写入命令都会被忽略。
了解了事务的 ACID 基本概念和 rosedb 事务基本用法之后,再来看看在 rosedb 当中,事务究竟是怎么实现的,也可以认为是如何来保证 AID 特性的。
3.1 原子性
前面已经说到,原子性指的是的事务执行的完整性,要么全部成功,要么全部失败,不能停留在中间状态。
要实现原子性其实不难,可以借助 rosedb 的写入特性来解决。先来回顾一下 rosedb 数据写入的基本流程,两个步骤:首先数据会先落磁盘,保证可靠性,然后更新内存中的索引信息。
对于一个事务操作,要保证原子性,可以先将需要写入的数据在内存中暂存,然后在提交事务的时候,一次性写入到磁盘文件当中。
这样存在一个问题,那就是在批量写入磁盘的时候出错,或者系统崩溃了怎么办?也就是说可能有一些数据已经写入成功,有一些写入失败了。按照原子性的定义,这一次事务没有提交完成,是无效的,那么应该怎么知道已经写入的数据是无效的呢?
目前 rosedb 采用了一种最容易理解,也是比较简单的一种办法来解决这个问题。
具体做法是这样的:每一次事务开始时,都会分配一个全局唯一的事务 id,需要写入的数据都会带上这个事务 id 并写入到文件。当所有的数据写入磁盘完成之后,将这个事务 id 单独存起来(也是写入到一个文件当中)。在数据库启动的时候,会先加载这个文件中的所有事务 id,维护到一个集合当中,称之为已提交的事务 id。
这样的话,就算数据在批量写入时出错,由于没有存放对应的事务 id,所以在数据库启动并取出数据构建索引的时候(回忆一下 rosedb 的启动流程),能够检查到数据对应的事务 id 没有在已提交事务 id 集合当中,所以会认为这些数据无效。
大多数 LSM 流派的 k-v 都是利用类似的思路来保证事务的原子性,例如 rocksdb 是将事务中所有的写入都存放到了一个 WriteBatch 中,在事务提交的时候一次性写入。
3.2 隔离性
目前 rosedb 支持两种事务类型:读写事务和只读事务。只能同时开启一个读写事务,只读事务则可以同时开启多个。
在这种模式下,读会加读锁,写会加写锁,也就是说,读写会互斥,不能同时进行。可以理解为这是四种隔离级别中的串行化,它的优点是简单易实现,缺点是并发能力差。
需要说明的是,目前的这种实现在后面大概率会进行调整,我的设想是可以使用快照隔离的方式来支持读提交或者可重复读,这样数据读取能够读到历史版本,不会造成写操作的阻塞,只不过在实现上要复杂得多了。
3.3 持久性
持久性需要保证数据已经写到了非易失性存储介质当中,比如最常见的有磁盘或者 SSD,这样即使发生系统异常,也能够保证数据安全。
在 rosedb 当中,写入数据时,如果走默认的刷盘策略,是将数据写到了操作系统页缓存当中,实际上并没有落磁盘。如果操作系统还没来来得及将页缓存的数据刷到磁盘,那么会造成数据丢失。这样虽不能完全保证持久性,但性能是相对更好的,因为 Sync 刷磁盘是一次极其慢速的操作。
如果在启动 rosedb 的时候指定了配置项 Sync 为 true,那么每次写入都会强行 Sync,能够保证数据不丢,但是写性能会下降。
实际应该怎么选择,可以根据自己的使用场景来,如果系统稳定,对性能的要求较高,并且能够容忍丢失少量数据,那么可以采用默认策略,即 Sync 为 false,否则可以强制刷盘。
四、缺陷
经过上面的简单分析,可以看到 rosedb 已经基本实现了事务的 AID 特性,整体来说还是挺简单的,易于学习和使用,并且能够很好理解便于进一步的扩展。当然,目前也存在一些缺陷亟待解决。
第一个便是上面提到的隔离级别的问题,目前这种方式太过简单,使用一把全局大锁搞成了串行化,后续可以考虑只锁定需要操作的某个 key,减小锁的粒度。
还有一个问题便是,由于 rosedb 支持了多种数据结构,但是像 List、ZSet 这种结构,在事务中支持全部命令的难度较大,因此目前 List 只支持了 LPush 和 RPush,ZSet 只支持了 ZAdd、ZScore、ZRem 命令。
主要的原因是如果在事务中对已经存在的 key 进行读写,那么去支持像范围查找这种类型的命令就会很困难,目前我还没有想到比较好的解决方案。
最后,附上项目地址:https://github.com/roseduan/rosedb,欢迎各位前来围观吐槽。
Ps:rosedb 也欢迎对存储、k-v 感兴趣的朋友加入,也可加我微信进行深入探讨交流。
版权声明: 本文为 InfoQ 作者【roseduan】的原创文章。
原文链接:【http://xie.infoq.cn/article/eacba325d574581a78279c902】。文章转载请联系作者。
评论