微信支付商戶系統架構背後的故事

一.事務管理系統的優化

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的內測使用，並將提供核心優化版和社群版兩個版本來滿足更多客戶的要求。

公眾號推薦: