PostgreSQL temp table 全链路 实现原理

Posted 2023-03-20

文章目录

• ​​背景​​
• ​​使用​​
• ​​实现​​

• ​​创建表​​
• ​​插入​​
• ​​删除表​​

背景

表(table/relation) 作为 PostgreSQL 数据库中最为常用的一种数据库对象，用户使用极多。

因为PG 本身是事务型处理的数据库，其实现事务语义采用的两种方式：锁 和 MVCC，前者辅助实现后者 已经 其他的事务特性，而后者则用于实现事务的隔离性。

所以，用户对一个普通表的读写链路会有较多的常规锁保护，而且中间过程还需要访问非常多的共享内存变量，也会需要 轻量锁的保护。但是用户有的时候就想在当前session临时创建一个表用作数据计算，而且用户能够保证这个表是不会被其他的session访问的，这个时候如果还是走普通用户表的读写/更新逻辑，那对一些有性能需求的用户来说当前表操作链路就没有必要有那么多锁的参与了。

所以，PG 很贴心得为用户实现了 temp-table 特性，来满足用户在session 内的高性能操作一个表的临时需求。

使用

接下来简单看看 temp-table 应该如何使用。

首先temp-table 生命周期默认是 backend级别，即一个backend内部创建了temp-table之后，backend退出的时候会对当前backend 所创建的所有的temp-table进行清理。

使用很简单，按照temp-table的声明周期，有两种使用方式：

1. Backend粒度

该粒度下如果不指定drop temp table的话默认 drop的时机是在 backend 退出的时候。

postgres=# create  temp table tmp(c1 int);
CREATE TABLE
postgres=# select oid,relname,relnamespace from pg_class where relname=tmp;
  oid  | relname | relnamespace
-------+---------+--------------
 24622 | tmp     |        24585
postgres=# select oid,datname from pg_database ;
  oid  |  datname
-------+-----------
     5 | postgres
 24604 | aaa
     1 | template1
     4 | template0

此时会在名字是 ​​postgres ​​​ 数据库对应的oid目录下创建一个 ​​tmp​​​ 表的 oid对应的数据文件​​t3_24622​​​，会带有​​t + backendId​​字段，和普通的以oid命名的表区分开来。

-rw-------  1 staff  staff       0  3 13 18:31 t3_24622

我们可以操作这个 ​​tmp​​表像操作普通的用户表一样，做增删改查以及索引添加。

postgres=# create index on tmp (c1 );
CREATE INDEX
postgres=# insert into tmp values (generate_series(1,10000));
INSERT 0 10000

此时对应的数据库数据文件目录下也会有对应tmp 表的索引表以及 fsm文件。

-rw-------  1 staff  staff  368640  3 13 21:30 t3_24622
-rw-------  1 staff  staff  245760  3 13 21:30 t3_24625
-rw-------  1 staff  staff   24576  3 13 21:30 t3_24622_fsm

如果我们退出backend 或者 手动​​drop table tmp;​​​或者 有backend切换操作(​​\\c other-database​​)，此时与 该temp-table相关的所有数据文件都会被清理。

2. Transaction粒度

该粒度下 可以指定一个事务提交时 对 temp table 的操作，transaction粒度需要在用户可控事务生命周期的事务块里 :​​begin​​​, ​​commit​​等；

• ​​create temp table aaa (c1 int) on commit drop;​​ 指定 temp table aaa 在发生commit 时（比如insert into aaa 操作）触发drop tmp table的行为
• ​​create temp table aaa (c1 int) on commit DELETE ROWS;​​ 会在提交时 删除事务内对当前temp table 的更新行，temp table本身的drop会在backend 退出时。
• ​​create temp table aaa (c1 int) on commit preserve rows​​ 会在提交时保留对 temp table 事务内的更新。

postgres=# begin;
BEGIN
postgres=*# create temp table aaa (c1 int) on commit preserve rows ;
CREATE TABLE
postgres=*#  insert into aaa values (1),(2);
INSERT 0 2
postgres=*# commit;
COMMIT
postgres=# select * from aaa;
 c1
----
  1
  2
(2 rows)

实现

接下来进入到比较有趣的数据库内核环节，关于temp table的实现链路 基本是和普通表的实现接近，包括创建、删除、插入等。

总的来说，差异点主要如下：

1. temp-table 的数据页 是由local buffer管理，而不是shared buffer，所以仅对创建它的backend可见。
2. temp-table 不会写WAL

读写链路通过如下流程图来展示就非常清晰：

从整体架构流程中能够很明显得看到temp-table 和 普通的用户表之间的异同。
从上到下可以看到 temp-table 以及 用户表读写链路上的各个组件：

• syscache & relcache， PG 为每一个session对应的backend进程单独维护了其进程本地的系统表缓存 和 表关系缓存，用于加速各个backend 内部对catalog 以及 表关系的访问。当然，这一些cache之间会通过 invalid-message 进行通信，保障不同backend之间的cache 一致性。这一部分 不论是 普通的backend 还是 创建了temp-table的backend 都有同样的访问逻辑。 差异点是对 temp-table的更新并不会发送 invalid-message 到其他的backend，不需要做cache 一致性的同步，因为 temp-table 仅会在当前backend 访问。这个过程，也不需要有锁参与。
• buffer manager，buffer-manager 组件也可以理解为是 buffer-pool ，主要用作管理 PG heap表存储引擎需要的page。buffer-manager 能够提供高效的 page访问 以及 dirty-page 淘汰策略，而page 内部则是存放 表的 tuple 行数据。关于 tuple 部分的详细描述可以参考：PostgreSQL heap表引擎实现原理。 buffer-manager 内部主要有几个小组件用于高效管理pages：

1. HATB，其主要拥有几个组件：​​HASHHDR​​​，用来保存当前hash表的控制信息，比如hash slot(segment)的个数，每一个segment的大小，freelist 指针，已经存储了多少元素等；​​HASHSEGMENT​​​ 一个保存元素链表的数组，数组对cpu的局部性更为友好，每一个数组元素是一个链表，保存实际存储在其中的page信息; ​​HASHELEMENT​​ 则是保存每一个page的hash-value，对于每一个page 都会经过 HTAB得 hashfunction 映射到某一个具体的 HASHSEGMENT 中的链表尾部。查找的时候根据 page 的 hash-value 找到 当前page属于哪一个 HASHSEGMENT，再顺序遍历其内部的链表进行hash-value 的匹配。找到对应的 HASHELEMENT之后 提取其 index。
2. Buf Descriptor，这里通过 ​​LocalBufferDescriptors​​ 保存每一个page 在内存中的具体起始地址。因为page的大小是固定的，找到了起始地址，意味着就能拿到改page内部的数据。
3. 通过 BufferDescriptor拿到的起始地址去 buffer pool中解析对应的 page 数据。

写入链路也是需要先从hash表 --> BufferDescriptor --> page 拿到一个可以存放当前tuple的 page，然后将tuple 数据填充到当前page中并对page header的头部做一些可见性相关的修改（具体细节参见前面提到的heap 表引擎的实现原理）。

需要注意的是， 对于temp-table的更新 ，其所在的backend 会为其创建local-buffer进行 temp-table的 page 管理，local-buffer-manger 因为没有并发访问的问题，所以其不论是访问hash表 还是更新 page，都不需要加锁。
而对于 ordinary-table 的更新，则是通过 shared-buffer-manager。多个backend 可能会访问同一个数据表，当然shared-buffer-manager 中的数据结构和 local-buffer-manager 基本一样，差异点事对其内部的基本数据结构的访问需要加锁。

• BgWorker ，这是一批后台进程的总称。比如像是 ​​checkpointer​​​, ​​walwriter​​​ 以及 ​​background writer​​​ 都是属于 bgworker。这里主要是指 ​​background writer​​​，其主要负责将 dirty-page 写入到 os-page-cache中。
  走os的写链路也是以page 为粒度进行写入，buffer-manager 有一套自己的 dirty-page 逐出算法，对于 dirty-page 会通过​​​background writer​​​ bg worker 写入到os 的 page-cache中。最终的持久化到磁盘则是通过 ​​checkpointer​​​进程 搭配 fsync 来完成。
  在一部分需要注意的是 普通表 在写入 shared-buffer-manager 之前，会多一个 WAL的写入。 wal 也是拥有自己的 wal-buffer 来管理 wal-record 的page，其会通过 ​​walwriter​​ 写入到 + fsync写入到磁盘文件。
• autovacuum，这个后台进程主要用于清理 PG 通过 MVCC 实现并发控制引入的表膨胀数据。
  在temp-table的清理中，其也会去清理某一个 backend异常退出时没有来得及清理的 无主 的 temp-table。

整个实现链路，如果关注每一个组件的代码细节，会非常复杂。接下来的原理描述也只能是概览一些代码链路，当然主要是关注 temp-table相关的链路。

创建表

创建 temp table 走的也是 基本的DDL 链路，​​CREATE TEMP TABLE​​。前面介绍 temp-table 的时候有一个细节没有提到，就是 namespace 概念。PG为了方便对整个数据库内部的表进行管理，设计了namespace，将系统表、用户表、临时表等不同schema 的表划分到不同的namespace中，对于这一些表的owner 以及 它们的权限控制就都可以转移对该表所属的 namespace的权限控制了。

比如对于一个新创建的数据库，其拥有如下几个namespace:

boydb=# select * from pg_namespace ;
  oid  |      nspname       | nspowner |                            nspacl
-------+--------------------+----------+---------------------------------------------------------------
    99 | pg_toast           |       10 |
    11 | pg_catalog         |       10 | zhanghuigui=UC/zhanghuigui,=U/zhanghuigui
  2200 | public             |     6171 | pg_database_owner=UC/pg_database_owner,=U/pg_database_owner
 12665 | information_schema |       10 | zhanghuigui=UC/zhanghuigui,=U/zhanghuigui
(4 rows)

可以看到默认是拥有 ​​pg_toast​​​, ​​pg_catalog​​​,​​informantion_shcema​​​ 以及 ​​public​​​ 这四个namespace，其中 前三个的 ​​nspowner​​​ 一样，都是10，这个值是从 ​​pg_authid​​ 中提取出来的。

boydb=# select * from pg_authid where oid=10;
 oid |   rolname   | rolsuper | rolinherit | rolcreaterole | rolcreatedb | rolcanlogin | rolreplication | rolbypassrls | rolconnlimit | rolpassword | rolvaliduntil
-----+-------------+----------+------------+---------------+-------------+-------------+----------------+--------------+--------------+-------------+---------------
  10 | zhanghuigui | t        | t          | t             | t           | t           | t              | t            |           -1 |             |

因为这个数据库是我创建的，所以 nspowner 对应的oid 就是标识是我所创建的表，我拥有对它的操作权限的体现是通过 ​​pg_namespace​​​的 ​​nspacl​​列。

对于 ​​oid=6171​​​来说，它的owner 是​​pg_database_owner​​，这个角色是 PG14 版本新发布的一个特性，能够更为便捷得对用户权限进行控制。

在 temp-table场景中，如果我们创建一个 temp-table，PG 会在当前数据库中创建两个不会被删除的 ​​pg_namespace​​​ tuple：​​pg_temp_3​​​ 以及 ​​pg_toast_temp_3​​​。其中的数字 3 表示的是 backendId，之所以也会创建 ​​pg_toast_temp_3​​​，是因为 ​​toast 属性​​（大宽表）的存储是默认开启的，比如当前tuple的大小超过 page 1/2，会默认开启toast的存储，将实际的 tuple数据部分存储到 toast表中，原本的heap表的tupe data部分则保存指向 toast表的指针；所以temp-table的使用也需要默认有一个 temp-toast-table 的管理方式。

一个新的backend 创建临时表的主要逻辑有两部分：

1. 创建namespace: 检查当前所在的backend 进程是否有 有效的 ​​myTempNamespace​​​， 默认 ​​myTempNamespace​​​ = ​​InvalidOid​​​ 即 0；有效，则直接返回；无效，则重新创建两个新的 ​​namespace​​​，分别命名为 ​​pg_temp_<MyBackendId>​​​ , ​​pg_toast_temp_<MyBackendId>​​。
2. 创建实际的 temp 用户表，走正常的建表逻辑。

步骤一 初始化 namespace 的调用链路如下：

PostmasterMain
  ServerLoop
    BackendStartup
      BackendRun
        PostgresMain
          exec_simple_query
            PortalRun
              PortalRunMulti
                PortalRunUtility
                  standard_ProcessUtility
                    ProcessUtilitySlow
                    transformCreateStmt // 建表语句是 `create temp table xxx();`，走 `T_CreateStmt` nodeTag
                      RangeVarGetAndCheckCreationNamespace
                        RangeVarGetCreationNamespace
                          AccessTempTableNamespace
                            InitTempTableNamespace

​​AccessTempTableNamespace​​ 逻辑如下：

static void
AccessTempTableNamespace(bool force)

  /*
   * Make note that this temporary namespace has been accessed in this
   * transaction.
   */
  MyXactFlags |= XACT_FLAGS_ACCESSEDTEMPNAMESPACE;

  /*是否是有效的 namespace */
  if (!force && OidIsValid(myTempNamespace))
    return;

  /* 无效，则创建namespace */
  InitTempTableNamespace();

这里需要注意 PG 创建好的 temp-namespace 的生命周期是伴随数据库的，而不是像 temp-table一样 backend 退出就会被删除。之所以这样有两方面的考虑：

1. 同一个backend 内部创建多个temp-table，namespace肯定用一个比较合适。
2. backendId 是有限的，受 ​​MaxBackends​​ 最大连接数的影响，所以其会被复用。所以通过创建有限个数的temp-namespace 能够防止因为重复创建namespace造成的创建 temp-table的性能损失。

创建temp-namespace 过程需要访问 ​​pg_namespace​​​, 如果发现能从 ​​pg_namespace​​ 所属的syscache 中 找到一个pg_tmpe_backendId 名字的oid，则需要先删除，再创建一个新的tuple 填充到 pg_namespace中。

确认 namespace 存在 或者 新创建完成之后，进入到创建 temp table 的过程。

步骤二 创建temp table的逻辑如下，整体是非常复杂的，需要读写的其他catalog 表较多（pg_type, pg_proc, pg_class等等）

需要注意的是每一个relation 会创建一个属于它的 smgr( storage manager)，需要用它来管理本地的数据表文件，比如需要创建/修改/删除/fsync，都是通过smgr来完成的。

PostmasterMain
  ServerLoop
    BackendStartup
      BackendRun
        PostgresMain
          exec_simple_query
            PortalRun
              PortalRunMulti
                PortalRunUtility
                  standard_ProcessUtility
                    ProcessUtilitySlow // 在 transformCreateStmt 完成namespace的创建，再调用  DefineRelation创建用户表
                      DefineRelation //创建 relation
                        heap_create_with_catalog // 创建当前relation相关的catalog

完成temp-table创建之后就是向里面插入数据。

插入

插入逻辑到还是会进入 heap 表的 ​​heap_insert​​ 的逻辑：

1. 通过 heap_prepare_insert 填充 tup 的 HeapTupleHeader 部分
2. 从buffer-manager 中获取一个可用的buffer index。判断是从localbuffer 中分配还是从 shared-buffer中分配，是通过前面建表时创建的 ​​(smgr)->smgr_rnode​​​，如果是temp表，则 满足 ​​(smgr)->smgr_rnode.backend != InvalidBackendId​​​。 localbuffermanager 为了和 shared-buffer 做区分，将buffer_id 初始化为了 以-1 开始，向负值方向逐渐递减递减，后续通过 ​​LocalBufferDescriptor​​​转为 可以获取到 ​​LocalBufferBlockPointers​​ buffer-pool 的page 起始地址。
3. 拿着 获取到的buffer，去​​LocalBufferBlockPointers​​ 提取page的地址。其内部会通过 buffer的正负来区分是从local-buffer-pool 还是从 shared-buffer-pool 中拿page，将准备好的 tuple 数据填充到page中。
4. 处理这个 page 的可见性，并标识这个page 为dirty。
5. 通过 ​​RelationNeedsWAL​​​ 判断是否需要写WAL，对于temp-table来说 是不需要的，因为其属性 不是 ​​RELPERSISTENCE_PERMANENT p​​​，只有普通的用户表才会有 ​​RELPERSISTENCE_PERMANENT​​​ 标识。
   当然整个链路大家能看到函数 ​​​UnlockReleaseBuffer​​​ 或者 ​​LockBuffer​​ ，这里 temp-table 链路下 对buffer 的访问 是不需要实际加锁的，其内部判读是temp-table会直接返回。
6. 发送invalid-message，更新temp-table 本地的cache

void
heap_insert(Relation relation, HeapTuple tup, CommandId cid,
      int options, BulkInsertState bistate)

  TransactionId xid = GetCurrentTransactionId();
  HeapTuple heaptup;
  Buffer    buffer;
  Buffer    vmbuffer = InvalidBuffer;
  bool    all_visible_cleared = false;
  
  /* 填充 tup的 HeapTupleHeader部分 */
  heaptup = heap_prepare_insert(relation, tup, xid, cid, options);
  ...
  /* 从 local buffer manager 中获取/分配 一个可用的page index */
  buffer = RelationGetBufferForTuple(relation, heaptup->t_len,
                     InvalidBuffer, options, bistate,
                     &vmbuffer, NULL);
  ...
  /* 拿着page index 找到对应的page ，将 tup的 data 信息填充到当前page中 */
  RelationPutHeapTuple(relation, buffer, heaptup,
                         (options & HEAP_INSERT_SPECULATIVE) != 0);
 
 ...
 MarkBufferDirty(buffer);
 /* XLOG stuff */
 if (RelationNeedsWAL(relation))
 
   ...
 
  
  UnlockReleaseBuffer(buffer);
  if (vmbuffer != InvalidBuffer)
    ReleaseBuffer(vmbuffer);
  ...
  /* 发送invalid message，更新sys/rel cache */
  CacheInvalidateHeapTuple(relation, heaptup, NULL);
  ...

插入完成之后的dirty-page 会由 ​​background writer​​ 将脏页通过 smgrwrite 写入到os-page cache中。

删除表

对于 temp-table的删除，在不同的场景下有三种方式，它们拥有不同的调用链路，底层的执行实际删除操作的链路是一样的。

1. 创建temp-table时会去清理已经存在的 temp-namespace，此时会将这个tempnamespace 下所有的temp-relation全部删除；后续为这个backend重新创建新的temp-namespace
2. 正常的 backend 退出 会清理 temp-table的数据。
3. ​​create temp table aaa(c1 int) on commit drop;​​ 事务commit 时会删除 temp-table
4. DROP 命令和 DISCARD命令。 ​​drop table aaa;​​​ , ​​discard temp aaa;​​
5. backend 被kill 或者 异常退出，会由 autovacuum 完成temp-table 的清理

以上链路到最后完成数据清理时 除了 ​​drop​​​ 和 ​​create temp table aaa() on commit drop;​​​是通过 ​​RemoveRelations​​​ --> ​​performMultipleDeletions​​​ 清理临时表之外，其他都是通过函数 ​​performDeletion​​ 进行的，普通表的删除是不会进入到这个逻辑。

1. DISCARD命令

其执行栈如下：

PostmasterMain
  ServerLoop
    BackendStartup
      BackendRun
        PostgresMain
          exec_simple_query
            PortalRun
              PortalRunMulti
                PortalRunUtility
                  standard_ProcessUtility
                    DiscardCommand
                      ResetTempTableNamespace
                        RemoveTempRelations
                          performDeletion

2. DROP 命令

和前面 DISCARD 的命令执行调度逻辑一样，只是进入了 dropstmt 中。

...
  standard_ProcessUtility
    ProcessUtilitySlow
      ExecDropStmt
        RemoveRelations
          performMultipleDeletions

3. CREATE TEMP TABLE aa() ON COMMIT DROP;

create 这个ddl 执行完之后会直接调度 清理 temp table的清理操作。

PostmasterMain
  ServerLoop
    BackendStartup
      BackendRun
        PostgresMain
          exec_simple_query
            finish_xact_command // create temp table aa() on commit drop; 事务执行完 commit
              CommitTransactionCommand
                CommitTransaction  
                  PreCommit_on_commit_actions 
                    performMultipleDeletions // 直接调度清理

4. Backend 进程退出时

这里的调度逻辑是正常的temptable 被清理的是逻辑。

其中 ​​RemoveTempRelationsCallback​​​ 是在完成 temp-table 创建时 会通过 ​​before_shmem_exit​​ 注册一个进去，这个注册在进程正常/FATAL/ERROR 退出时都能在如下调用栈中执行，保障temp-table 被调度到清理。

PostmasterMain
  ServerLoop
    BackendStartup
      BackendRun
        PostgresMain
          proc_exit
            proc_exit_prepare
              shmem_exit
                RemoveTempRelationsCallback
                    RemoveTempRelations
                      performDeletion

5. TEMP-TABLE 在新启动的backend中创建时

会在创建的过程中，在前面创建临时表时提到的 ​​InitTempTableNamespace​​​函数中如果找到对应backend的 ​​pg_temp_<backendID>​​ 的 namespaceoid，则需要先删除旧的 temp-namespace 中的所有relation。

...
  standard_ProcessUtility
    ProcessUtilitySlow
      transformCreateStmt
        RangeVarGetAndCheckCreationNamespace
          RangeVarGetCreationNamespace
            AccessTempTableNamespace
              InitTempTableNamespace
                RemoveTempRelations
                  performDeletion

6. AUTOVACUUM 清理 temp-table

因为AUTOVACUUM 主要关注的是无主的temp-table，即创建该temp-table的 backend 已经被kill，却没有来得及执行 ​​performDeletion​​。

do_autovacuum
  checkTempNamespaceStatus
  performDeletion

在 ​​autovacuum​​​ 中，通过 ​​checkTempNamespaceStatus​​​ 函数确认这个temp-table 是否是无主的，如果是无主的则将该temp-table 的 oid 添加到 ​​orphan_oids​​​ 链表中，后续会循环 通过 ​​performDeletion​​ 进行清理。

关于判断一个 temp-table是否是无主的， ​​checkTempNamespaceStatus​​ 逻辑如下：

1. 通过​​GetTempNamespaceBackendId​​ 根据 temp-table 所处的 temp-namespace-id 拿到temp-namespace的名字，解析出temp-namespace 所处的 backendId。
2. 通过 ​​BackendIdGetProc​​ 从 shmInvalBuffer->procState 拿到一个proc指针。如果为NULL，说明这个 proc已经挂了，直接返回 idle

其中 ​​shmInvalBuffer​​ 是Shared cache invalidation memory segment，保存了整个 PG 进程组最新的 backend 列表，对其的访问和更新都是在 LWLOCK的保护下完成的。所以这里拿到的 backend 对应的 proc 指针一定是最新的。

1. 如果 backend还活着，可能是新启动的一个backend，需要进行更多的判读确保这个 temp-table 有效：

1. 活着的 proc 访问的数据库 id 和 当前 autovacuum 的数据库ID 不匹配，说明这个PROC 不是创建temp-table 的proc，返回idle即可。
2. 再此检查活着的 proc 访问的namespaceId 和 当前temp-table 所属的name-spaceid 是否匹配，不是则返回idle。
3. 最后返回 IN_USE，这才是 temp-table 所属的有效的PROC，这个temp-table 的 oid 才不会被添加到 ​​orphan_oids​​

TempNamespaceStatus
checkTempNamespaceStatus(Oid namespaceId)

  PGPROC     *proc;
  int     backendId;

  Assert(OidIsValid(MyDatabaseId));

  backendId = GetTempNamespaceBackendId(namespaceId);

  /* No such namespace, or its name shows its not temp? */
  if (backendId == InvalidBackendId)
    return TEMP_NAMESPACE_NOT_TEMP;

  /* Is the backend alive? */
  proc = BackendIdGetProc(backendId);
  if (proc == NULL)
    return TEMP_NAMESPACE_IDLE;

  /* Is the backend connected to the same database we are looking at? */
  if (proc->databaseId != MyDatabaseId)
    return TEMP_NAMESPACE_IDLE;

  /* Does the backend own the temporary namespace? */
  if (proc->tempNamespaceId != namespaceId)
    return TEMP_NAMESPACE_IDLE;

  /* Yup, so namespace is busy */
  return TEMP_NAMESPACE_IN_USE;

介绍完了几种删除链路，接下来看看 ​​performDeletion​​ 具体如何删除掉临时文件的？ 本质上还是通过 smgr去清理文件，需要分别清理catalog的数据和用户表的数据。

performDeletion 会先提取出要删除的relation 依赖的所有相关relation 的地址，通过 ​​deleteOneObject​​​ --> ​​doDeletion​​ 挨个清理，最后会在清理物理信息：

void
heap_drop_with_catalog(Oid relid)

  ...
  if (RELKIND_HAS_STORAGE(rel->rd_rel->relkind))
    RelationDropStorage(rel);
  ...

​​RelationDropStorage​​​ 这个函数会将 Relation的物理文件句柄信息 ​​rd_node​​​ 添加到 全局的 ​​pendingDeletes ​​链表中。

对于 ​​pendingDeletes​​​ 的清理时通过：​​CommitTransaction​​​ / ​​AbortTransaction​​​ 时调用 ​​smgrDoPendingDeletes​​​集中将当前事务内部所有的 pendingDeletes 的 文件​​rd_node​​​ 通过 ​​smgrdounlinkall​​ 掉。

到此就对整个temp-table 的 创建、写入、删除链路了解的差不多了，正常运行的场景中 还是 local-buffer的管理，通过local-buffer-manager 保证 对 temp-table 链路访问的高效；当然不写 WAL （不保证temp-table的可靠性）也是高性能必要的一部分。

更重要的是通过 temp-table的切入，能够对整个数据表 在 PG 内部执行器之下的访问 更为熟悉，也能够有效的得了解到PG 在存储层的组件实现。

Node.js 应用全链路追踪技术——[全链路信息获取]

全链路追踪技术的两个核心要素分别是 全链路信息获取 和 全链路信息存储展示。

Node.js 应用也不例外，这里将分成两篇文章进行介绍；第一篇介绍 Node.js 应用全链路信息获取， 第二篇介绍 Node.js 应用全链路信息存储展示。

一、Node.js 应用全链路追踪系统

目前行业内， 不考虑 Serverless 的情况下，主流的 Node.js 架构设计主要有以下两种方案：

• 通用架构：只做 ssr 和 bff，不做服务器和微服务；

• 全场景架构：包含 ssr、bff、服务器、微服务。

上述两种方案对应的架构说明图如下图所示：

在上述两种通用架构中，nodejs 都会面临一个问题，那就是：

在请求链路越来越长，调用服务越来越多，其中还包含各种微服务调用的情况下，出现了以下诉求：

• 如何在请求发生异常时快速定义问题所在；

• 如何在请求响应慢的时候快速找出慢的原因；

• 如何通过日志文件快速定位问题的根本原因。

我们要解决上述诉求，就需要有一种技术，将每个请求的关键信息聚合起来，并且将所有请求链路串联起来。让我们可以知道一个请求中包含了几次服务、微服务请求的调用，某次服务、微服务调用在哪个请求的上下文。

这种技术，就是Node.js应用全链路追踪。它是 Node.js 在涉及到复杂服务端业务场景中，必不可少的技术保障。

综上，我们需要Node.js应用全链路追踪，说完为什么需要后，下面将介绍如何做Node.js应用的全链路信息获取。

二、全链路信息获取

全链路信息获取，是全链路追踪技术中最重要的一环。只有打通了全链路信息获取，才会有后续的存储展示流程。

对于多线程语言如 Java 、 Python 来说，做全链路信息获取有线程上下文如 ThreadLocal 这种利器相助。而对于Node.js来说，由于单线程和基于IO回调的方式来完成异步操作，所以在全链路信息获取上存在天然获取难度大的问题。那么如何解决这个问题呢？

三、业界方案

由于 Node.js 单线程，非阻塞 IO 的设计思想。在全链路信息获取上，到目前为止，主要有以下 4 种方案：

• domain: node api；

• zone.js: Angular 社区产物；

• 显式传递：手动传递、中间件挂载；

• Async Hooks：node api；

而上述 4 个方案中，  domain 由于存在严重的内存泄漏，已经被废弃了；zone.js 实现方式非常暴力、API比较晦涩、最关键的缺点是 monkey patch 只能 mock api ，不能 mock language；显式传递又过于繁琐和具有侵入性；综合比较下来，效果最好的方案就是第四种方案，这种方案有如下优点：

• node 8.x 新加的一个核心模块，Node 官方维护者也在使用，不存在内存泄漏；

• 非常适合实现隐式的链路跟踪，入侵小，目前隐式跟踪的最优解；

• 提供了 API 来追踪 node 中异步资源的生命周期；

• 借助 async_hook 实现上下文的关联关系；

优点说完了，下面我们就来介绍如何通过 Async Hooks 来获取全链路信息。

四、Async Hooks【异步钩子】

4.1  Async Hooks 概念

Async Hooks 是 Node.js v8.x 版本新增加的一个核心模块，它提供了 API 用来追踪 Node.js 中异步资源的生命周期，可帮助我们正确追踪异步调用的处理逻辑及关系。在代码中，只需要写 import asyncHook from \'async_hooks\' 即可引入 async_hooks 模块。

一句话概括：async_hooks 用来追踪 Node.js 中异步资源的生命周期。

目前 Node.js 的稳定版本是 v14.17.0 。我们通过一张图看下 Async Hooks 不同版本的 api 差异。如下图所示：

从图中可以看到该 api 变动较大。这是因为从 8 版本到 14 版本，async_hooks 依旧还是 Stability: 1 - Experimental

但是没关系，要相信官方团队，这里我们的全链路信息获取方案是基于 Node v9.x 版本 api 实现的。对于 Async Hooks api 介绍和基本使用， 大家可以阅读官方文档，下文会阐述对核心知识的理解。

下面我们将系统介绍基于 Async Hooks 的全链路信息获取方案的设计和实现，下文统称为 zone-context 。

4.2  理解 async_hooks 核心知识

在介绍 zone-context 之前，要对 async_hooks 的核心知识有正确的理解，这里做了一个总结，有如下6点：

• 每一个函数(不论异步还是同步)都会提供一个上下文， 我们称之为 async scope ，这个认知对理解 async_hooks 非常重要；

• 每一个 async scope 中都有一个 asyncId ,它是当前 async scope 的标志，同一个的 async scope 中 asyncId 必然相同，每个异步资源在创建时， asyncId 自动递增，全局唯一；

• 每一个 async scope 中都有一个 triggerAsyncId ，用来表示当前函数是由哪个 async scope 触发生成的；

• 通过 asyncId 和 triggerAsyncId 我们可以追踪整个异步的调用关系及链路，这个是全链路追踪的核心；

• 通过 async_hooks.createHook 函数来注册关于每个异步资源在生命周期中发生的 init 等相关事件的监听函数；

• 同一个 async scope 可能会被调用及执行多次，不管执行多少次，其 asyncId 必然相同，通过监听函数，我们很方便追踪其执行的次数、时间以及上下文关系。

上述6点知识对于理解 async_hooks 是非常重要的。正是因为这些特性，才使得 async_hooks 能够优秀的完成Node.js 应用全链路信息获取。

到这里，下面就要介绍 zone-context 的设计和实现了，请和我一起往下看。

五、zone-context

5.1  架构设计

整体架构设计如下图所示：

核心逻辑如下：异步资源（调用）创建后，会被 async_hooks 监听到。监听到后，对获取到的异步资源信息进行处理加工，整合成需要的数据结构，整合后，将数据存储到 invoke tree 中。在异步资源结束时，触发 gc 操作，对 invoke tree 中不再有用的数据进行删除回收。

从上述核心逻辑中，我们可以知道，此架构设计需要实现以下三个功能：

• 异步资源（调用）监听

• invoke tree

• gc

下面开始逐个介绍上述三个功能的实现。

5.2  异步资源（调用）监听

如何做到监听异步调用呢？

这里用到了 async_hooks （追踪 Node.js 异步资源的生命周期）代码实现如下：

asyncHook
  .createHook({
    init(asyncId, type, triggerAsyncId) {
      // 异步资源创建（调用）时触发该事件
    },
  })
  .enable()

是不是发现此功能实现非常简单，是的哦，就可以对所有异步操作进行追踪了。

介绍完异步调用监听，下面将介绍 invoke tree 的实现。

5.3 invoke tree 设计和异步调用监听结合

5.3.1 设计

invoke tree 整体设计思路如下图所示：

具体代码如下：

interface ITree {  [key: string]: {    // 调用链路上第一个异步资源asyncId    rootId: number    // 异步资源的triggerAsyncId    pid: number    // 异步资源中所包含的异步资源asyncId    children: Array<number>  }} const invokeTree: ITree = {}

创建一个大的对象 invokeTree， 每一个属性代表一个异步资源的完整调用链路。属性的key和value代表含义如下：

• 属性的 key 是代表这个异步资源的 asyncId。

• 属性的 value 是代表这个异步资源经过的所有链路信息聚合对象，该对象中的各属性含义请看上面代码中的注释进行理解。

通过这种设计，就能拿到任何一个异步资源在整个请求链路中的关键信息。收集根节点上下文。

5.3.2 和异步调用监听结合

虽然 invoke tree 设计好了。但是如何在 异步调用监听的 init 事件中，将 asyncId 、 triggerAsyncId 和 invokeTree 关联起来呢？

代码如下：

asyncHook
  .createHook({
    init(asyncId, type, triggerAsyncId) {
      // 寻找父节点
      const parent = invokeTree[triggerAsyncId]
      if (parent) {
        invokeTree[asyncId] = {
          pid: triggerAsyncId,
          rootId: parent.rootId,
          children: [],
        }
        // 将当前节点asyncId值保存到父节点的children数组中
        invokeTree[triggerAsyncId].children.push(asyncId)
      }
    }
  })
  .enable()

大家看上面代码，整个代码大致有以下几个步骤：

1. 当监听到异步调用的时候，会先去 invokeTree 对象中查找是否含有 key 为 triggerAsyncId 的属性；

2. 有的话，说明该异步调用在该追踪链路中，则进行存储操作，将 asyncId 当成 key ， 属性值是一个对象，包含三个属性，分别是 pid、rootId、children ， 具体含义上文已说过；

3. 没有的话，说明该异步调用不在该追踪链路中。则不进行任何操作，如把数据存入 invokeTree 对象；

4. 将当前异步调用 asyncId 存入到 invokeTree 中 key 为 triggerAsyncId 的 children 属性中。

至此，invoke tree 的设计、和异步调用监听如何结合，已经介绍完了。下面将介绍 gc 功能的设计和实现。

5.4 gc

5.4.1 目的

我们知道，异步调用次数是非常多的，如果不做 gc 操作，那么 invoke tree 会越来越大，node应用的内存会被这些数据慢慢占满，所以需要对 invoke tree 进行垃圾回收。

5.4.2 设计

gc 的设计思想主要如下：当异步资源结束的时候，触发垃圾回收，寻找此异步资源触发的所有异步资源，然后按照此逻辑递归查找，直到找出所有可回收的异步资源。

话不多说，直接上代码， gc 代码如下：

interface IRoot {
  [key: string]: Object
}

// 收集根节点上下文
const root: IRoot = {}

function gc(rootId: number) {
  if (!root[rootId]) {
    return
  }

  // 递归收集所有节点id
  const collectionAllNodeId = (rootId: number) => {
    const {children} = invokeTree[rootId]
    let allNodeId = [...children]
    for (let id of children) {
      // 去重
      allNodeId = [...allNodeId, ...collectionAllNodeId(id)]
    }
    return allNodeId
  }

  const allNodes = collectionAllNodeId(rootId)

  for (let id of allNodes) {
    delete invokeTree[id]
  }

  delete invokeTree[rootId]
  delete root[rootId]
}

gc 核心逻辑：用 collectionAllNodeId 递归查找所有可回收的异步资源（ id ）。然后再删除 invokeTree 中以这些 id 为 key 的属性。最后删除根节点。

root 其实是我们对某个异步调用进行监听时，设置的一个根节点对象，这个节点对象可以手动传入一些链路信息，这样可以为全链路追踪增加其他追踪信息，如错误信息、耗时时间等。

5.5 万事具备，只欠东风

我们的异步事件监听设计好了， invoke tree 设计好了，gc 也设计好了。那么如何将他们串联起来呢？比如我们要监听某一个异步资源，那么我们要怎样才能把 invoke tree 和异步资源结合起来呢？

这里需要三个函数来完成结合，分别是 ZoneContext 、 setZoneContext 、 getZoneContext。下面来一一介绍下这三个函数：

5.5.1 ZoneContext

这是一个工厂函数，用来创建异步资源实例的，代码如下所示：

// 工厂函数
async function ZoneContext(fn: Function) {
  // 初始化异步资源实例
  const asyncResource = new asyncHook.AsyncResource(\'ZoneContext\')
  let rootId = -1
  return asyncResource.runInAsyncScope(async () => {
    try {
      rootId = asyncHook.executionAsyncId()
      // 保存 rootId 上下文
      root[rootId] = {}
      // 初始化 invokeTree
      invokeTree[rootId] = {
        pid: -1, // rootId 的 triggerAsyncId 默认是 -1
        rootId,
        children: [],
      }
      // 执行异步调用
      await fn()
    } finally {
      gc(rootId)
    }
  })
}

大家会发现，在此函数中，有这样一行代码： 

const asyncResource = new asyncHook.AsyncResource(\'ZoneContext\') 

这行代码是什么含义呢？

它是指我们创建了一个名为 ZoneContext 的异步资源实例，可以通过该实例的属性方法来更加精细的控制异步资源。

调用该实例的 runInAsyncScope方法，在runInAsyncScope 方法中包裹要传入的异步调用。可以保证在这个资源（ fn ）的异步作用域下，所执行的代码都是可追踪到我们设置的 invokeTree 中，达到更加精细控制异步调用的目的。在执行完后，进行gc调用，完成内存回收。

5.5.2 setZoneContext

用来给异步调用设置额外的跟踪信息。代码如下：

function setZoneContext(obj: Object) {
  const curId = asyncHook.executionAsyncId()
  let root = findRootVal(curId)
  Object.assign(root, obj)
}

通过 Object.assign(root, obj) 将传入的 obj 赋值给 root 对象中， key 为 curId 的属性。这样就可以给我们想跟踪的异步调用设置想要跟踪的信息。

5.5.3 getZoneContext

用来拿到异步调的 rootId 的属性值。代码如下：

function findRootVal(asyncId: number) {
  const node = invokeTree[asyncId]
  return node ? root[node.rootId] : null
}
function getZoneContext() {
  const curId = asyncHook.executionAsyncId()
  return findRootVal(curId)
}

通过给 findRootVal 函数传入 asyncId 来拿到 root 对象中 key 为 rootId 的属性值。这样就可以拿到当初我们设置的想要跟踪的信息了，完成一个闭环。

至此，我们将 Node.js应用全链路信息获取的核心设计和实现阐述完了。逻辑上有点抽象，需要多去思考和理解，才能对全链路追踪信息获取有一个更加深刻的掌握。

最后，我们使用本次全链路追踪的设计实现来展示一个追踪 demo 。

5.6 使用 zone-context

5.6.1 确定异步调用嵌套关系

为了更好的阐述异步调用嵌套关系，这里进行了简化，没有输出 invoke tree 。例子代码如下：

// 对异步调用A函数进行追踪
ZoneContext(async () => {
  await A()
})

// 异步调用A函数中执行异步调用B函数
async function A() {
  // 输出 A 函数的 asyncId
  fs.writeSync(1, `A 函数的 asyncId -> ${asyncHook.executionAsyncId()}\\n`)
  Promise.resolve().then(() => {
    // 输出 A 函数中执行异步调用时的 asyncId
    fs.writeSync(1, `A 执行异步 promiseC 时 asyncId 为 -> ${asyncHook.executionAsyncId()}\\n`)
    B()
  })
}

// 异步调用B函数中执行异步调用C函数
async function B() {
  // 输出 B 函数的 asyncId
  fs.writeSync(1, `B 函数的 asyncId -> ${asyncHook.executionAsyncId()}\\n`)
  Promise.resolve().then(() => {
    // 输出 B 函数中执行异步调用时的 asyncId
    fs.writeSync(1, `B 执行异步 promiseC 时 asyncId 为 -> ${asyncHook.executionAsyncId()}\\n`)
    C()
  })
}

// 异步调用C函数
function C() {
  const obj = getZoneContext()
  // 输出 C 函数的 asyncId
  fs.writeSync(1, `C 函数的 asyncId -> ${asyncHook.executionAsyncId()}\\n`)
  Promise.resolve().then(() => {
    // 输出 C 函数中执行异步调用时的 asyncId
    fs.writeSync(1, `C 执行异步 promiseC 时 asyncId 为 -> ${asyncHook.executionAsyncId()}\\n`)
  })
}

输出结果为：

A 函数的 asyncId -> 3
A 执行异步 promiseA 时 asyncId 为 -> 8
B 函数的 asyncId -> 8
B 执行异步 promiseB 时 asyncId 为 -> 13
C 函数的 asyncId -> 13
C 执行异步 promiseC 时 asyncId 为 -> 16

只看输出结果就可以推出以下信息：

• A 函数执行异步调用后， asyncId 为 8 ，而 B 函数的 asyncId 是 8 ，这说明， B 函数是被 A 函数 调用；

• B 函数执行异步调用后， asyncId 为 13 ，而 C 函数的 asyncId 是 13 ，这说明， C 函数是被 B 函数 调用；

• C 函数执行异步调用后， asyncId 为 16 ， 不再有其他函数的 asyncId 是 16 ，这说明， C 函数中没有调用其他函数；

• 综合上面三点，可以知道，此链路的异步调用嵌套关系为：A —> B -> C；

至此，我们可以清晰快速的知道谁被谁调用，谁又调用了谁。

5.6.2 额外设置追踪信息

在上面例子代码的基础下，增加以下代码：

ZoneContext(async () => {
  const ctx = { msg: \'全链路追踪信息\', code: 1 }
  setZoneContext(ctx)
  await A()
})

function A() {
  // 代码同上个demo
}

function B() {
  // 代码同上个demo
  D（）
}

// 异步调用C函数
function C() {
  const obj = getZoneContext()
  Promise.resolve().then(() => {
    fs.writeSync(1, `getZoneContext in C -> ${JSON.stringify(obj)}\\n`)
  })
}

// 同步调用函数D
function D() {
  const obj = getZoneContext()
  fs.writeSync(1, `getZoneContext in D -> ${JSON.stringify(obj)}\\n`)
}

输出以下内容：呈现代码宏出错:参数

\'com.atlassian.confluence.ext.code.render.InvalidValueException\'的值无效。

getZoneContext in D -> {"msg":"全链路追踪信息","code":1}

getZoneContext in C-> {"msg":"全链路追踪信息","code":1}

可以发现， 执行 A 函数前设置的追踪信息后，调用 A 函数， A 函数中调用 B 函数， B 函数中调用 C 函数和 D 函数。在 C 函数和 D 函数中，都能访问到设置的追踪信息。

这说明，在定位分析嵌套的异步调用问题时，通过 getZoneContext 拿到顶层设置的关键追踪信息。可以很快回溯出，某个嵌套异步调用出现的异常，

是由顶层的某个异步调用异常所导致的。

5.6.3 追踪信息大而全的 invoke tree

例子代码如下：

ZoneContext(async () => {
  await A()
})
async function A() {
  Promise.resolve().then(() => {
    fs.writeSync(1, `A 函数执行异步调用时的 invokeTree -> ${JSON.stringify(invokeTree)}\\n`)
    B()
  })
}
async function B() {
  Promise.resolve().then(() => {
    fs.writeSync(1, `B 函数执行时的 invokeTree -> ${JSON.stringify(invokeTree)}\\n`)
  })
}

输出结果如下：

A 函数执行异步调用时的 invokeTree -> {"3":{"pid":-1,"rootId":3,"children":[5,6,7]},"5":{"pid":3,"rootId":3,"children":[10]},"6":{"pid":3,"rootId":3,"children":[9]},"7":{"pid":3,"rootId":3,"children":[8]},"8":{"pid":7,"rootId":3,"children":[]},"9":{"pid":6,"rootId":3,"children":[]},"10":{"pid":5,"rootId":3,"children":[]}}

B 函数执行异步调用时的 invokeTree -> {"3":{"pid":-1,"rootId":3,"children":[5,6,7]},"5":{"pid":3,"rootId":3,"children":[10]},"6":{"pid":3,"rootId":3,"children":[9]},"7":{"pid":3,"rootId":3,"children":[8]},"8":{"pid":7,"rootId":3,"children":[11,12]},"9":{"pid":6,"rootId":3,"children":[]},"10":{"pid":5,"rootId":3,"children":[]},"11":{"pid":8,"rootId":3,"children":[]},"12":{"pid":8,"rootId":3,"children":[13]},"13":{"pid":12,"rootId":3,"children":[]}}

根据输出结果可以推出以下信息：

1、此异步调用链路的 rootId （初始 asyncId ，也是顶层节点值） 是 3

2、函数执行异步调用时，其调用链路如下图所示：

3、函数执行异步调用时，其调用链路如下图所示：

从调用链路图就可以清晰看出所有异步调用之间的相互关系和顺序。为异步调用的各种问题排查和性能分析提供了强有力的技术支持。

六、总结

到这，关于Node.js 应用全链路信息获取的设计、实现和案例演示就介绍完了。全链路信息获取是全链路追踪系统中最重要的一环，当信息获取搞定后，下一步就是全链路信息存储展示。

我将在下一篇文章中阐述如何基于 OpenTracing 开源协议来对获取的信息进行专业、友好的存储和展示。