lmdb简介
lmdb是openLDAP项目开发的嵌入式（作为一个库嵌入到宿主程序）存储引擎。其主要特性有：
- 基于文件映射IO（mmap）
- 基于B+树的key-value接口
- 基于MVCC（Multi Version Concurrent Control）的事务处理
- 类bdb（berkeley db）的api
实现
底层读写的实现
lmdb的基本思路是使用mmap访问存储，不管这个存储实在内存上还是在持久存储上。
lmdb的所有读取操作都是通过mmap将要访问的文件只读地装载到宿主进程的地址空间，直接访问相应的地址，这减少了硬盘、内核地址控件和用户地址空间之间的拷贝，也简化了平坦的“索引空间”上的实现，因为使用了read-only的mmap，规避了因为宿主程序错误将存储结构写坏的风险。IO的调度由操作系统的页调度机制完成。
而写操作，则是通过write系统调用进行的，这主要是为了利用操作系统的文件系统一致性，避免在被访问的地址上进行同步。
基于MVCC的存储引擎
我们在前面提及，lmdb上的读取操作，直接读取了mmap所装载的内存地址，那么，如果所读取的内容被修改了，不是出现了不一致的结果吗？事实是，lmdb上的所有内容都不会被修改。
lmdb用MVCC处理并发读写访问的问题。其要点在于：
- 每一个变更对应一个版本
- 变更发生的时候不修改原来的版本
- 读者进入的时候会取得一个版本，它只读取这个版本的内容
对于一个树形数据结构，当它的一个节点上发生变更的时候，就创建一个新的节点，在新的节点上容纳这些变更，由于这个节点的父节点也要发生变更（从指向原来的节点变更为指向新的这个节点），那么重复上述过程，即，实际发生变更的节点通往根节点路径上的所有节点都必须重新创建一份，当变更工作完成的时候，我们通过一个原子操作提交这个变更版本。大体是这样一个过程：
如上图所示，每个新的版本就会产生一个新的跟节点，按照上述处理，最终的存储中就会保留历史上所有的版本，当然，所有版本中就包括了当前所有读者所读的版本，因此，变更不会对读者产生任何影响，所以，写可以不被读阻塞。
上面，我们讨论了读的情况，上述方法承诺给每一个读一个一致的版本（就是它进入时所得到的那个版本），但没有承诺给它一个最新的版本，我们考虑在一个事务中，依据一个值变更另一个值的情况，很显然，当我们想要提交变更的时候，很可能我们进入时所得到的版本已经不是最新的，也就是说，在我们的进入和提交之间发生了另一个提交，这种情况下，如果提交了变更就会发生不一致的状况，譬如一个单调递增的计数器，就因此可能“吃掉”多个递增。为了解决这个问题，我们只要在提交时检查我们进入的版本是否最新版本即可，这常常可以通过一个CAS原子操作完成，如果这个操作失败，就重新进入存储，重做整个事务。这样，读也可以不被（可能的）写阻塞。
按照上述描述，我们的存储中保存了所有的历史版本，这是否必要呢？事实上，我们所以保存历史版本，是因为有可能有读者读它，新的读者总是读到最新的版本，老的版本就没有用了，如果一个版本上没有任何读者（和写者），那它就没有必要存在了。我们可以依据上述原理实现旧版本的回收，不过lmdb做了一些改进：
- 一个基本的事实是，新的读者总是去读最新的版本，因此，保留所有版本的根节点是不必要的，我们只需要保存一个最新版本的根节点和一个用于提交更加新的变更的节点即可。
- 所有读者进入的时候，都复制当前的根节点的一个snapshot（因为它随后很可能被改变）
- 当一个变更被提交的时候，它清楚因为这个提交，哪些节点迟早会变成没用的---所有因为这次变更发生过修改的节点，都会在相应版本的读者退出后变成无用的节点，因此可以回收
- 因为上述理由，最新的版本可以收集所有需要被回收的节点和它们所属的版本
- 维护一个读者的slot，可以从这里面查到最小的版本，比这个版本小的版本所属的可回收节点都可以进行回收
如上所述，我们现在只有两个根节点，所有变更最终都要修改这个根节点，这样，所有的写事实上要被序列化。这并没有降低性能，理由是这样的，如我们上面所述的，当两个变更并发进行的时候，确切的说，是进入同一个版本，并依据这个版本进行了某些变更，然后要提交这些变更，两者中必有一个事务必须重做，因为在它的提交和进入之间有别的提交，这个结论可以推广到多个并发的情况。也就是说，变更事实上是序列化的，由于不同的变更之间没有阻塞，MVCC的方案消耗了更多的计算资源（所有失败的提交都要被重做）。因此，lmdb用一把锁序列化了所有的变更操作。
以上就是lmdb实现中大部分要点。
