微信支付商户系统架构背后的故事

本是古典何须时尚 2022-05-20 02:20 238阅读 0赞

![640?wx\_fmt=gif][640_wx_fmt_gif]

![640?wx\_fmt=png][640_wx_fmt_png]

### 一.事务管理系统的优化 ###

PostgreSQL-XC在事务管理系统方案本身有一个明显的缺点，那就是事务管理机制会成为系统的瓶颈，GTM（Global Transaction Manager全局事务管理器）会限制系统的扩展规模。如图1所示，是每个请求过来CN(Coordinator 协调节点)都会向GTM申请必需的gxid（全局事务ID）和gsnapshot（全局快照）信息，并把这些信息随着SQL语句本身一起发往DN（Datanode数据库节点）进行执行。另外，PostgreSQL-XC的管理机制，只有主DN才会获取的gxid，而备DN没有自己的gxid，因此无法提供只读服务，对系统也是不小的浪费。

![640?wx\_fmt=jpeg][640_wx_fmt_jpeg]

图1

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

![640?wx\_fmt=jpeg][640_wx_fmt_jpeg 1]

图2

### 二.备机只读实现与优化 ###

![640?wx\_fmt=png][640_wx_fmt_png 1]

通过这些方式，集群可以提供带有智能负载能力的备DN只读功能，充分利用系统资源。

![640?wx\_fmt=png][640_wx_fmt_png 2]

图3

### 三.业务最小中断的扩容方案 ###

业务的快速增长不可避免的需要对资源进行扩容，社区版本的实现使得扩容成本高昂，需要对业务进行长时间的中断。因为，在社区版本PostgreSQL-XC中，通过 `DN=Hash(row) % nofdn`的方式决定一条记录的存储节点：

也就是说，先对分布列计算hash值，然后使用这个值对集群中的节点个数取模来决定记录去哪个节点（如图4）。

这种方案简单，但实际应用中需要长时间停机扩容。这是因为，扩容后节点数会变多，数据无法按照原有的分布逻辑进行读写，需要重新分布节点数据。而再均衡数据需要停机并手工迁移再均衡到各个节点。对于规模较大的交易系统来说，由于原有节点存储的是海量数据，再均衡过程可能会持续好几天。相信这是业务完全无法忍受的。

![640?wx\_fmt=jpeg][640_wx_fmt_jpeg 2]

图4

![640?wx\_fmt=png][640_wx_fmt_png 3]

![640?wx\_fmt=png][640_wx_fmt_png 4]

图5

### 四.数据倾斜解决方案 ###

数据倾斜是指，在分布式数据库系统中会因为物理节点、hash或shard分布原因，导致某些DN物理空间不足，而另外的物理空间剩余较大。例如，如果以商户作为分布key，京东每天的数据量和一个普通电商的数据量肯定是天地差别。可能某个大商户一个月的数据就会把一个DN的物理空间塞满，这时系统只有停机扩容一条路。因此我们必须要有一个有效的手段来解决数据倾斜，保证在表数据分布不均匀时系统仍然能够高效稳定的运行。

![640?wx\_fmt=png][640_wx_fmt_png 5]

![640?wx\_fmt=png][640_wx_fmt_png 6]

图6

对于系统中数据量较大用户进行特别的识别，并为他们创建白名单，使用不同的数据分布逻辑（如下图7）：普通用户使用默认的数据分布逻辑，也就是：

`Shardid = Hash(merchantid) % #shardmap`

大商户使用定制的数据分布逻辑，也就是：

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

![640?wx\_fmt=png][640_wx_fmt_png 7]

图7

通过在大商户group分布逻辑中加入日期偏移，来实现同一个用户的数据在group内部多个节点间均匀分布。从而有效的解决数据分布不均匀问题。

下面是一个例子（如下图8）：

![640?wx\_fmt=jpeg][640_wx_fmt_jpeg 3]

图8

### 五.9000W记录高效排序解决方案 ###

业务在列表查询场景下会收到如下的查询SQL：

![640?wx\_fmt=png][640_wx_fmt_png 8]

在微信支付的场景中，某个商户每天的数据有300W，一个月数据超过9000W条，也就是说PostgreSQL需要面向一个9000W数据级数据进行快速排序，而且业务逻辑要求需要秒级输出，快速获取排序结果。

![640?wx\_fmt=png][640_wx_fmt_png 9]

为此，我们提供表定义方案，即建立集群分区表。根据上述需求，可以采用按月分表，即每个月一张表，并对排序字段ffinish\_time建立索引，这样每个分区进行扫描是可以使用索引。

![640?wx\_fmt=png][640_wx_fmt_png 10]

我们再通过一系列执行计划的优化，CN下推order by和limit offset子句到DN；DN上在执行对应的sql使用使用Merge Append算子对各个子表执行的结果进行汇总输出，这个算子本身会保证输出是有序的，也就是说对子表进行索引扫描，同时Merge Append又对各个子表的结果进行归并，进而保证节点本身的结果是排序的。CN对多个DN的结果同样使用Merge Append进行归并，保证整个输出结果是有序的，从而完成整个排序过程。

![640?wx\_fmt=jpeg][640_wx_fmt_jpeg 4]

下面是我们对排序进行的性能测试结果：

![640?wx\_fmt=png][640_wx_fmt_png 11]

![640?wx\_fmt=png][640_wx_fmt_png 12]

通过在24核CPU，64G内存的机型上进行测试，9000W数据的排序在最短可以在25 ms内完成，QPS最高可达5400。

### 六.并行优化 ###

随着当前硬件的发展，系统资源越来越丰富，多CPU大内存成了系统标配，充分利用这些资源可以有效的提升的处理效率优化性能。腾讯在2014年底开始进行PostgreSQL多核执行优化。

目前PostgreSQL9.6社区版也会包含部分并行化特性，但是没有我们这边这么丰富，下面介绍下腾讯PostgreSQL并行化的原理和效果：

![640?wx\_fmt=jpeg][640_wx_fmt_jpeg 5]

![640?wx\_fmt=png][640_wx_fmt_png 13]

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

![640?wx\_fmt=png][640_wx_fmt_png 14]

![640?wx\_fmt=png][640_wx_fmt_png 15]

![640?wx\_fmt=png][640_wx_fmt_png 16]

![640?wx\_fmt=png][640_wx_fmt_png 17]

![640?wx\_fmt=png][640_wx_fmt_png 18]

整体来说性能普遍是优化前的10-12倍，优化的效果比较明显。

### 七.腾讯PostgreSQL-XZ的两地三中心容灾 ###

两地三中心容灾是金融级数据库的必备能力，对于金融类业务数据安全是最基本也是最重要诉求，因此我们为了保障高效稳定的数据容灾能力，也为PostgreSQL-XZ建设了完善的两地三中心自动容灾能力。具体的两地三中心部署结构如下：

![640?wx\_fmt=jpeg][640_wx_fmt_jpeg 6]

同城节点间采用强同步方式，保障数据强一致；异地采用专网异步同步。

![640?wx\_fmt=png][640_wx_fmt_png 19]

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

在主机故障宕机时，JCenter优先选择同城的备机升主。

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

**公众号推荐:**

![640?wx\_fmt=jpeg][640_wx_fmt_jpeg 7]

![640?wx\_fmt=jpeg][640_wx_fmt_jpeg 8]

[640_wx_fmt_gif]: /images/20220520/e5dd8fe6c47d437fa38f4016aa5e959d.png
[640_wx_fmt_png]: /images/20220520/fbf801eef4bf4c7eb1fa144fc36ad174.png
[640_wx_fmt_jpeg]: /images/20220520/1808d6fb91c844458ce4ef33deb4e51e.png
[640_wx_fmt_jpeg 1]: /images/20220520/7a955672a09449229ac3ca9536a2b030.png
[640_wx_fmt_png 1]: /images/20220520/709b0b79f4d141429b366855a0ee522b.png
[640_wx_fmt_png 2]: /images/20220520/b5b67ed18fd04c04bff5aa5319796a88.png
[640_wx_fmt_jpeg 2]: /images/20220520/cc91aae13a8147ec8ea07e78e0a15aee.png
[640_wx_fmt_png 3]: /images/20220520/54146b908a5746ffaea7acb5fc1b79c1.png
[640_wx_fmt_png 4]: /images/20220520/b3e7b766b56448f5a5d2d243518f8993.png
[640_wx_fmt_png 5]: /images/20220520/43e416ab2ab6462cb9eab06b5e8cd84e.png
[640_wx_fmt_png 6]: /images/20220520/e5c8d4c7543c4b528a38d4f3271ba612.png
[640_wx_fmt_png 7]: /images/20220520/f97a3ee9349c49f280e9c738c5aa0e73.png
[640_wx_fmt_jpeg 3]: /images/20220520/44686019df36460f878d8b33cf882973.png
[640_wx_fmt_png 8]: /images/20220520/442b9856d1f14ee88d4c6b3611fb6237.png
[640_wx_fmt_png 9]: /images/20220520/8adf7a0ff60647fdb88bbbd17d0f3b29.png
[640_wx_fmt_png 10]: /images/20220520/f6f802ea980940829d6eb8b90a3b93f0.png
[640_wx_fmt_jpeg 4]: /images/20220520/6096ce5e8aad44149785f34300314812.png
[640_wx_fmt_png 11]: /images/20220520/dd6ed581ddb645c78beebf22760676ad.png
[640_wx_fmt_png 12]: /images/20220520/6b19a5b0a36a4641a7e2c6be498e55ba.png
[640_wx_fmt_jpeg 5]: /images/20220520/99a2b0e0adaf4587acc8c93f6fdb916e.png
[640_wx_fmt_png 13]: /images/20220520/a954718cc0c74041b763d9c477bef0ce.png
[640_wx_fmt_png 14]: /images/20220520/6e342cfde6d246c9b697e04ddeddf515.png
[640_wx_fmt_png 15]: /images/20220520/51bc613c33ec4c78bee6f10b9fba7a76.png
[640_wx_fmt_png 16]: /images/20220520/a25b1f19a59346c99a19ac97765aae96.png
[640_wx_fmt_png 17]: /images/20220520/fad2b028418944759c31ebaf198a79ba.png
[640_wx_fmt_png 18]: /images/20220520/6d80406e26ed41059c89d3018906a5b3.png
[640_wx_fmt_jpeg 6]: /images/20220520/37cac04b339844de89da985f3a755173.png
[640_wx_fmt_png 19]: /images/20220520/dca6db858c504ad381314d7d2fb934dd.png
[640_wx_fmt_jpeg 7]: /images/20220520/1945fff24559434784589aab0ea2c65b.png
[640_wx_fmt_jpeg 8]: /images/20220520/d10e4b696e1944b4b2a8f59bd6260fcf.png