李跃森，腾讯云PostgreSQL首席架构师，腾讯数据库团队架构师，负责微信支付商户系统核心数据库的架构设计和研发，PostgreSQL-x2社区核心成员，获多项国家发明专利。从事PG内核开发和架构设计超过10年。
2015年之前，微信支付业务快速发展，需要一款数据库能够安全高效的支撑微信支付商户系统核心业务，这个重任落在了腾讯数据库团队自研PostgreSQL上。
2016年7月，腾讯云对外发布云数据库PostgreSQL，提供腾讯自研的内核优化版和社区版两个版本，以及提供分布式集群架构（分布式集群内部代号PostgreSQL-XZ）两种方案。目前云数据库PostgreSQL在腾讯大数据平台、广点通、腾讯视频等腾讯多个核心业务中稳定运行。
腾讯自研PostgreSQL分布式集群 PostgreSQL-XZ腾讯PostgreSQL-XZ是由PostgreSQL-XC社区版本地化而来，能支撑水平扩展数据库集群。虽然PostgreSQL-XC很强大，但在性能、扩展性、安全、运维方面还是有明显的瓶颈，而腾讯PostgreSQL经过多年的积累，在这些方面都有较大提升和强化。由于是用于微信支付的核心数据库，腾讯PostgreSQL被定位为安全、高效，稳定，可靠的数据库集群。下面将以腾讯PostgreSQL-XZ为代表介绍腾讯自研PostgreSQL所做的优化和改进。
一.事务管理系统的优化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只读提供了基础，然而原始集群并没有负载、调度等能力。在这方面，我们也做了大量的创新，总结起来包括：
正常CN和只读CN进行分离。
正常CN存储主用DN的元数据信息
只读CN存储备用DN的元数据信息
DN之间使用hot standby（热备份保护）模式进行日志同步
通过这些方式，集群可以提供带有智能负载能力的备DN只读功能，充分利用系统资源。
图3
三.业务最小中断的扩容方案业务的快速增长不可避免的需要对资源进行扩容，社区版本的实现使得扩容成本高昂，需要对业务进行长时间的中断。因为，在社区版本PostgreSQL-XC中，通过 DN=Hash(row) % nofdn的方式决定一条记录的存储节点：
也就是说，先对分布列计算hash值，然后使用这个值对集群中的节点个数取模来决定记录去哪个节点（如图4）。
这种方案简单，但实际应用中需要长时间停机扩容。这是因为，扩容后节点数会变多，数据无法按照原有的分布逻辑进行读写，需要重新分布节点数据。而再均衡数据需要停机并手工迁移再均衡到各个节点。对于规模较大的交易系统来说，由于原有节点存储的是海量数据，再均衡过程可能会持续好几天。相信这是业务完全无法忍受的。
图4
因此我们引入了一种新的分表方法—sharded table。Shardedtable的数据分布采用如下（图5）的方式：
引入一个抽象的中间层--shard map。Shard map中每一项存储shardid和DN的映射关系。
Sharded table中的每条记录通过Hash(row) % #shardmap entry来决定记录存储到哪个shardid，通过查询shardmap的存储的DN。
每个DN上存储分配到本节点shardid信息，进而进行可见性的判断。
通过上面的方案，在扩容新加节点时，就只需要把一些shardmap中的shardid映射到新加的节点，并把对应的数据搬迁过去就可以了。扩容也仅仅需要切换shardmap中映射关系的，时间从几天缩短到几秒。
图5
四.数据倾斜解决方案