微信支付系统架构：云数据库PostgreSQL助力核心业务稳定运行

2016年7月，腾讯云发布了云数据库PostgreSQL，提供腾讯自研的核心优化版和社区版，以及分布式集群。架构有两种选择（分布式集群内部代号PostgreSQL-XZ）。目前，云数据库PostgreSQL在腾讯大数据平台、广电通、腾讯视频等腾讯多个核心业务中稳定运行。

腾讯自研PostgreSQL分布式集群PostgreSQL-XZ

腾讯PostgreSQL-XZ是从PostgreSQL-XC社区版本地化而来，可以支持数据库集群的水平扩展。虽然PostgreSQL-XC非常强大，但在性能、可扩展性、安全性和运维方面仍然存在明显的瓶颈。经过多年的积累，腾讯PostgreSQL在这些方面都有了很大的改进和加强。作为微信支付使用的核心数据库，腾讯PostgreSQL定位为安全、高效、稳定、可靠的数据库集群。下面将以腾讯PostgreSQL-XZ为代表介绍腾讯自研PostgreSQL所做的优化和改进。

1。事务管理系统的优化

PostgreSQL-XC在事务管理系统解决方案本身上有一个明显的不足，即事务管理机制会成为系统的瓶颈，GTM（Global Transaction Manager）会限制扩展系统。如图1所示，任何到达CN（Coordinator协调节点）的请求都会向GTM申请必要的gxid（全局事务ID）和gsnapshot（全局快照）信息，并将这些信息连同SQL 语句。 （Datanode数据库节点）用于执行。而且，根据PostgreSQL-XC的管理机制，只有主DN才能获取gxid，备用DN没有自己的gxid，因此无法提供只读服务，这也是对系统的浪费。

图1

腾讯PostgreSQL-XZ改进了事务管理机制。改进后，CN不再从GTM获取gxid和gsnapshot。每个节点使用自己的本地xid（事务ID）和gsnapshot（快照）。这样GTM就不会成为系统的瓶颈；另外，DN备份机还可以提供只读服务，充分利用空闲的系统资源。如图2所示，优化后的事务管理系统架构如下：

图2

2.备机只读实现及优化

当然，事务管理系统的优化是基础备用 DN 只读。但原来的集群不具备加载、调度等能力。在这方面，我们也做了很多创新，概括起来就是：

1. 普通 CN 和只读 CN 的分离。
2. 普通 CN 存储主 DN 的元数据信息
3. 只读 CN 存储备份 DN 的元数据信息
4. 采用 DN 之间的热备模式（热备份保护）进行日志同步 方式，集群可以提供备用DN只读功能和智能负载选项，充分利用系统资源。

   图3

   3.业务中断最小化的扩容计划

   业务的快速增长必然需要资源扩张。社区版本的实施使得扩容成本很高，并且需要长期的业务中断。因为，在社区版本 PostgreSQL-XC 中，一条记录的存储节点是通过 DN=Hash(row) % nofdn:

   来确定的，也就是说，先计算分布列的哈希值，然后使用该值对集群中的节点数取模来确定要记录的节点（图 4）。

   该方案虽然简单，但实际使用中需要较长时间的停机扩容。这是因为扩容后节点数量会增加，无法按照原来的分布逻辑读写数据，必须重新分布节点数据。重新平衡数据需要关闭并手动迁移并重新平衡到每个节点。对于规模较大的交易系统，由于原始节点存储大量数据，重新平衡过程可能需要几天的时间。我想这对于公司来说绝对是难以承受的。

   图4

   所以我们介绍一种新的切板方法——切板。 Shardedtable的数据分布如下（图5）：

   1. 引入了一个抽象的中间层——分片映射。 Shard Map的每个元素都存储了shardid和DN之间的映射关系。
   2. Sharded 表中的每个条目都使用 Hash(row) % #shardmap-entry 通过查询 shardmap 存储的 DN 来确定该条目存储在哪个 shardid 中。
   3. 每个 DN 存储分配给该节点的 shardid 信息以确定可见性。

   采用上述方案，在扩容新节点时，只需将部分shardmap中的shardid映射到新添加的节点上，并将相应的数据移到那里即可。扩容只需要改变shardmap中的关联关系，时间从几天缩短到几秒。

   图 5

   4。数据倾斜解决方案

   数据倾斜是指在分布式数据库系统中，由于物理节点、哈希或分片分布等原因，会导致部分DN物理空间不足，而另一些DN剩余物理空间较大。例如，如果以零售商作为分发关键，京东每天的数据量肯定会与常规电子商务公司的数据量完全不同。也许大型杂货店一个月的数据将填满 DN 的物理空间。在这种情况下，唯一的办法就是关闭系统并扩容。因此，我们必须有一种有效的手段来解决数据倾斜，保证在表数据分布不均匀的情况下系统仍然能够高效稳定的运行。

   首先我们将系统的DN进行分组（如下图6所示）。每组：

   1. 包含一个或多个 DN
   2. 每个组都有一个分片图
   3. 构建分片表时，可以指定存储组，即要么存储在 group1 中，要么存储在 groupCN 可以访问的地方CN

   也存储了所有组以及所有表的访问方式信息

图6

针对系统中数据量较大的情况，专门对大用户进行了识别，并采用不同的数据分布逻辑为其创建了白名单（如如图7）：普通用户采用标准数据分发逻辑，即：

Shardid = Hash(merchantid) % #shardmap

大型零售商采用自定义数据分发逻辑，即：

Shardid = Hash(merchantid) ) % #shardmap + fcreate_timedayoffset from 1970-01-01

图7

通过在大商户组中分配逻辑添加日期偏移量，实现同一用户数据在多个节点数据组之间的统一分配。这有效解决了数据分布不均匀的问题。

以下为示例（如图8）：

图8

5.9000W条记录高效排序解决方案

公司会在列表中收到如下查询场景：在微信支付中场景：某商户每天有300W数据，一个月有9000W以上数据。这意味着PostgreSQL需要在数据层面快速排序9000W的数据，业务逻辑需要秒级输出才能快速获得排序结果。 。

为此我们提供了表定义的解决方案，即建立集群分区表。根据上述需求，可以按月对表进行分区，即每月一张表，并在ffinish_time排序字段上创建索引，这样就可以利用该索引扫描每个分区。

CN 对一系列执行计划进行优化后，将订单下推并限制 offset 子句给 DN；当在DN上执行相应的SQL时，使用Merge Append算子对每个子表的执行结果进行汇总并输出。该运算符本身将确保输出是有序的，即子表被索引和扫描。同时Merge Append将各个子表的结果进行合并，保证节点本身的结果是有序的。 CN还使用Merge Append将多个DN的结果进行合并，保证整个输出结果是有序的，从而完成整个排序过程。

以下是我们排序的性能测试结果：

在24核CPU、64G内存型号上测试，最短25ms可完成9000W数据的排序，QPS最高可达5400

6.并行优化

随着现在硬件的发展，系统资源越来越丰富。多CPU和大内存已经成为标准的系统配置。充分利用这些资源可以有效提高处理效率、优化性能。腾讯于 2014 年底开始优化 PostgreSQL 多核执行。

当前的 PostgreSQL 9.6 社区版本也会包含一些并行化功能，但它们没有我们的那么丰富。下面介绍一下腾讯PostgreSQL并行化的原理和效果：

• 系统创建了一个全局共享内存管理器。使用位图控制算法进行控制
• 在系统启动时创建带有特定数据的执行器。这些Executor用于执行执行计划的片段
• 系统会创建一个计划队列，所有Executor都会在任务队列上等待计划
• 每个Executor对应一个任务结果队列。当执行器读取结果时，它将结果的指针挂在结果队列中。计划队列、结果队列和计划分片执行结果都存储在共享内存管理器中，因此所有进程都可以访问这些结构
• 当Postgres会话进程收到sql时，它会确定是否可以并行并分配任务；当结果队列中有结果时，读取返回

我们已经完成了优化计算 Sub:

• Seqscan
• Hash join
• Nestloop joinNestloop joineA gg
• Sort Agg
• 附

通过在24核CPU、64G内存的机型上运行测试，各算子的优化结果：

总体来说性能比优化前提升了10-12倍，优化效果比较明显。

7。腾讯PostgreSQL-XZ的两地三中心容灾

两地三中心容灾是金融级数据库的重要特性。对于金融业务数据安全来说，是最基本也是最重要的要求。因此，我们为了保证高效稳定的数据容灾能力，还为PostgreSQL-XZ构建了两地三中心完整的自动容灾能力。两地三中心的具体实现结构如下：

同城节点之间采用强同步，保证数据强一致性；异地采用专网异步同步。

在节点中，CAgent是在每台物理机上实现的。 Agent收集机器状态并上报，并执行相应的报警和切换执行功能。

每个IDC至少实现一个JCenter。 JCenter负责收集并上报各个agent上报的状态给ZK集群。这多个 JCenter 中只有一个是活动的。除了状态报告之外，主用 JCenter 还执行故障排除和耦合。当主用JCenter出现异常后，系统自动选择一个备份JCenter通过ZK提升为主用。

JCenter和CAgent是两地三中心的控制和统治节点。

对于数据库节点，CN在每个IDC中至少实现一个。每个中心部署一台DN，一台为主机，另外两台作为备份机并行放置在主机上，一台为同步备份机，另一台为异步备份机。

当主机出现故障宕机时，JCenter优先同城备机升级为主。

目前，腾讯云已提供云数据库PostgreSQL内测，并将提供核心优化版和社区版两个版本，以满足更多客户的需求。