Tair是一个高性能、分布式、可扩展、高可靠的NoSQL存储系统。本文基于Tair v3.1.2.43版本，探究其mdb存储引擎的实现。
Tair目前有mdb、ldb和rdb等存储引擎。其中mdb是Tair最早的一款内存型产品，也是在公司内部应用最广泛的集中式缓存。特别适用容量小（一般在M级别，50G之内），读写QPS高（万级别）的应用场景。由于是内存型产品，因此无法保证数据的安全性，对数据安全有要求的应用建议在后端加持久化数据源（例如MySQL）。本文接下来详细讨论Tair mdb存储引擎的实现。
Tair的存储引擎接口是src\storage\storage_manager.hpp里的虚基类storage_manager。所有的Tair存储引擎均继承实现了storage_manager这个虚基类。src\dataserver\tair_manager.cpp文件中的tair_manager::initialize函数根据配置文件中storage_engine的设置初始化相应的存储引擎。
最近一直在忙毕设的事情，博客都快被遗忘了。最近正好在研究sigslot库，索性晚上写点源码分析的水文充充数。
言归正传，sigslot是一个用标准C++语法实现的信号与槽机制的函数库，类型和线程安全。提到信号与槽机制，恐怕最容易想到的就是大名鼎鼎的Qt所支持的对象之间通信的模式吧。不过这里的信号与槽虽然在概念上等价与Qt所实现的信号与槽，但是采用的仅仅是标准C++语法，不像Qt采用了扩展C++语言的方式（Qt需要使用moc工具对代码预处理之后，才能由标准的C++编译器进行编译）。
众所周知，C++是一门特性众多的语言，其支持多种编程范式。虽然C++在一定程度上支持OOP编程，但是C++这种“静态消息机制”的语言一直没有实现对象级别的delegate机制，而C++之父Bjarne主张的“库扩展胜于语言扩展”的做法使得各种解决方案层出不穷。除了信号与槽机制，C++11正式加入的std:bind/std::function组合也提供了优秀的解决方案。这里所说的信号与槽机制也是一种对象间通信的机制，具体的讨论也可以看看sigslot相关介绍中的内容。
sigslot主页: http://sigslot.sourceforge.net
sigslot文档: http://sigslot.sourceforge.net/sigslot.pdf
sigslot库的用法文档中已然很明了了，所以在这里就不赘述了。接下来我们看看这个库的实现。源码分析的方法有很多种，具体到库代码的分析的方法，我喜欢的是先研究库的功能，直到能写出一个demo程序为止。研究一个库的前提是你得会用它，熟悉它的接口。读完文档，很容易就写出了下面的测试代码：
我们假定读者掌握了：
我们谈什么，不谈什么：
可以先行阅读的参考资料：
进程眼中的线性地址空间
线程眼中的线性地址空间
Linux线程的前世今生
聊聊内存管理
Linux系统调用
goroutine背后的系统知识
这篇文章我们聊聊内存管理。
本来我想不针对于任何具体的操作系统来谈内存管理，但是又觉得不接地气、言之无物。所以我决定在阐述概念的同时，还针对 x86 Linux 下的内存管理做简要的介绍，并且以实验来证明结论。以下内容分拆为几个大标题和小节，内容前后承接。
首先，什么是物理地址空间？我们知道 CPU 与外部进行信息传递的公用通道就是总线，一般而言，CPU 有三大总线：控制总线、数据总线、地址总线。这三类总线在一定程度上决定了 CPU 对外部设备的控制和数据传送能力。其中地址总线决定了 CPU 能向外部输出的地址宽度，也就是 CPU 的寻址能力。
通过 /proc/cpuinfo 可以查看具体的数据：
