总体结构¶
根据总体介绍文档,tair 是一个分布式的 key-value 存储系统,并且支持不同存储引擎的体系结构,但系统同时只能
用一种存储引擎。整个系统主要包括了 cong_server 模块,data_server 模块,storage 模块以及其他公用的模块
等。其中 cong_server 是做为元数据管理的服务器,代码主要在 cong_server 目录中,主要管理数据的分布和复
制,以及迁移;data_server 是数据存储的节点,代码在 data_server 目录,主要和不同存储引擎交互,管理数据的
操作;storage 是实现了不同存储引擎,代码在 storage 目录,主要是根据存储引擎接口,实现了两种存储引擎。
config_server¶
cong_server 模块主要包括 cong_server 目录。实现了从配置文件中 load 进节点的信息,然后根据配置的数据分
布的桶的数量和需要建立的数据的备份数,建立一张数据的分布表。该表其实是一个数组,元素为数据存储的节点的
信息,长度为桶数乘以数据的备份数。比如,现在有 1023 个桶,备份数是 3,那就是一个长度为 1023 * 3 数组。其
中前 1023 个数组元素就是数据要存储的主节点信息,数组下标就是相应的桶号。后面 1023*2 个元素就是数据存储
的备份节点信息。这样就是说一个主节点对应了两个备份节点,比如在前 1023 个元素中,有一个下标为 2 的元素,
说明该桶号是 2,该元素就是桶 2 的主桶所在的节点信息,那么 1023*1+2 和 1023*2+2,这两个下标所对应的元素
就是桶 2 的备份桶所在节点信息。同时,为了负载均衡,主桶会尽量均匀分布到所有节点上。备份桶分布可以根据不
同策略分布,主要是根据不同的数据中心,或者不同位置的来分布。不同位置主要指主桶和备份桶不能在同一节点上
(当然这里可能在同一的物理机器上)。不同的数据中心主要指必须有一份数据是在异地的数据中心,这个主要为了
容灾的需要,当一个机房停电或者失火等,系统仍能继续服务。其他 cong_server 还负责对数据节点故障检测,主
要通过心跳来确定数据节点的状态,但数据节点发生变化(比如增加服务器),就会把前面所描述的数据分布表发送
给数据节点。同时数据节点通过心跳来上报一些统计信息等数据。
data_server¶
data_server 为数据节点提供服务,主要处理客户端的请求,还支持了数据的复制,根据前面所描述的数据分布表,
会把负责的主桶的数据发送到对应的备份桶所在节点。同时为了支持迁移,比如当数据节点发生变化,需要迁移出或
者迁移进数据,迁移以桶为单位。迁移过程是先迁移原先数据,在迁移过程中的产生的更新,进行日志记录,然后在
不加锁的情况下,进行日志的 redo;当还需要 redo 的日志比较少时候,会加锁,把剩下的日志 redo 完成,然后通
知 cong_server,该桶已经迁移完成。
storage 模块¶
这里主要实现两种存储引擎,其中 mdb 目录中实现了内存型的存储引擎,fdb 目录中实现持久化的存储引擎。存储引
擎的基本接口定义在 storage_manager.hpp。mdb 主要是使用在需要 cache 的系统中,为了减少系统 down 的影
响,采用共享内存的方式,这样当系统 down 后,重新启动后数据还存在。fdb 是采用类似 Tokyo Cabinet 实现方式,
但这里为了性能考虑,会把索引和数据分文件存放,同时把索引文件放在内存中(在部署文档中可以看到可以配置大
小)。
plugin¶
tair 支持热插拔的插件式服务,可以开发自己的插件,然后通知 cong_server,需要支持这个插件,让节点进行
load。比如在需要一些性能统计信息时候,你可以需要的时候进行启动统计信息插件,让节点进行一定数据统计,并
记录到一定的地方,到不在需要的时候,可以让该插件停止。