TDSQL-C PG 版整体架构
\
在介绍整体架构前，先说一下为什么我们要做 TDSQL-C 这款产品。在传统数据库上，数据库的使用是存在一些问题，主要分为以下四个：
第一是资源利用率低，计算和存储在一台机器上，CPU 和磁盘使用不均衡，例如 CPU 用满，但磁盘很空闲或者 CPU 很空闲但磁盘又满了，这样就会导致资源利用率低。
第二是扩展能力不足，在单排上可能不能满足一些用户要求，无法扩展。
第三是资源规划难，例如用户使用数据库，一开始无法预估这个数据库需要多少次磁盘空间。
第四是备份比较困难，因为每一个实例数据是私有的，所以每个实例都需要单独进行备份。
\
TDSQL-C 的解决思路：
\
第一个问题是计算存储分离，计算资源可以弹性调度。例如说可能给用户分配一个 4 核 8G 存储资源，一段时间以后会发现这个无法满足他要求，那可以给它分配一个更高规格实例。比如说 16 核 32G 这样一个实例，这个是做计算资源升配。第二个问题是日志下沉以及异步回放，TDSQL-C 的日志是通过网络，从计算层下放到存储层。第三个问题是共享分布式存储，我们 TDSQL-C 地域的所有实例，在底下是共享一个分布式存储，可以动态向一个实例里添加资源。最后一个是后台持续备份，我们的后台有定期备份任务，将日志和数据备份到地上存储上面。
\
PG 实例，包括主实例和读实例，主的负责读写，只读是负责数据读取。在 PG 下有一个叫 CynosStore Agent 组件，它主要负责存储层进行通信，包括主的写日志、读页面，从的是读页面。再向下是存储服务或叫 CynosStore，采用的是 RAPS 结构，一主两层。右边是集群管理服务，是对 CynosStore 里存储节点进行管理服务。包括故障迁移是一个节点发生故障然后迁到其它节点功能。
\
另外一个当需要扩展资源时，也是由这个集群管理服务来实现。下面是对象存储，我们会定期在对象存储备份日志和数据。这里涉及几个核心架构：一个是日志下沉，计算节点产生的日志是通过网络，下沉到存储层。存储层是通过异步方式来回访日志，导出页面上去。另外是我们会提供一个多版本读的能力，PG 上层可能会有多个 Buffer 会话去读这个数据，每个开始时间不一样，可能会读到不同的版本。
\
介绍一下日志下沉、异步回放这部分。这里边涉及几个概念：
\
第一个是数据原子修改，我们叫 MTR。当中有很多情况是一个数对应一个数据库要修改多个页面，例如想对数字索引分裂或是一条 UP Date 语句，它可能要给多条元组，分布在不同的页面上，这些都需要保证是原子操作。第二是 CPL 概念，我们 MTR 里修改了多条数据页面修改，最后一个产生日志我们叫它 CPL，另外一个是叫 VDL。这 CPL 是存储层所有连续 CPL 里最大值，我管它叫做 VDL。随着数据库在运行中，这个 VDL 是在不断地向前推进。同时我们的 PG 读也是拿到一个读点，就是一个个的 VDL。
\
第二个是日志异步写入。日志异步写入是由我们 PG 进程来生成日志，写到我们的日志 Buffer，日志 Buffer 是 PG 进程和我们 CynosStore Agent 进程之间共享的。写到这个 Buffer 以后，由 Agent 进程给它异步发送到存储节点。存储节点是通过挂到日志链上，再异步合并到数据页面上去，整个过程都是异步的。
\
第三个是日志并行插入。上层 PG 可以有多个 Buffer 同时去写日志，是用一个并行的方式，不是串行的拷贝方式。
\
接下来看一下，TDSQL-C PG 版的主机优化：
\
第一点是不必依赖于传统 PG 的 CheckPoint 机制。大家都知道传统 PG 有个 CheckPoint，定期把数据库中日志和对应修改的数据页都刷到本地磁盘上，这是一个比较耗时操作。那在我们的系统里边由于是存在分离，日志是异步通过存储节点来回放，所以就没有了 CheckPoint（07:43 英）的机制。
\
第二点是不需要在日志中记录全页。PG 上有一个概念，叫 Full Page Write，在 CheckPoint 之后，对每个数据页面的第一次修改，把整个数据页面内容写入到日志当中。这是为了防止断电情况下可能产生数据页面的半页问题，而在我们这种架构下不需要这个，可以减少很多日志。
\
第三点是快速启动系统。在启动时不需要恢复 XLog、DLog 这些，可以很快将数据库启动起来提供服务。传统 PG 它是先需要恢复大量 XLog 以后，达到一致点才可以对外提供服务。
\
最后一个是日志合并压缩。这个是在对一个数据页面做修改时，往往需要修改这个页面多个不同偏移，比如说从第 0 个偏移改 8 个字节，然后需要从第 30 个字节开始改 4 个字节，会涉及到多个修改。我们把这同一页面多个修改抽象出来一个共享日志来减少日志大小，进一步减少 IO。
\
TDSQL-C PG 版主从架构
\
接下来介绍一下 TDSQL-C PG 版的主从架构。传统数据库 PG 主备模式是先把日志写到本地磁盘，再由主机的 Sender 进程把 XLog 读取出来通过网络发送到备机，备机有个 Receiver 进程接收到这部分日志写到本地磁盘，再由 PG 恢复进程 Starup 读出来，把 XLog 对应修改应用到数据页面上去。但是它有几个缺点，第一个是在创建备机时，需要拷贝主机日志和数据这部分内容，这部分内容拷贝需要一定时间，例如说当实例比较大几个 T 甚至几十个 T 时，需要很多时间，另外一点是需要耗费存储资源，在备机切换成主机和启动过程中，它都是需要去恢复 XLog，达到一致性状态之后才能对外提供服务，导致结果就会启动慢。
\
我们采用的一主多读模式有以下两种优势：第一个是由于我们搭建从句速度很快，所以横向扩展读能力会比传统 PG 好很多。我们搭建从不需要考虑数据，因为我们的数据是共享的。第二个是由于我们横向扩展能力强，所以从提升主时也不需要来恢复日志，在提升数据库可用性这方面比传统 PG 好很多。
\
接下来介绍主从架构里边多个节点并恢复日志的实现。这张图里面是一组三层结构，可以看到主从之间发送日志是在我们 CynosStore Agent 这个组件里进行发送。从机是由 CynosStore Agent 组件来接收日志。接收到日志会把它先写到磁盘，再读上来写到共享日志 HAC 表里生成日志链，这个日志链的 Key 就是 Block ID。
\
这些日志大概分为两类：第一类是运行时一些信息，包括事物列表，还有锁，还有一些运行时快照这些信息。另外一类是对数据页修改产生的日志，包括 Heap 页面、索引页面这些。挂完链以后，这些链上的日志是由 PG 的后台进程读取，然后将日志对应的修改应用到页面上。和 PG 不一样的在于，当我们要应用的日志对应数据页面不在内存当中时，我们跳过这个页面读取，就是日志恢复是不需要从存储上读上来以后再恢复到内存中。这一点是和传统 PG 不一样的地方。
\
TDSQL PG 版主从机优化
\
接下来介绍 TDSQL-C PG 版优化，这里涉及到从句优化。从 Starup 进程去读 XLog，可以看到它不管页面是不是在 Buffer 中，它都是需要去存储中把对应数据页面读出来，把 XLog 应用上去在恢复下一条。因为它的数据不是共享的而是私有的，如果不恢复对应日志就会丢失数据。
\
我们和它区别一是我们有多个应用日志进程来应用日志。二是当这个页面不在 Buffer 的时候，我们可以跳过这部分日志，就不需要去读上来再回复。
\
接下来介绍一下前面提到的从机并行合并日志。这个图里面我们画的是 ABCD 有这么四个数据块，每个块上面是括号里的值表示的是当前数据块日志应用到的位置，11、17、15、9，它们表示的就是当前数据块应用位置。假设现在又来了 12、18、16、19 对应日志，那就会有多个 Merge 进程来对这些没有相关性的数据块做并行的恢复。例如第一个 Merge 进程会对 A 和 B 这两个数据块做恢复。如果是另外一个 Merge 进程可以对 C 这个数据块做恢复，它们之间是并行的。每恢复完这样一些数据块后，我们的 VDL 就可以向前推进，比如说从 17 到 19 还可以接着向前推。
\
接下来介绍从机优化是针对 DROP 表和 DROP 数据库优化。在数据库 PG 里，当你主机上 DROP 一个表或 DROP 一个 DB 时，从机需要做这么几件事：
\
第一是要删除，把这个表或者这个数据库在系统表当中的原数据，像 PG-Class 当中或者是 PG-Attrdef，还有 PG-attribute 的这些系统表当中的原数据，要先给它删掉。
\
第二是需要遍历一下 Shared Buffer，这些表或数据可能在从机上去读取过，它可能在 Buffer 里留下了一些页面，我们需要把这些页面找到，让它失效掉。
\
第三是发送失效消息，就是这个表或数据的失效消息。一个时效消息队列，通知其它进程，然后是删除外存文件。
\
这里第二步是 Shared Buffer，这个操作比较耗时。按照默认 PG 的一个 Buffer 是 8K 来算，那么 1G 的 Shared Buffer 就会有 13 万左右 Buffer，那么有 64G 大概会有 800 多万的 Buffer。被删一张表，在从机这边可能要遍历 800 万次 Buffer，失效一个页面，去淘汰一个页面。当到了这个表比较多的时候，比如说抓回一个 Scheme，下面可能有几十张表时，那么这个遍历次数就更多了。
\
我们这里做了一个优化，就是将它的第二步也就是遍历 Buffer，失效 Buffer 的操作，把它单独拿出来做为一个进程来做这件事。这个地方我们叫 Log Process。它和 Starup 之间是通过共享内存队列方式来通信，也就是 Starup 进程。当需要失效 Shared Buffer 的时候，我们会把对应的 DBID 或表 ID 放到队列中，Starup 会通知 Log Process，Log Process 会去对接里面取到这个 DBID 或 TableID，再去遍历 Buffer，将对应 Buffer 失效掉。
\
另外一个优化和 DAG 表相关。PG 在 DAG 表时，会把这个表信息在内存当中保存这个表一些信息，当这个表在主机删除，再从机需要恢复的时候，它会把这个表从它单项列表当中移除掉，也就是这个表第一次创建时会在从机放到一个列表里，当主机删除的时候，备机会把这个表信息从单列表导出来，把它进行删除。
\
当我们表比较多的时候，比如说有几千、几万表时，单向列表长度可能需要几千几万。当要删除这个表时，要从几千或几万个元素单向列表中去找到要删除的节点，找到它前向节点，最后把它指向要删除这个节点的后向节点。这个单向里查找是一个比较耗时的操作。
\
这里用法比较简单是把单向链表改为双向链表。让要删除这个节点的前面指向它后面节点，它后面节点指向它前面的节点，就可以达到删除目的。有了这个优化，加上异步淘汰 Buffer 优化，在有一定压力情况下，日志堆积可以从 100GB 降低到几十兆这个级别，几百兆就没有日志堆积了。
\
接下来是介绍一下传统备机和 TDSQL-C PG 版启动的一个。传统 PG 启动的时候恢复到一致性的点才能对外提供服务。当前画的这个图里比如说最小恢复点是 50，而恢复当中又来了一个 CheckPoint，比如说 CheckPoint 里记录的是 1000，那么它在下一次启动时需要恢复到 1000 点才能对外提供服务。
\
在 TDSQL-C PG 版里，从机启动时，是需要拿到一个持久化 VDL 就可以获得存储一致性状态，而这个 VDL 是可以从主机传过来的日志当中计算出来。这个速度比 PG 快很多。第二个是快速 Replica 创建备机，就是不需要复制全量数据。
\
我们的主从优化它解决的问题是避免 PG 在发生主从切换时可能会出现双写，导致日志“分叉”。例如一个一主一丛的 PG 实例，当发生切主时，由于某些原因旧主并没有死掉，可能有些应用还是连在旧主上面，但是另外一些应用连到新主上面，会导致两边数据不一致，需要人工干预才能把数据库恢复到一致状态。
\
TDSQL-C PG 版采用的是 HA Fencing 机制。当每一个主实例在启动开始写数据时，之前会通过网络去我们的 Meta 服务上面获取一个 Fencing 值，这个 Fencing 值是全局唯一递增的。计算层每次往存储层写日志时都会带着这个值。
\
当切到一个新主上时，新主又会去 Meta 服务上拿到一个新的值，例如旧主拿的是 100，旧主存储节点通讯时都会用 100，假设这时候新主上来，它会拿到 101，然后它就用 101 和我们的存储节点通信。这时假设旧主还通过网络，以 100 往存储上写数据，存储就会拒绝这个数据的写入，从而达到了避免数据分叉目的。
\
未来展望
\
对未来的一些探索，我们可能会采用一些新硬件，包括 RDMA。另外，现在是一种多层的架构，未来会尝试做多主架构、Serverless 无服务化这些来降低计算成本，可能还会做一些兼容性方面的工作，例如 Oracle 兼容性这些。
