大佬爲你揭祕微信支付的系統架構，你想知道的都在這裏了

歡迎你們前往騰訊雲+社區，獲取更多騰訊海量技術實踐乾貨哦~

本文由 李躍森發表於 雲+社區專欄

李躍森，騰訊雲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只讀提供了基礎，然而原始集羣並無負載、調度等能力。在這方面，咱們也作了大量的創新，總結起來包括：

1. 正常CN和只讀CN進行分離。
2. 正常CN存儲主用DN的元數據信息
3. 只讀CN存儲備用DN的元數據信息
4. DN之間使用hot standby（熱備份保護）模式進行日誌同步

經過這些方式，集羣能夠提供帶有智能負載能力的備DN只讀功能，充分利用系統資源。

圖3

三.業務最小中斷的擴容方案

業務的快速增加不可避免的須要對資源進行擴容，社區版本的實現使得擴容成本高昂，須要對業務進行長時間的中斷。由於，在社區版本PostgreSQL-XC中，經過 DN=Hash(row) % nofdn的方式決定一條記錄的存儲節點：

也就是說，先對分佈列計算hash值，而後使用這個值對集羣中的節點個數取模來決定記錄去哪一個節點（如圖4）。

這種方案簡單，但實際應用中須要長時間停機擴容。這是由於，擴容後節點數會變多，數據沒法按照原有的分佈邏輯進行讀寫，須要從新分佈節點數據。而再均衡數據須要停機並手工遷移再均衡到各個節點。對於規模較大的交易系統來講，因爲原有節點存儲的是海量數據，再均衡過程可能會持續好幾天。相信這是業務徹底沒法忍受的。

圖4

所以咱們引入了一種新的分表方法—sharded table。Shardedtable的數據分佈採用以下（圖5）的方式：

1. 引入一個抽象的中間層--shard map。Shard map中每一項存儲shardid和DN的映射關係。
2. Sharded table中的每條記錄經過Hash(row) % #shardmap entry來決定記錄存儲到哪一個shardid，經過查詢shardmap的存儲的DN。
3. 每一個DN上存儲分配到本節點shardid信息，進而進行可見性的判斷。

經過上面的方案，在擴容新加節點時，就只須要把一些shardmap中的shardid映射到新加的節點，並把對應的數據搬遷過去就能夠了。擴容也僅僅須要切換shardmap中映射關係的，時間從幾天縮短到幾秒。

圖5

四.數據傾斜解決方案

數據傾斜是指，在分佈式數據庫系統中會由於物理節點、hash或shard分佈緣由，致使某些DN物理空間不足，而另外的物理空間剩餘較大。例如，若是以商戶做爲分佈key，京東天天的數據量和一個普通電商的數據量確定是天地差異。可能某個大商戶一個月的數據就會把一個DN的物理空間塞滿，這時系統只有停機擴容一條路。所以咱們必需要有一個有效的手段來解決數據傾斜，保證在表數據分佈不均勻時系統仍然可以高效穩定的運行。

首先咱們把系統的DN分爲group（以下圖6），每一個group裏面：

1. 包含一個或者多個DN
2. 每一個group有一個shardmap
3. 在建sharded表時，能夠指定存儲的group，也就是要麼存儲在group1，要麼group2
4. CN能夠訪問全部的group，並且CN上也存儲全部表的訪問方式信息

圖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並行化的原理和效果：

• 系統建立一個全局的共享內存管理器，使用bitmap管理算法進行管理
• 系統啓動時建立必定數據的Executor，這些Executor用來執行執行計劃的碎片
• 系統會建立一個計劃隊列，全部的Executor都會在任務隊列上等待計劃
• 每一個Executor對應一個任務結果隊列，Executor在輸出結果時就把結果的指針掛到結果隊列中去
• 計劃隊列，結果隊列，計劃分片執行結果都存放在共享內存管理器中，這樣全部的進程均可以訪問到這些結構
• Postgres會話進程在收到sql時，判斷是否能夠並行化，並進行任務的分發；在結果隊列中有結果時就讀出返回

咱們完成優化的算子：

• Seqscan
• Hash join
• Nestloop join
• Remote query
• Hash Agg
• Sort Agg
• Append

經過在24核CPU，64G內存的機型下測試，各個算子的優化結果：

總體來講性能廣泛是優化前的10-12倍，優化的效果比較明顯。

七.騰訊PostgreSQL-XZ的兩地三中心容災

兩地三中心容災是金融級數據庫的必備能力，對於金融類業務數據安全是最基本也是最重要訴求，所以咱們爲了保障高效穩定的數據容災能力，也爲PostgreSQL-XZ建設了完善的兩地三中心自動容災能力。具體的兩地三中心部署結構以下：

同城節點間採用強同步方式，保障數據強一致；異地採用專網異步同步。

節點內，每臺物理機上部署CAgent，agent收集機器狀態並進行上報，並進行相應的告警和倒換執行功能。

每一個IDC至少部署一個JCenter，JCenter負責收集上報每一個agent上報的狀態到ZK集羣。這麼多個JCenter中只有一個是主用，主用的JCenter除了進行狀態上報還進行故障裁決和倒換。在主用的JCenter異常後，系統經過ZK自動裁決挑選一個備用的JCenter升主。

JCenter和CAgent是兩地三中心的控制和裁決節點。

對於數據庫節點，CN在每一個IDC至少部署一個。DN在每一箇中心部署一個，一個爲主，另外兩個並聯做爲備機放在主機上，一個爲同步備機，另一個爲異步備機。

在主機故障宕機時，JCenter優先選擇同城的備機升主。

目前，騰訊雲已經提供雲數據庫PostgreSQL的內測使用，並將提供內核優化版和社區版兩個版原本知足更多客戶的要求。

問答
如何記錄PostgreSQL查詢？
相關閱讀
PostgreSQL新手入門
PostgreSQL配置優化
PostgreSQL主備環境搭建
【每日課程推薦】機器學習實戰！快速入門在線廣告業務及CTR相應知識

此文已由做者受權騰訊雲+社區發佈，更多原文請點擊

搜索關注公衆號「雲加社區」，第一時間獲取技術乾貨，關注後回覆1024 送你一份技術課程大禮包！

海量技術實踐經驗，盡在雲加社區！