上篇图文，从GaussDB关键架构目标、GaussDB分布式架构、数据计算路由层（Coordinator）关键技术方案等三方面对GaussDB架构进行了介绍。本篇将从数据持久化存取层(DataNode)关键技术方案、全局事务管理层（GTM）关键技术方案、集群管理层（CM）关键技术方案、OM运维管理关键技术方案等方面继续解读GaussDB架构。
目录
4 数据持久化存取层(DataNode)关键技术方案
5 全局事务管理层（GTM）关键技术方案
5.1 单节点的事务
5.2 跨节点事务
6 集群管理层（CM）关键技术方案
7 OM运维管理关键技术方案
8 安全关键技术方案
安全关键技术一：密态等值查询
安全关键技术二：账本数据库
4 数据持久化存取层(DataNode)关键技术方案
Datanode节点主要负责数据的持久化和快速写入、读取。数据持久化采用物理日志wal，事务提交wal刷盘， 对外提供逻辑日志功能，反解析物理日志为SQL逻辑日志。
图1 datanode数据持久化
Astore：存储格式为追加写优化设计，其多版本元组采用新、老版本混合存储方式。当一个更新操作将老版本元组更新为新版本元组之后，如果老版本元组所在页面仍然有空闲空间，则直接在该页面内插入更新后的新版本元组，并在老版本元组中记录指向新版本元组地址的指针。在这个过程中，新版本元组以追加写的方式和被更新的老版本元组混合存放，这样可以减少更新操作的IO开销。然而，需要指出的是，由于新、老版本元组是混合存放的，因此在清理老版本元组时需要从混杂的数据中挑出垃圾数据，清理开销会比较大。同时，由于新版本元组位置相对老版本元组位置发生了变化，而索引中只记录了老版本元组的位置，因此容易导致索引膨胀。为了缓解索引膨胀这个问题，对于同一个页面内的更新，采用了HOT技术，将同一个记录的多个版本按从老至新的更新顺序给串连起来，但是这种从老至新的更新链顺序，对于并发的OLTP类短查询是效率是比较低，需要遍历的版本个数较多。
Ustore：与astore相比，ustore的最大特点在于新、老版本记录的分离存储。当一个更新操作将老版本元组更新为新版本元组之后，直接在老版本元组的位置覆写新版本元组内容，同时，将老版本元组移到统一管理历史版本的undo区域。在这个过程中，既需要修改数据页面，也需要修改undo页面，更新操作开销较astore的追加更新稍大。但是，就如同垃圾分类回收一样，这样带来的好处也是显而易见的，在清理老版本元组时，不再需要遍历扫描主表数据，直接按需回收undo区域即可，垃圾清理开销较astore不仅大幅降低，而且稳定可控。同时，由于新版本元组复用老版本元组的物理位置，因此索引无需更新，索引膨胀得到有效控制。另外，在ustore中，多个版本的更新链按从新至老的顺序串连，对于并发查询更友好。总而言之，ustore更适合更新频繁的业务场景。
5 全局事务管理层（GTM）关键技术方案
GTM 仅处理全局时间戳请求， 64位CSN递增，几乎都是CPU ++和消息收发操作。不是每次都写ETCD, 而是采用定期持久化到ETCD 里， 每次写ETCD的CSN要加上一个backup_step (100w), 一旦GTM故障，CSN从ETCD读取出来的值保证单调递增。当前GTM 只完成CSN++, 预估可以支持200M/s 请求。GTM处理获取csn消息和csn++的消息, TCP 协议栈消耗CPU会非常严重，采用用户态协议栈提高GTM单节点的处理能力。未来架构演进完全去中心化，采用高精度时钟解决扩展性问题。
5.1 单节点的事务
图2 单节点事务处理流程
关键设计：
-
GTM 只维护一个CSN++, snapshot 只包含CSN
-
DN 本地维护事务id, 维护id到CSN的映射(CSN_LOG)
-
DN 本地GC的过程中回填CSN
-
单shared读事务使用local snapshot：
-
get local latest CSN + get prepared_xid
-
wait csn commit in process(same as before)
-
如果row.csn < localsnapshot.csn || xid in prepared_xid list 可见, 否则不可见
5.2 跨节点事务
图3 跨节点事务处理流程
关键设计：
-
第二阶段Commit 改为异步方式，只同步做prepare xact。（1.5 PC）
-
DN 上行级别可见性判断：
-
DN处于prepared状态的事务依赖对应CN上的事务是否提交，如果已经提交，且CSN比snapshot.CSN小，就可见
-
对DN上处于prepared的事务，CN上的事务不处于提交状态，则必须判断是否残留状态，回滚。
6 集群管理层（CM）关键技术方案
GaussDB Kernel V5 集群管理层关键模块如下。
图4 集群管理层组件设计图
CM 组件提供了四种服务 CM Agent, CM Server, OM Monitor, cm_ctl，与各类实例服务组件（CN, DN, GTM 等）一起构成了整个数据库集群系统。
cm_ctl
-
通过命令行执行集群的启动、停止、状态查询、主备倒换、备机重建等功能
-
除启动和停止外，主要通过与 CM Server 的消息传递执行命令
-
可在任意节点执行并获取到相同的结果
OM Monitor
-
由系统定时任务拉起
-
负责 CM Agent 的运行状态监控
CM Agent
-
由 OM Monitor 拉起
-
负责拉起和停止所在节点的 CN, DN, GTM, CM Server（如果存在）；监控实例状态并上报至 CM Server；执行 CM Server 下发的命令等
-
对应 cm_agent 二进制文件，所有节点常驻服务
CM Server
-
由 CM Agent 拉起，是整个集群管理组件的大脑
-
负责接收 cm_ctl 发送的命令并下发至 CM Agent；接收并处理 CM Agent 上报的实例状态，下发仲裁指令保证各类故障和异常场景下集群的可用性
-
对应 cm_server 二进制文件，常驻服务
CM与各类组件的主备数据同步、倒换、重建等机制高度融合，提供告警、重启、倒换、隔离等手段，赋予数据库实例故障恢复及自愈的高可用（HA）能力，保证数据的可靠性和完整性，最终实现集群对外的业务连续性。
集群管理仲裁关键技术
单节点故障在生产过程中，不可避免。CM 组件可根据探测到的状态进行仲裁，从而尽可能恢复集群可用性的过程。
以某个主 DN 故障为例，一次典型的仲裁流程包括：
① CM Agent 1探测DN主实例并发现故障
② CM Agent 1持续上报实例故障信息至CM Server
③ CM Server执行仲裁流程，选择DN备机升主
④ CM Server下发升主命令至CM Agent 2
⑤ CM Agent 2对实例执行升主操作
图5 集群管理仲裁过程
常见的故障类型包含磁盘故障、网络故障、下电故障、操作系统故障、其它故障（CPU故障）等。CM在选举过程中，遵从DN多数派。即，对于某一个DN分片来说，故障后的选主，需要得到大多数DN的投票，候选DN副本才可以被选中升主。仲裁规则主要依据两个原则：1） 任期（Term）大，且日志长的DN副本优先被选主 2） 同等条件下，静态主优先。
CM辅助不同组件故障情况下恢复过程
1. CN 故障 （集中式部署时，无CM节点）
-
DDL 语句无法执行，DML 语句不受影响
-
通过将故障 CN 剔除，可保障 DDL 语句不受影响
-
仅支持集群内 CN 个数大于 3，且 1 个 CN 发生故障时剔除
2. DN 故障
-
单点故障可自动恢复
-
主 DN 故障时，仲裁备 DN 升主继续提供服务
-
备 DN 故障时，主 DN 将日志和数据同步至从备，业务不受影响
3. 主 GTM 故障
-
备 GTM 升主后继续提供服务
4. 主 CM Server 故障
-
备 CM Server 接受多数派 CM Agent链接，升主后继续提供服务
异常检测
从业界经验来看，数据库实例可能处于故障、僵死、亚健康等状态。这些状态的出现概率逐级降低，但检测难度逐级增高。尤其是如何区分亚健康状态和系统繁忙状态，具有较大的挑战性。
CM 组件包含异常检测流程，可用于识别和处理网络不稳定、磁盘 IO 挂死、进程/线程僵死、进程频繁退出、实例状态时好时坏等场景，提高集群的稳定性和可用性。
以 DN 短链接检测为例，CM Agent 按照固定时间间隔与 DN 实例新建链接。如果与某个主 DN 链接失败或通过新链接无法执行 SQL 语句，则认为该 DN 发生 1 次 Hang 异常。如果多次出现异常，则会触发 Hang 检测机制，将该 DN 实例杀死并执行主备切换。目前常见的异常检测项有：
-
短链接建立
-
通过短链接执行 SQL 语句
-
IO 挂死
-
内存占用异常
基于Paxos协议复制实现DN副本自仲裁
GaussDB Kernel V5 采用基于Paxos协议主备副本复制协议，实现DN副本的自仲裁功能。关键技术方案如下图所示，其中DCF为GaussDB Kernel V5 基于Paxos协议的一致性复制组件。需包含日志复制、自仲裁选主等功能。
图6 DN自仲裁设计
关键技术方案要点：1）DN 副本自仲裁，缩短仲裁链路，减小RTO 2）采用Paxos一致性协议，保证DN副本间的一致性，避免备机由于日志分叉产生增量重建。
未来技术方案演进：1） DCF组件日志与数据库内核日志合一，减少对IO的占用。2） 采用Parallel Paxos协议或者多主的Paxos协议提升日志复制的吞吐量 3）通过RDMA/UB 网络优化主、备节点日志传输，提升日志复制性能。
7 OM运维管理关键技术方案
GaussDB Kernel V5 OM运维管理关键模块如下。
OM 运维主要功能有：
-
安装
-
升级
-
节点替换
-
扩容、缩容
-
自动告警
-
巡检
-
备份恢复、容灾
-
日志分析系统
在华为云的部署模式下，OM相关组件部署示意图如下：
图7 华为云OM运维管理
-
用户登录华为云Console，访问GaussDB Kernel V5的管控页面，输入想要的运维操作（购买实例）。
-
华为云Console调用云管控服务，云管控服务根据用户输入的运维操作，如购买实例，进行相应的操作，如购买实例，云管控服务会创建虚拟机。
-
云管控服务调用Mgr Agent，Mgr Agent会调用内置插件Adapter。
-
Adapter会调用OM Agent。
-
OM Agent会调用OM来完成具体的运维操作。
通过OM Adaptor和OM Agent 采用适配器模式设计，对管控面提供了统一的北向接口。降低了管控面平台变更后重新对接的难度，更适用于云平台下的开发模式。
8 安全关键技术方案
安全关键技术一：密态等值查询
密态等值查询属于密态数据库第一阶段方案，但是遵从密态数据库总体架构。密态数据库的总体架构示意图如下图所示。密态数据库的完整形态包括密码学方案和软硬结合方案。
图8 密态数据库总体架构
由于密态等值查询仅涉及到软件部分，仅需集成密态数据库总体架构的软件部分，其总体实现方案如下图所示。
图9 密态等值查询总体方案
从总体流程上来看，数据在客户端完成加密，以密文形式发送到GaussDB Kernel数据库服务侧，即需要在客户端构建加解密模块。加解密模块依赖密钥管理模块，密钥管理模块生成根密钥(RK, Root Key)和客户端主密钥(CMK，Client Master Key)，有了CMK，可以通过SQL语法定义列加密密钥(CEK，Column Encryption Key)。其中，CMK由RK加密后保存在密钥存储文件(KSF，Key Store File)中，与RK一起由KeyTool统一管理；CEK则由CMK加密后存储在服务端，加密算法使用AES128和AES256。
按照原有明文格式发送至服务端。当查询任务发起后，客户端需要对当前的Query进行解析，如果查询语句中涉及加密列，则对对应的列参数(加密列关联参数)也要进行加密(这里说的加密均需要为确定性加密，否则无法支持对应的查询)；如果查询语句中不涉及加密列，则直接发送至服务端，无需额外的操作。
在数据库服务侧，加密列的数据始终以密文形态存在，整个查询也在密文形态下实现。对于第一阶段密态等值查询解决方案，需要采用确定性加密，使得相同的明文数据获得相同的密文，从而支持等值计算。
按照用户使用的流程，整体设计思路将围绕用户的使用步骤展开，即整个Use Case被切分成三部分。具体如下：
-
生成客户端主密钥：用户需要在本地部署密钥管理工具（KeyTool），通过密钥管理工具相关指令来管理密钥，如创建或删除密钥；当前该工具底层集成华为公司KMC组件，生成的主密钥通过KMC进行保存和管理，并返回密钥信息给用户，方便后续调用和管理；
-
记录CMK与CEK信息，在系统创建加密表：有了阶段1中生成的密钥信息后，为数据库设计专门的密钥创建语法，包括设计新的主密钥(CMK, Client Master Key)和列加密密钥(CEK, Column Encryption Key)语法；通过内核接口访问KeyTool中存储的主密钥并记录在系统中，列加密密钥则由主密钥在客户端完成加密后存储在数据库服务端；数据通过列加密密钥完成在客户端的加密，然后传输到服务端。为了做到查询对用户的透明，需要基于当前已有的创建表语法进行改造，主要进一步增强列的option信息；
-
完成密态等值查询：为了完成密态等值查询需要在客户端和服务端完成配合设计。其中在客户端需要设计轻量级的解析模块，完成对查询语句的解析，定义密态等值查询所支持的规格。在客户端解析模块，需要识别所有涉及的属性是否包含加密列信息，如果不涉及则直接返回并将查询发送到服务端，如果涉及加密列，则需要按照对应的列加密密钥和加密算法加密参数信息，然后发送查询任务到服务端。在服务端，需要在优化器和执行器的各个执行逻辑过程中完成功能适配，特别的，数据在经过加密后，存储的数据类型发生变更，在服务端需要根据新的存储类型进行查询任务执行。
安全关键技术二：账本数据库
防篡改数据库的整体方案如图1所示，其最终形态是多个数据库之间的多方共识系统。我们基于GaussDB Kernel数据库，从存储层、应用层和传输层进行改造和增强。存储层为防篡改用户表增加校验信息，作为篡改校验的基础能力；应用层提供高效篡改校验接口，使用高性能校验算法，能够快速识别出用户表、用户历史表以及全局区块表的一致性，有效识别篡改行为；传输层增加多方共识执行接口，并内置CFG、BFT等共识算法，使得系统中，每一次对防篡改用户表的修改都需要取得大多数参与方的认可和记录，保证核心数据的防篡改、可追溯。
图10 防篡改数据库总体方案
账本数据库属于防篡改数据库第一阶段方案，是防篡改数据库的单集群形态，主要是实现了存储层、执行层的功能，提供了用于防篡改校验数据以及高效篡改校验算法。账本数据库作为防篡改数据库整体方案的基础功能和核心能力，需要紧密结合内核并利用分布式数据库的执行框架和通信流程。
我们采用schema对防篡改用户表和普通表进行隔离。用户在防篡改schema中创建的表会成为防篡改用户表，防篡改用户表与普通表最大的差别是防篡改用户表会在创建时自动添加名为hash的系统列。hash列在用户插入数据时，自动通过单向加密哈希算法生成。同时在创建防篡改用户表时，会在blockchain系统schema中创建与之一一对应的用户历史表。用户对防篡改表进行DML操作，造成的行级数据更改记录会记录在对应的用户历史表中，同时会将sql语句记录在全局区块表中，作为操作的记录。防篡改用户表、用户历史表、全局区块表中的hash摘要信息可以相互校验，如果校验通过，则视为用户表未被篡改。
需要特别说明的是，我们通过判断数据的一致性来识别篡改行为，不能防止恶意用户从文件层一致的修改多个文件以及越权用户通过sql语句对用户表进行修改。
账本数据库的功能主要分为三个部分：防篡改用户表的DDL和DML操作、防篡改用户表的一致性校验以及校验数据的归档和修复功能。
首先我们介绍防篡改特性的隔离级别，我们使用schema来隔离普通用户表和防篡改用户表。通过增加创建防篡改schema的语法: CREATE SCHEMA schema_name WITH BLOCKCHAIN，在防篡改schema中创建的表，均为防篡改用户表。
其次是用户表的DDL和DML操作，在创建防篡改用户表的过程中，主要有两点修改：
1. 对该表增加一个名为hash的伪列，该列类型为uuid16，该列记录和每一行数据的校验信息。
2. 生成防篡改用户表对应的用户历史表，用户表中记录了行级数据的修改记录。
以上内容为数据持久化存取层(DataNode)关键技术方案、全局事务管理层（GTM）关键技术方案、集群管理层（CM）关键技术方案、OM运维管理关键技术方案和安全关键技术方案的相关内容，下篇图文将接着分享智能关键技术方案、驱动接口关键技术方案的精彩内容，敬请期待！
欢迎小伙伴们交流~