lightning mdb 源代码分析(5)-事务控制

本博文系列前面已经探讨了LMDB的系统架构、MMAP映射、B-Tree操作等部分,本文将尝试描述LMDB中的事务控制的实现。

事务的基本特征:

事务是恢复和并发控制的基本单位。它是一个操作序列,这些操作要么都执行,要么都不执行,它是一个不可分割的工作单位。

事务是数据库维护数据一致性的单位,在每个事务结束时,都能保持数据一致性。

事务应该具有4个属性:原子性、一致性、隔离性、持久性。这四个属性通常称为ACID特性

原子性(atomicity)。一个事务是一个不可分割的工作单位,事务中包括的诸操作要么都做,要么都不做。

一致性(consistency)。事务必须是使数据库从一个一致性状态变到另一个一致性状态。一致性与原子性是密切相关的。

隔离性(isolation)。一个事务的执行不能被其他事务干扰。即一个事务内部的操作及使用的数据对并发的其他事务是隔离的,并发执行的各个事务之间不能互相干扰。

持久性(durability)。持久性也称永久性(permanence),指一个事务一旦提交,它对数据库中数据的改变就应该是永久性的。接下来的其他操作或故障不应该对其有任何影响。

LMDB中的实现基本思路:

Atom(A):LMDB中通过txn数据结构和cursor数据结构的控制,通过将脏页列表放入dirtylist中,当txn进行提交时再一次性统一刷新到磁盘

中或者abort时都不提交保证事务要不全成功、要不全失败。对于长事务,若页面spill到磁盘,因为COW技术,这些页面未与整棵B-Tree的root

page产生关联,因此后续的事务还是不能访问到这些页面,同样保证了事务的原子性。

其数据就是一致的,不存在因为多线程同时写数据导致数据产生错误的情况。

Isolation(I):事务隔离通过锁控制(MUTEX),LMDB支持的锁互斥是进程级别/线程级别,支持的隔离方式为锁表支持,读读之间不锁,写等待读完成之后开始,

读等待写完成后开始

Duration(D):LMDB中,没有使用WAL、undo/redo log等技术来保证系统崩溃时数据库的可用性,其保证数据持续可用的技术是COW技术和只有一线程写技术。

假如LMDB或者系统崩溃时,只有读操作,那么数据本来就没有发生变化,因此数据将不可能遭到破坏。假如崩溃时,有一个线程在进行写操作,则只需要判断最后的

页面号与成功提交到数据库中的页面号是否一致,若不一致则说明写操作没有完成,则最后一个事务写失败,数据在最后一个成功的页面前的是正确的,后续的属于

崩溃事务的,不能用,这样就保证了数据只要序列化到磁盘则一定可用,要不其就是还没有遵循ACI原则序列化到磁盘

顺便说一句,因为MMAP技术、只一个写线程的实现方案,所以数据库进行备份时特别简单,只要定期在线热备整个数据库即可完成。同时恢复也将比较快。当然由于

其使用了重用旧页技术,LMDB在恢复时只能恢复到最新状态,不能恢复到任意时刻。

实现方法:

LMDB支持嵌套事务,不期望在子事务完成之前父事务有任何读写操作,这样的话可以避免父子事务之间的数据不一致。

LMDB不支持跨线程事务,一个事务只能属于一个线程,一个线程在任一时刻只能持有一个事务。

mdb_txn_begin:

开启一个事务,根据是否传入父事务判断是否为子事务,根据传入参数判断是否为只读事务。嵌套事务支持只支持一个子事务,且子事务为写事务父事务也必须为写事务,

而且数据库不能为mmap可写方式。事务开启流程:分配内存,设置变量,若为子事务,设置父子相关关联变量并shadow父亲所有cursor以减少IO读取。否则调用renew0完成

最终的事务开启工作。

mdb_txn_abort:

放弃一个事务,有子事务则先放弃子事务,然后调用reset0真正执行结束操作。
mdb_txn_commit:

提交一个事务,有子事务则先提交子事务,若为只读事务,则关闭所有打开的数据库句柄并保持打开状态,然后放弃事务即可,若为可写事务,确定事务状态是否正确,若为error

状态,不可以提交,若不是则根据是否存在父事务进行处理,没有父事务则首先更新数据库的root节点,然后保存可重用空间到freedb以便空间重用,并释放midl空间之后,进行

页面刷新,同步相关环境变量之后释放内存,最后释放写锁,至此没有父事务情况提交完成。若有父事务,则其进行将midl列表与父事务的midl合并,cursor同样合并到父事务中进行

最终关闭,将dirtylist合并到父事务中,相关合并和本事务的变量内存释放完毕之后,子事务提交成功,即子事务主要完成内存释放,其他动作如磁盘刷新等都合并至父事务中一次性完成。

mdb_txn_reset:

放弃一个事务,但是保留句柄,仅对只读事务有效,同样调用reset0进行真正事务结束操作。
mdb_txn_reset0 :

放弃事务的公共代码.首先关闭事务中打开的数据库句柄。若是只读事务,设置事务相关变量即可,若为可写事务,需要关闭所有游标,然后释放midl空间,最后释放写锁。至此事务

关闭完毕。
mdb_txn_renew:

重用一个只读事务句柄,避免一次内存分配,检查是否有严重错误,若有失败,没有的话调用renew0完成。
mdb_txn_renew0:

renew0是renew和begin的公共代码。若是写事务,申请进程间互斥锁,若是读事务,首先检查本线程是否已经有读事务,有不支持返回错误,没有的话,开始申请读表互斥锁,

成功后将线程id记录到读表里面,然后立刻释放读表锁。然后再次确认线程中确有事务。事务(读写)申请成功后,将env的meta页面根据txnid进行切换,轮流使用。

最后再次设定些变量后通知调用者申请成功。
mdb_txn_env:

返回事务关联的env对象

上文解释了LMDB实现事务控制的方式和主要接口方法的基本流程,若实现类似关系型数据库的细粒度事务,则需要更细粒度的锁以及复杂的页面等待队列机制等以保证行锁或表锁

的正确性并最终实现事务控制机制,且在数据库应用时有可能陷入死锁状态,而在LMDB当中,读写锁分开,且进程崩溃时,系统会释放相关内核变量,从而保证要不进程正常,

锁成功释放,要不进程崩溃,系统释放锁,因此数据库永远不会陷入死锁状态,不过若事务在等待写锁,有可能等待较长时间。

希望各位能积极批评指正以及转载。

时间: 2024-10-02 06:42:16

lightning mdb 源代码分析(5)-事务控制的相关文章

lightning mdb 源代码分析(1)

lighting mdb(lmdb) 是一个高性能mmap kv数据库,基本介绍和文档参见symas官网,本文将尝试分析其源代码结构以理解数据库设计的关键技术. 本系列文章将尝试从以下几个方面进行分析. 系统架构(本文) MMAP映射(系列2) B+Tree操作(系列3) 事务管理(系列4) MVCC控制(系列5) 等几个方面进行分析. lmdb是为了改进OPENLADP工程的数据缓存后端数据库(bdb)的一系列设计问题,比如多重缓存设计.锁控制.空间膨胀的问题而研发的一款数据库. 其具备管理简

lightning mdb 源代码分析(4)—MVCC/COW

本博文将描述MVCC和cow技术以及LMDB中如何使用以及实现这两种技术. COW(Copy On Write): COW技术背后的思想是拖延技术,基本方法是假如有多个调用者需要访问的资源,在其初始化的时候是不能区分的,即对于多个调用者来说,这资源就是一样的.这样就可以给每个 调用者一个指向资源的指针即可.这种方法一直持续到调用者需要进行修改所需要访问的资源时,在这个时候,调用者将被分配到一份真正私有的资源拷贝,这样调用者对资源的任意 改动对于其它调用者来说都是不可见的.所有的以上操作对于调用者

lightning mdb 源代码分析系列(3)

本系列前两章已经描述了系统架构以及系统构建的基础内存映射,本章将详细描述lmdb的核心,外存B+Tree的操作.本文将从基本原理.内存操作方式.外存操作方式以及LMDB中的相关函数等几方面描述LMDB中关于B+Tree的使用方式. 介绍 动态查找树主要有:二叉查找树(Binary Search Tree),平衡二叉查找树(Balanced Binary Search Tree),红黑树 (Red-Black Tree ),B-tree/B+-tree/ B*-tree(B~Tree).前三者是典

lightning mdb 源代码分析(2)

本系列前一篇已经分析了lightningmdb的整体架构和主要的数据结构.本文将介绍一下MMAP原理以及lmdb中如何使用它. 1. Memory Map原理 内存映射文件与虚拟内存有些类似,通过内存映射文件可以保留一个地址空间的区域,同时将物理存储器提交给此区域,只是内存文件映射的物理存储器来自一个已经存在于磁盘上的文件,而非系统的页文件,而且在对该文件进行操作之前必须首先对文件进行映射,就如同将整个文件从磁盘加载到内存.由此可以看出,使用内存映射文件处理存储于磁盘上的文件时,将不需要由应用程

[Android]Fragment源代码分析(三) 事务

Fragment管理中,不得不谈到的就是它的事务管理,它的事务管理写的很的出彩.我们先引入一个简单经常使用的Fragment事务管理代码片段: FragmentTransaction ft = this.getSupportFragmentManager().beginTransaction(); ft.add(R.id.fragmentContainer, fragment, "tag"); ft.addToBackStack("<span style="f

HBase源代码分析之HRegion上MemStore的flsuh流程(二)

继上篇<HBase源代码分析之HRegion上MemStore的flsuh流程(一)>之后.我们继续分析下HRegion上MemStore flush的核心方法internalFlushcache().它的主要流程如图所看到的: 当中.internalFlushcache()方法的代码例如以下: /** * Flush the memstore. Flushing the memstore is a little tricky. We have a lot of updates in the

Hadoop源代码分析

关键字: 分布式云计算 Google的核心竞争技术是它的计算平台.Google的大牛们用了下面5篇文章,介绍了它们的计算设施. GoogleCluster:http://research.google.com/archive/googlecluster.html Chubby:http://labs.google.com/papers/chubby.html GFS:http://labs.google.com/papers/gfs.html BigTable:http://labs.googl

转:RTMPDump源代码分析

0: 主要函数调用分析 rtmpdump 是一个用来处理 RTMP 流媒体的开源工具包,支持 rtmp://, rtmpt://, rtmpe://, rtmpte://, and rtmps://.也提供 Android 版本. 最近研究了一下它内部函数调用的关系. 下面列出几个主要的函数的调用关系. RTMPDump用于下载RTMP流媒体的函数Download: 用于建立网络连接(NetConnect)的函数Connect: 用于建立网络流(NetStream)的函数 rtmpdump源代码

Raid1源代码分析--读流程

我阅读的代码的linux内核版本是2.6.32.61.刚进实验室什么都不懂,处于摸索阶段,近期的任务就是阅读raid1的源码.第一次接触raid相关的东西,网上分析源码的资料又比较少,不详细.逐行阅读代码,做了笔记.如果要对raid1的读流程有个整体上的把握,需要将笔记中的主线提炼出来,这里不写了.理解不足或者有误之处,希望批评指正. 读流程主要涉及以下函数: 请求函数make_request 读均衡read_balance 回调函数raid1_end_read_request 读出错处理rai