PostgreSQL云数据库：微信支付业务系统架构的故事

2015年之前，微信支付业务快速发展，需要一个数据库来安全、高效地支撑微信支付业务系统的核心业务。这个重任落到了腾讯数据库团队的肩上。研究 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（协调节点）的请求都会被应用到GTM以获取必要的gxid（全局事务ID）和gsnapshot（全局快照）信息，并将这些信息与SQL语句本身一起发送到DN 。 。 （Datanode数据库节点）执行。另外，根据PostgreSQL-XC管理机制，gxid只能获取主DN，而备用DN没有自己的gxid，因此无法提供只读服务，这也是对系统的浪费。 。

图1

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

图2

2、只读备机的实现与优化

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

1. 普通KN和只读KN的分离。
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. 分片表中的每条记录都使用 Hash(row) % #shardmap item 通过查询 shardmap 存储库的 DN 来确定该记录存储在哪个 shardid 中。
   3. 在每个 DN 中，存储有关分配给该节点的 shardid 的信息以确定可见性。

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

   图 5

   4。解决数据倾斜

   数据倾斜是指在分布式数据库系统中，有些DN会因为物理节点、哈希或分片的分布而导致物理空间不足，而另一些DN则有足够的物理空间。例如，如果以商户作为分发密钥，京东每天的数据量肯定会与正常的电商公司有很大不同。也许来自大型商家一个月的数据将填满 DN 的物理空间。在这种情况下，唯一的办法就是关闭系统并扩容。因此，我们必须有有效的手段来解决数据失真问题，保证在表中数据分布不均匀的情况下系统仍然能够高效稳定的运行。

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

   1. 包含一个或多个 DN
   2. 每个组都有一个分片图
   3. 构建受保护表时，您可以指定一个存储组，这意味着它存储在组 1 或 2 中
   4. 可以访问CN

   上也存储了所有组和所有表的访问方式信息

图6

针对系统中数据量较大的情况，采用不同的数据分布逻辑（如如图7）：普通用户使用默认的数据分发逻辑，即：

Shardid = Hash(merchantid) % #shardmap
复制代码

大商户使用定制的数据分发逻辑，即：

Shardid = Hash(merchantid) % #shardmap + fcreate_timedayoffset from 1970-01-01
复制代码

图7

通过在大商户逻辑中添加数据偏移量分布，同一用户的数据可以均匀分布在一个组内的多个节点上。这有效解决了数据分布不均匀的问题。

示例如下（如图8所示）：

图8

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

某企业在列表查询场景中收到如下SQL查询： ❙ ❙ ❙在微信支付场景中，某交易者每天有300W的数据量，每月有9000W以上的数据量。这意味着PostgreSQL需要在数据层面快速排序9000W的数据，业务逻辑需要秒级输出才能快速检索排序结果。 。

为此，我们提供了表定义的解决方案，即创建集群分布表。根据上述需求，可以按月进行分表，即每月一张表，并在finish_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。这些执行器用于执行执行计划片段
• 系统会创建一个计划队列，所有执行器都会在作业队列中等待计划
• 每个执行器对应一个作业结果队列。当执行器发出结果时，它将结果指针挂在结果队列上。计划队列、结果队列和计划片段执行结果都存储在共享内存管理器中，因此所有进程都可以访问这些结构
• 当Postgres会话进程接收到sql时，它会判断是否可以并行并划分任务;当结果在结果队列中时，读取返回

我们完成了优化计算 Sub:

• Seqscan
• Hash join
• 查询到 Nestloop'›Remogg›查询到 Nestloop❙›
• Sort Agg
• Connect

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

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

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

两地三中心容灾是金融级数据库的必备特性。对于金融业务数据的安全来说，这是最基本也是最重要的要求。因此，为了保证高效、稳定的容灾选择，PostgreSQL-XZ还构建了两地三中心的全自动容灾功能。两地三中心的具体部署结构如下：

同城节点之间建立强同步，保证数据强一致性；异步专用网络同步用于远程位置。

在节点中，CAgent 部署在每台物理计算机上。代理收集并报告机器状态并执行相应的警报触发和切换功能。

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

JCenter和CAgent是两地三中心的控制和管理节点。

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

当一台主机出现故障并失效时，JCenter会优先同城的备机升级为主。

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

作者：腾讯云+社区