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

一.事务管理系统的优化

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

图1

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

图2

二.备机只读实现与优化

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

图3

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

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

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

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

图4

图5

四.数据倾斜解决方案

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

图6

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

Shardid = Hash(merchantid) % #shardmap

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

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

图7

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

下面是一个例子(如下图8):

图8

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

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

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

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

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

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

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

六.并行优化

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

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

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

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

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

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

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

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

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

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

原文发布于微信公众号 - IT技术精选文摘(ITHK01)

原文发表时间:2018-07-10

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏架构师之路

12306系统架构优化

12306系统架构优化 coolshell陈皓优化方案 原文:http://coolshell.cn/articles/6470.html 一、业务复杂度比对 ...

78440
来自专栏java架构师

学习 WCF (1)--基础篇

  Windows Communication Foundation (WCF)是一个面向服务编程的综合分层架构。该架构的顶层称为服务模型层(Service M...

27990
来自专栏编程

武哥自学Python笔记(一)

最近Python被各大培训机构炒的火热,好像离开Python这个世界就不能运转一般,恰恰这个时候浙江省信息技术课程改革方案出台,Python确定进入浙江省信息技...

23680
来自专栏Android干货园

Android 轻松实现百度地图定位

版权声明:本文为博主原创文章,转载请标明出处。 https://blog.csdn.net/lyhhj/article/details/49...

52310
来自专栏码神联盟

碎片化 | 第四阶段-32-Struts2列表展示-视频

如清晰度低,可转PC网页观看高清版本: http://v.qq.com/x/page/p0566r8938t.html 列表展示 /list.do->Str...

36690
来自专栏ImportSource

吐槽“双亲委派”

(此图为网上下载) 真的不想说什么。最初看到这个“双亲委派”四个字的时候,我是接受的。当时也没什么多余想法,看到名词就感觉这大概就是最权威的。 但,最近我开始怀...

58790
来自专栏李跃森的专栏

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

本文将以腾讯 PostgreSQL-XZ 为代表介绍腾讯自研 PostgreSQL 所做的优化和改进。

93.6K80
来自专栏晓晨的专栏

ASP.NET Core的身份认证框架IdentityServer4(1)-特性一览

11830
来自专栏IT技术精选文摘

NoSQL和数据可扩展性

介绍 本文提供了一个易于理解和有用的一组有关当前可用NoSQL数据库的信息。 可扩展数据架构 可扩展数据架构已发展用于提高整体系统效率并降低运营成本。 具体的...

52360
来自专栏京东技术

闲话高并发的那些神话,看京东架构师如何把它拉下神坛

高并发也算是这几年的热门词汇了,尤其在互联网圈,开口不聊个高并发问题,都不好意思出门。高并发有那么邪乎吗?动不动就千万并发、亿级流量,听上去的确挺吓人。但仔细想...

31340

扫码关注云+社区

领取腾讯云代金券