摘要：年之前，微信支付業(yè)務(wù)快速發(fā)展，需要一款數(shù)據(jù)庫(kù)能夠安全高效的支撐微信支付商戶系統(tǒng)核心業(yè)務(wù)，這個(gè)重任落在了騰訊數(shù)據(jù)庫(kù)團(tuán)隊(duì)自研上。由于是用于微信支付的核心數(shù)據(jù)庫(kù)，騰訊被定位為安全高效，穩(wěn)定，可靠的數(shù)據(jù)庫(kù)集群。

歡迎大家前往騰訊云+社區(qū)，獲取更多騰訊海量技術(shù)實(shí)踐干貨哦~

本文由李躍森發(fā)表于云+社區(qū)專欄
李躍森，騰訊云PostgreSQL首席架構(gòu)師，騰訊數(shù)據(jù)庫(kù)團(tuán)隊(duì)架構(gòu)師，負(fù)責(zé)微信支付商戶系統(tǒng)核心數(shù)據(jù)庫(kù)的架構(gòu)設(shè)計(jì)和研發(fā)，PostgreSQL-x2社區(qū)核心成員，獲多項(xiàng)國(guó)家發(fā)明專利。從事PG內(nèi)核開發(fā)和架構(gòu)設(shè)計(jì)超過(guò)10年。

2015年之前，微信支付業(yè)務(wù)快速發(fā)展，需要一款數(shù)據(jù)庫(kù)能夠安全高效的支撐微信支付商戶系統(tǒng)核心業(yè)務(wù)，這個(gè)重任落在了騰訊數(shù)據(jù)庫(kù)團(tuán)隊(duì)自研PostgreSQL上。

2016年7月，騰訊云對(duì)外發(fā)布云數(shù)據(jù)庫(kù)PostgreSQL，提供騰訊自研的內(nèi)核優(yōu)化版和社區(qū)版兩個(gè)版本，以及提供分布式集群架構(gòu)（分布式集群內(nèi)部代號(hào)PostgreSQL-XZ）兩種方案。目前云數(shù)據(jù)庫(kù)PostgreSQL在騰訊大數(shù)據(jù)平臺(tái)、廣點(diǎn)通、騰訊視頻等騰訊多個(gè)核心業(yè)務(wù)中穩(wěn)定運(yùn)行。

騰訊PostgreSQL-XZ是由PostgreSQL-XC社區(qū)版本地化而來(lái)，能支撐水平擴(kuò)展數(shù)據(jù)庫(kù)集群。雖然PostgreSQL-XC很強(qiáng)大，但在性能、擴(kuò)展性、安全、運(yùn)維方面還是有明顯的瓶頸，而騰訊PostgreSQL經(jīng)過(guò)多年的積累，在這些方面都有較大提升和強(qiáng)化。由于是用于微信支付的核心數(shù)據(jù)庫(kù)，騰訊PostgreSQL被定位為安全、高效，穩(wěn)定，可靠的數(shù)據(jù)庫(kù)集群。下面將以騰訊PostgreSQL-XZ為代表介紹騰訊自研PostgreSQL所做的優(yōu)化和改進(jìn)。

PostgreSQL-XC在事務(wù)管理系統(tǒng)方案本身有一個(gè)明顯的缺點(diǎn)，那就是事務(wù)管理機(jī)制會(huì)成為系統(tǒng)的瓶頸，GTM（Global Transaction Manager全局事務(wù)管理器）會(huì)限制系統(tǒng)的擴(kuò)展規(guī)模。如圖1所示，是每個(gè)請(qǐng)求過(guò)來(lái)CN(Coordinator 協(xié)調(diào)節(jié)點(diǎn))都會(huì)向GTM申請(qǐng)必需的gxid（全局事務(wù)ID）和gsnapshot（全局快照）信息，并把這些信息隨著SQL語(yǔ)句本身一起發(fā)往DN（Datanode數(shù)據(jù)庫(kù)節(jié)點(diǎn)）進(jìn)行執(zhí)行。另外，PostgreSQL-XC的管理機(jī)制，只有主DN才會(huì)獲取的gxid，而備DN沒(méi)有自己的gxid，因此無(wú)法提供只讀服務(wù)，對(duì)系統(tǒng)也是不小的浪費(fèi)。

圖1

而騰訊PostgreSQL-XZ改進(jìn)了事務(wù)管理機(jī)制，改進(jìn)后，CN不再?gòu)腉TM獲取gxid和gsnapshot，每個(gè)節(jié)點(diǎn)使用自己的本地xid（事務(wù)ID）和gsnapshot（快照），如此GTM便不會(huì)成為系統(tǒng)的瓶頸；并且，DN備機(jī)就還可以提供只讀服務(wù)，充分利用系統(tǒng)閑置資源。如圖2，優(yōu)化后的事務(wù)管理系統(tǒng)架構(gòu)如下：

圖2

當(dāng)然，事務(wù)管理系統(tǒng)的優(yōu)化為進(jìn)行備DN只讀提供了基礎(chǔ)，然而原始集群并沒(méi)有負(fù)載、調(diào)度等能力。在這方面，我們也做了大量的創(chuàng)新，總結(jié)起來(lái)包括：

正常CN和只讀CN進(jìn)行分離。

正常CN存儲(chǔ)主用DN的元數(shù)據(jù)信息

只讀CN存儲(chǔ)備用DN的元數(shù)據(jù)信息

DN之間使用hot standby（熱備份保護(hù)）模式進(jìn)行日志同步

通過(guò)這些方式，集群可以提供帶有智能負(fù)載能力的備DN只讀功能，充分利用系統(tǒng)資源。

圖3

業(yè)務(wù)的快速增長(zhǎng)不可避免的需要對(duì)資源進(jìn)行擴(kuò)容，社區(qū)版本的實(shí)現(xiàn)使得擴(kuò)容成本高昂，需要對(duì)業(yè)務(wù)進(jìn)行長(zhǎng)時(shí)間的中斷。因?yàn)椋谏鐓^(qū)版本PostgreSQL-XC中，通過(guò) DN=Hash(row) % nofdn的方式?jīng)Q定一條記錄的存儲(chǔ)節(jié)點(diǎn)：

也就是說(shuō)，先對(duì)分布列計(jì)算hash值，然后使用這個(gè)值對(duì)集群中的節(jié)點(diǎn)個(gè)數(shù)取模來(lái)決定記錄去哪個(gè)節(jié)點(diǎn)（如圖4）。

這種方案簡(jiǎn)單，但實(shí)際應(yīng)用中需要長(zhǎng)時(shí)間停機(jī)擴(kuò)容。這是因?yàn)椋瑪U(kuò)容后節(jié)點(diǎn)數(shù)會(huì)變多，數(shù)據(jù)無(wú)法按照原有的分布邏輯進(jìn)行讀寫，需要重新分布節(jié)點(diǎn)數(shù)據(jù)。而再均衡數(shù)據(jù)需要停機(jī)并手工遷移再均衡到各個(gè)節(jié)點(diǎn)。對(duì)于規(guī)模較大的交易系統(tǒng)來(lái)說(shuō)，由于原有節(jié)點(diǎn)存儲(chǔ)的是海量數(shù)據(jù)，再均衡過(guò)程可能會(huì)持續(xù)好幾天。相信這是業(yè)務(wù)完全無(wú)法忍受的。

圖4

因此我們引入了一種新的分表方法—sharded table。Shardedtable的數(shù)據(jù)分布采用如下（圖5）的方式：

引入一個(gè)抽象的中間層--shard map。Shard map中每一項(xiàng)存儲(chǔ)shardid和DN的映射關(guān)系。

Sharded table中的每條記錄通過(guò)Hash(row) % #shardmap entry來(lái)決定記錄存儲(chǔ)到哪個(gè)shardid，通過(guò)查詢shardmap的存儲(chǔ)的DN。

每個(gè)DN上存儲(chǔ)分配到本節(jié)點(diǎn)shardid信息，進(jìn)而進(jìn)行可見(jiàn)性的判斷。

通過(guò)上面的方案，在擴(kuò)容新加節(jié)點(diǎn)時(shí)，就只需要把一些shardmap中的shardid映射到新加的節(jié)點(diǎn)，并把對(duì)應(yīng)的數(shù)據(jù)搬遷過(guò)去就可以了。擴(kuò)容也僅僅需要切換shardmap中映射關(guān)系的，時(shí)間從幾天縮短到幾秒。

圖5

數(shù)據(jù)傾斜是指，在分布式數(shù)據(jù)庫(kù)系統(tǒng)中會(huì)因?yàn)槲锢砉?jié)點(diǎn)、hash或shard分布原因，導(dǎo)致某些DN物理空間不足，而另外的物理空間剩余較大。例如，如果以商戶作為分布key，京東每天的數(shù)據(jù)量和一個(gè)普通電商的數(shù)據(jù)量肯定是天地差別。可能某個(gè)大商戶一個(gè)月的數(shù)據(jù)就會(huì)把一個(gè)DN的物理空間塞滿，這時(shí)系統(tǒng)只有停機(jī)擴(kuò)容一條路。因此我們必須要有一個(gè)有效的手段來(lái)解決數(shù)據(jù)傾斜，保證在表數(shù)據(jù)分布不均勻時(shí)系統(tǒng)仍然能夠高效穩(wěn)定的運(yùn)行。

首先我們把系統(tǒng)的DN分為group（如下圖6），每個(gè)group里面：

包含一個(gè)或者多個(gè)DN

每個(gè)group有一個(gè)shardmap

在建sharded表時(shí)，可以指定存儲(chǔ)的group，也就是要么存儲(chǔ)在group1，要么group2

CN可以訪問(wèn)所有的group，而且CN上也存儲(chǔ)所有表的訪問(wèn)方式信息

圖6

對(duì)于系統(tǒng)中數(shù)據(jù)量較大用戶進(jìn)行特別的識(shí)別，并為他們創(chuàng)建白名單，使用不同的數(shù)據(jù)分布邏輯（如下圖7）：普通用戶使用默認(rèn)的數(shù)據(jù)分布邏輯，也就是：

Shardid = Hash(merchantid) % #shardmap

大商戶使用定制的數(shù)據(jù)分布邏輯，也就是：

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

圖7

通過(guò)在大商戶group分布邏輯中加入日期偏移，來(lái)實(shí)現(xiàn)同一個(gè)用戶的數(shù)據(jù)在group內(nèi)部多個(gè)節(jié)點(diǎn)間均勻分布。從而有效的解決數(shù)據(jù)分布不均勻問(wèn)題。

下面是一個(gè)例子（如下圖8）：

圖8

業(yè)務(wù)在列表查詢場(chǎng)景下會(huì)收到如下的查詢SQL：

在微信支付的場(chǎng)景中，某個(gè)商戶每天的數(shù)據(jù)有300W，一個(gè)月數(shù)據(jù)超過(guò)9000W條，也就是說(shuō)PostgreSQL需要面向一個(gè)9000W數(shù)據(jù)級(jí)數(shù)據(jù)進(jìn)行快速排序，而且業(yè)務(wù)邏輯要求需要秒級(jí)輸出，快速獲取排序結(jié)果。

為此，我們提供表定義方案，即建立集群分區(qū)表。根據(jù)上述需求，可以采用按月分表，即每個(gè)月一張表，并對(duì)排序字段ffinish_time建立索引，這樣每個(gè)分區(qū)進(jìn)行掃描是可以使用索引。

我們?cè)偻ㄟ^(guò)一系列執(zhí)行計(jì)劃的優(yōu)化，CN下推order by和limit offset子句到DN；DN上在執(zhí)行對(duì)應(yīng)的sql使用使用Merge Append算子對(duì)各個(gè)子表執(zhí)行的結(jié)果進(jìn)行匯總輸出，這個(gè)算子本身會(huì)保證輸出是有序的，也就是說(shuō)對(duì)子表進(jìn)行索引掃描，同時(shí)Merge Append又對(duì)各個(gè)子表的結(jié)果進(jìn)行歸并，進(jìn)而保證節(jié)點(diǎn)本身的結(jié)果是排序的。CN對(duì)多個(gè)DN的結(jié)果同樣使用Merge Append進(jìn)行歸并，保證整個(gè)輸出結(jié)果是有序的，從而完成整個(gè)排序過(guò)程。

下面是我們對(duì)排序進(jìn)行的性能測(cè)試結(jié)果：

通過(guò)在24核CPU，64G內(nèi)存的機(jī)型上進(jìn)行測(cè)試，9000W數(shù)據(jù)的排序在最短可以在25 ms內(nèi)完成，QPS最高可達(dá)5400。

隨著當(dāng)前硬件的發(fā)展，系統(tǒng)資源越來(lái)越豐富，多CPU大內(nèi)存成了系統(tǒng)標(biāo)配，充分利用這些資源可以有效的提升的處理效率優(yōu)化性能。騰訊在2014年底開始進(jìn)行PostgreSQL多核執(zhí)行優(yōu)化。

目前PostgreSQL9.6社區(qū)版也會(huì)包含部分并行化特性，但是沒(méi)有我們這邊這么豐富，下面介紹下騰訊PostgreSQL并行化的原理和效果：

系統(tǒng)創(chuàng)建一個(gè)全局的共享內(nèi)存管理器，使用bitmap管理算法進(jìn)行管理

系統(tǒng)啟動(dòng)時(shí)創(chuàng)建一定數(shù)據(jù)的Executor，這些Executor用來(lái)執(zhí)行執(zhí)行計(jì)劃的碎片

系統(tǒng)會(huì)創(chuàng)建一個(gè)計(jì)劃隊(duì)列，所有的Executor都會(huì)在任務(wù)隊(duì)列上等待計(jì)劃

每個(gè)Executor對(duì)應(yīng)一個(gè)任務(wù)結(jié)果隊(duì)列，Executor在輸出結(jié)果時(shí)就把結(jié)果的指針掛到結(jié)果隊(duì)列中去

計(jì)劃隊(duì)列，結(jié)果隊(duì)列，計(jì)劃分片執(zhí)行結(jié)果都存放在共享內(nèi)存管理器中，這樣所有的進(jìn)程都可以訪問(wèn)到這些結(jié)構(gòu)

Postgres會(huì)話進(jìn)程在收到sql時(shí)，判斷是否可以并行化，并進(jìn)行任務(wù)的分發(fā)；在結(jié)果隊(duì)列中有結(jié)果時(shí)就讀出返回

我們完成優(yōu)化的算子：

Seqscan

Hash join

Nestloop join

Remote query

Hash Agg

Sort Agg

Append

通過(guò)在24核CPU，64G內(nèi)存的機(jī)型下測(cè)試，各個(gè)算子的優(yōu)化結(jié)果：

整體來(lái)說(shuō)性能普遍是優(yōu)化前的10-12倍，優(yōu)化的效果比較明顯。

兩地三中心容災(zāi)是金融級(jí)數(shù)據(jù)庫(kù)的必備能力，對(duì)于金融類業(yè)務(wù)數(shù)據(jù)安全是最基本也是最重要訴求，因此我們?yōu)榱吮Ｕ细咝Х€(wěn)定的數(shù)據(jù)容災(zāi)能力，也為PostgreSQL-XZ建設(shè)了完善的兩地三中心自動(dòng)容災(zāi)能力。具體的兩地三中心部署結(jié)構(gòu)如下：

同城節(jié)點(diǎn)間采用強(qiáng)同步方式，保障數(shù)據(jù)強(qiáng)一致；異地采用專網(wǎng)異步同步。

節(jié)點(diǎn)內(nèi)，每臺(tái)物理機(jī)上部署CAgent，agent收集機(jī)器狀態(tài)并進(jìn)行上報(bào)，并進(jìn)行相應(yīng)的告警和倒換執(zhí)行功能。

每個(gè)IDC至少部署一個(gè)JCenter，JCenter負(fù)責(zé)收集上報(bào)每個(gè)agent上報(bào)的狀態(tài)到ZK集群。這么多個(gè)JCenter中只有一個(gè)是主用，主用的JCenter除了進(jìn)行狀態(tài)上報(bào)還進(jìn)行故障裁決和倒換。在主用的JCenter異常后，系統(tǒng)通過(guò)ZK自動(dòng)裁決挑選一個(gè)備用的JCenter升主。

JCenter和CAgent是兩地三中心的控制和裁決節(jié)點(diǎn)。

對(duì)于數(shù)據(jù)庫(kù)節(jié)點(diǎn)，CN在每個(gè)IDC至少部署一個(gè)。DN在每個(gè)中心部署一個(gè)，一個(gè)為主，另外兩個(gè)并聯(lián)作為備機(jī)放在主機(jī)上，一個(gè)為同步備機(jī)，另外一個(gè)為異步備機(jī)。

在主機(jī)故障宕機(jī)時(shí)，JCenter優(yōu)先選擇同城的備機(jī)升主。

目前，騰訊云已經(jīng)提供云數(shù)據(jù)庫(kù)PostgreSQL的內(nèi)測(cè)使用，并將提供內(nèi)核優(yōu)化版和社區(qū)版兩個(gè)版本來(lái)滿足更多客戶的要求。

問(wèn)答
如何記錄PostgreSQL查詢？
相關(guān)閱讀
PostgreSQL新手入門
PostgreSQL配置優(yōu)化
PostgreSQL主備環(huán)境搭建 
【每日課程推薦】機(jī)器學(xué)習(xí)實(shí)戰(zhàn)！快速入門在線廣告業(yè)務(wù)及CTR相應(yīng)知識(shí)

此文已由作者授權(quán)騰訊云+社區(qū)發(fā)布，更多原文請(qǐng)點(diǎn)擊

搜索關(guān)注公眾號(hào)「云加社區(qū)」，第一時(shí)間獲取技術(shù)干貨，關(guān)注后回復(fù)1024 送你一份技術(shù)課程大禮包！

海量技術(shù)實(shí)踐經(jīng)驗(yàn)，盡在云加社區(qū)！