前言
数据库最核心的功能是把数据存储下来，并提供快速读、写能力，因此，对于一个数据库来说，数据的读写是最基础而重要的业务。
但数据的读写在数据库实际使用中数以亿计的请求的情况下，还要做到不出任何的数据错乱，这就很考验数据库的数据读写设计。针对数据库在读写中可能出现的诸如读写互相干扰的问题，TcaplusDB的设计开发人员设计了TcaplusDB的数据读写逻辑。
TcaplusDB的读写逻辑
单Shard的数据组织形式就是一张Hash表，同一个Hash桶中的数据又是以一棵AVL树的形式组织。
数据的读写过程类似于内存中Hash表的读取过程，区别在于这里的Hash表是要持久化到文件，而磁盘IO的效率远不及内存，如何保证在主要的场景下这些存储在文件中的数据访问效率最优化，就是数据存储引擎要考虑的主要问题。
一条数据写入到数据文件的过程
本节主要讲述数据的插入（Insert）过程，当然数据的写操作还包括修改（Update）和替换（Replace）。
- 首先通过Hash算法，计算得到数据的Hash桶号，数据将会插入到对应Hash桶中。这个桶是逻辑上的概念，同一个桶中的数据，并不意味着它们一定会集中存储在磁盘上的某个位置。桶号 = hash(数据Key) % 桶数。
- 对Hash桶加锁。由于写数据的过程中涉及到检查数据是否已存在和修改桶中的数据组织结构，通过加锁可以防止这个过程因为并发而出现数据不一致等问题。
- 在Hash桶中搜索（搜索的过程参考AVL树算法描述）是否已经存在与待插入数据Key值相同的数据，如果存在，则直接结束插入流程，并提示数据已存在。如果不存在，则开始写数据到数据文件中。
- 数据引擎为新数据分配存储空间，由于数据的Key和Value在内容和使用上都较大的区别，为了尽可能的保证数据的访问效率，Key和Value的存储空间是分开分配的，而且分配策略上也略有不同。
存储空间分配的基本策略
- 优先使用数据文件的前1G的空间。原因是存储引擎启动时，会将数据文件的前1G空间通过mmap映射到内存中，访问效率较高，而剩余的空间中数据是直接对接文件IO的方式访问的；
- 数据的Key比数据的Value更有权利优先使用前1G的空间。原因是通常情况下Key的访问频率要比Value高。当前1G空间中原先分配给Key使用的空闲块不足时，会将前1G空间中原先分配给Value使用的空闲块挪给Key使用；
- 所有数据的Key尽量存放在一起。这是因为我们有很多Key遍历的场景（比如数据迁移），Key放在一起，可以一定程度上加快遍历的过程，减少磁盘IO；
- 空闲块的查找策略为Best-Fit，即找满足需求的最小空闲块，目的是为了尽可能的让数据存在同一块中，避免数据的Split。
存储空间的详细分配过程参见下图（下图拆分成了两个部分，两幅图通过虚线框的”尝试从文件空间分配“节点联系在一起）：
存储空间详细分配过程图
从文件空间中分配图
策略设计的考虑
存储引擎根据空间分配策略，会先分配数据Value的存储空间，写入数据Value部分后，再分配数据Key的存储空间，并写入数据Key部分。之所以是这样的顺序，有两方面的原因：
- 数据Key的头部需要记录它所指向的Value的存储地址，需要先分配Value的存储空间，得到Value的存储地址头，再写Key；
- 数据访问入口是Key，按照这个顺序，Key写成功，我们也基本可以认为Value也是写成功了，可以减少数据不一致的情况。
从前面的内容，我们也了解到，数据的Key，在写入文件的时候，会有头部信息，里面会记录数据在AVL树中的左右子树节点的信息，当插入新数据的时候，因为树节点的关系会发生变化，因此会涉及其它数据Key头部信息的修改，这个过程与新数据的插入是一起完成的。写数据的最后一步就是写Binlog文件，Binlog记录当前数据的最后的状态，主要用于主备节点的数据同步等场景。
一条数据从数据文件读出的过程
相比数据的写入过程，数据的读取过程要简单一些：
- 首先和写入数据一样，要找到存储要查找的数据的Hash桶，Hash桶号的计算方法，与写入数据完全一致。
- 在Hash桶内，执行AVL树的搜索过程，查找找指定的Key，如果没找到，直接返回，并提示数据不存在，如果找到，读取Key，并从Key的头部信息中找到Value的存储位置，将Value一并读取。
最后
我们已经了解了 TcaplusDB 的数据读写逻辑，后续我们将揭开更多TcaplusDB设计的特殊奥秘。