StoneDB 源码解读系列｜Tianmu 引擎工具类模块源码详解（一）

StoneDB 源码解读系列文章正式开启，预计以周更的形式跟大家见面，请多多支持~

本篇源码解读内容已进行直播分享，可在视频号观看直播回放，也可点击阅读原文跳转至 B 站观看回放视频。

PPT 内容可在社区论坛中查看下载：https://forum.stonedb.io/t/topic/89

各个工具类属于 Tianmu 引擎的核心组件，这些组件可以说是 Tianmu 的基石，由于工具类的范围广，在源码解读系列中会挑选主要的一些跟大家做分享，包括：日志系统、异常处理、堆栈跟踪、线程池、内存管理、数据压缩/解压缩等。本篇内容主要分享前面四点。

源码结构

众所周知大型项目会有巨量的代码，为了方便管理和维护，一般开发人员会根据功能模块对源代码划分为不同的目录，所以在分析大型项目时首先要知道项目中每个目录的作用是干什么的，然后再根据自己的需求去对应的目录解读对应的代码。

1. StoneDB 源码目录结构

2. Tianmu 引擎的源码目录结构

Tianmu 引擎的日志系统

Tianmu 引擎的日志类型分为了三类，系统日志、调试日志、和查询引擎执行的结果日志。其中系统的异常信息、异常情况的堆栈信息 和一些计时信息都记录在系统日志里面。系统运维和开发人员可以通过日志了解服务器软硬件信息、检查配置过程中的错误及错误发生的原因。经常分析日志可以了解服务器的负荷，性能安全性，从而及时采取措施纠正错误。

下图为 Tianmu 引擎的日志系统结构关系图：

1. 日志系统

系统日志把日志分为了以下 7 个级别 ：

使用枚举类型表示各个级别

enumLogCtl_Level {     DISABLED = 0, FATAL = 1, ERROR = 2, WARN = 3, INFO = 4, DEBUG = 5, TRACE = 6 };

并支持将 MySQL 日志级别映射到 Tianmu 日志级别,可以通过 设置参数 tianmu_global_debug_level 来控制日志的输出级别：

日志的级别越高输出的信息就越多，当然详细的日志信息会影响系统的运行性能，需要视情况而定。

Tianmu 的系统日志会统一落地到 MySQL 安装目录下/log/tianmu.log 文件

日志系统核心类：

class utils:: LogCtl

2. 调试日志

调试日志落地到 mysql 安装目录下/log/trace.log 文件。

由 tianmu_control_trace 该配置项控制，为 1 打开记录日志的开关，为 0 则关闭

调用接口对象：

system::Channel rccontrol

3. 查询引擎执行的结果日志

查询引擎执行的结果日志落地到 StoneDB 安装目录下/log/ query.log 文件。

由 tianmu_ini_controlquerylog 该配置项控制，为 1 打开记录日志的开关，为 0 则关闭

调用接口对象：

system::Channel rcquerylog

堆栈跟踪

保存堆栈的相关信息（堆栈的函数调用和堆栈的符号信息等），方便后续调试和问题排查，目前 Tianmu 系统基于异常处理模块加上了堆栈信息的记录，如果有异常情况出现，就会把现场的堆栈信息记录下来。堆栈的调用信息会以 WARN 级别的日志信息记录在 Tianmu 的系统日志里面，日志所在的目录：StoneDB 安装目录下/log/tianmu.log 文件中。

其中为了获得堆栈信息，Tianmu 这里使用了 glibc 中提供的 backtrace()和 backtrace_symbols() 两个函数来输出和解析程序的 call stack，并使用 g++ 中的 abi::__cxa_demangle 来 demangle（将 C++ ABI 标识符(C++ ABI identifier)转换成 C++源程序标识符(original C++ source identifier)的过程称为 demangle。更简单的说，识别 C++编译以后的函数名的过程，就叫 demangle。）

调用函数接口：

GetStackTrace();

异常处理

Tianmu 支持的异常处理类型如下图：

异常处理的流程图如下：

出现异常后 Tianmu 系统会把异常信息，和出现异常逻辑的堆栈调用信息以 WARN 级别的日志信息记录在 Tianmu 的系统日志里面，日志所在的目录：StoneDB 安装目录下/log/tianmu.log 文件中。

异常处理模块核心基类：

class common:: Exception

线程池

Tianmu 的线程是基于 C++ 新特性实现的

线程池核心类：

class utils::thread_pool

其具有以下优点：

• Tianmu 的线程池的实现是基于 C++11 标准的线程库：std::thread。可进行跨平台编译而无需修改代码。

  
  

• 使用 std::condition_variable 和 std::mutex  进行线程的阻塞控制和唤醒,避免线程无效的循环和等待，提高程序效率。

  
  

• 对添加线程的入口使用了函数模板与可变长参数模板，使之可添加任意的处理流程进入到线程池中。

  
  

• 其中 Tianmu 引擎支持利用 std::thread::hardware_concurrency() 函数或者机器的 CPU 核心数，自动的对不同线程池利用不同的分配策略来设置线程池中的线程数量，可以自动精准的配置和利用机器的 CPU，避免造成 CPU 资源利用不足和线程分配过多导致系统资源内耗的情况。同时用户也可根据机器的资源情况进行配置。

  
  

1.线程池类型

目前 Tianmu 引擎基于此线程池类定义了以下四类线程池

• 延迟插入线程池

主要功能是将 insert buffer 中的数据加载到数据库

utils::thread_pool delay_insert_thread_pool;

• 加载导入线程池

主要功能是把插入和导入的数据落地到磁盘

utils::thread_pool load_thread_pool;

• 查询处理线程池

为查询过程中提供并行处理的能力

utils::thread_pool query_thread_pool;

• delete & update 执行线程池

为 delete 和 update 执行接口提供并行执行的功能

utils::thread_pool delete_or_update_thread_pool

各类线程池和其中加入的线程执行体如下图所示：

2.线程池初始化流程

线程池初始化的过程是在 StoneDB 系统启动的过程中进行的初始化，主要是为各类线程池初始化实例对象，设置各类线程池的类型，和线程池的大小。

下图为线程初始化过程 StoneDB 系统调用的流程:

以上是本文全部内容。

如果您对我们的源码感兴趣，欢迎到我们的 GitHub 代码仓库阅读查看，觉得不错记得点个 Star 哦~

StoneDB 代码仓库：https://github.com/stoneatom/stonedb

StoneDB 社区官网：https://stonedb.io/

带你来吃瓜！Andy Pavlo教授带您一文回顾数据库的2022年稳扎稳打，坚定前行 | 一文带你回顾 StoneDB 的 2022 年

哪篇论文宣布了 HTAP 数据库的诞生？| StoneDB学术分享会#5

列存引擎 Tianmu 如何实现 Delete？| StoneDB 研发分享 #3

StoneDB 首席架构师李浩：如何选择一款 HTAP 产品？

子查询优化之 Semi-join 优化 | StoneDB 研发分享 #2