本文由李躍森發表於雲+社群專欄postgresql-xc在事務管理系統方案本身有乙個明顯的缺點，那就是事務管理機制會成為系統的瓶頸，gtm（global transaction manager全域性事務管理器）會限制系統的擴充套件規模。如圖1所示，是每個請求過來cn(coordinator 協調節點)都會向gtm申請必需的gxid（全域性事務id）和gsnapshot（全域性快照）資訊，並把這些資訊隨著sql語句本身一起發往dn（datanode資料庫節點）進行執行。另外，postgresql-xc的管理機制，只有主dn才會獲取的gxid，而備dn沒有自己的gxid，因此無法提供唯讀服務，對系統也是不小的浪費。 圖1
圖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
資料傾斜是指，在分布式資料庫系統中會因為物理節點、hash或shard分布原因，導致某些dn物理空間不足，而另外的物理空間剩餘較大。例如，如果以商戶作為分布key，京東每天的資料量和乙個普通電商的資料量肯定是天地差別。可能某個大商戶乙個月的資料就會把乙個dn的物理空間塞滿，這時系統只有停機擴容一條路。因此我們必須要有乙個有效的手段來解決資料傾斜，保證在表資料分布不均勻時系統仍然能夠高效穩定的執行。
首先我們把系統的dn分為group（如下圖6），每個group裡面：
包含乙個或者多個dn
每個group有乙個shardmap
在建sharded表時，可以指定儲存的group，也就是要麼儲存在group1，要麼group2
cn可以訪問所有的group，而且cn上也儲存所有表的訪問方式資訊
圖6對於系統中資料量較大使用者進行特別的識別，並為他們建立白名單，使用不同的資料分布邏輯（如下圖7）：普通使用者使用預設的資料分布邏輯，也就是：
shardid = hash(merchantid) % #shardmap
複製**
shardid = hash(merchantid) % #shardmap + fcreate_timedayoffset from 1970-01-01
複製**
通過在大商戶group分布邏輯中加入日期偏移，來實現同乙個使用者的資料在group內部多個節點間均勻分布。從而有效的解決資料分布不均勻問題。
下面是乙個例子（如下圖8）： 圖8
業務在列表查詢場景下會收到如下的查詢sql：
為此，我們提供表定義方案，即建立集群分割槽表。根據上述需求，可以採用按月分表，即每個月一張表，並對排序欄位ffinish_time建立索引，這樣每個分割槽進行掃瞄是可以使用索引。
下面是我們對排序進行的效能測試結果：
通過在24核cpu，64g記憶體的機型上進行測試，9000w資料的排序在最短可以在25 ms內完成，qps最高可達5400。
我們完成優化的運算元：
通過在24核cpu，64g記憶體的機型下測試，各個運算元的優化結果：
整體來說效能普遍是優化前的10-12倍，優化的效果比較明顯。
兩地三中心容災是金融級資料庫的必備能力，對於金融類業務資料安全是最基本也是最重要訴求，因此我們為了保障高效穩定的資料容災能力，也為postgresql-xz建設了完善的兩地三中心自動容災能力。具體的兩地三中心部署結構如下：
同城節點間採用強同步方式，保障資料強一致；異地採用專網非同步同步。
節點內，每台物理機上部署cagent，agent收集機器狀態並進行上報，並進行相應的告警和倒換執行功能。
每個idc至少部署乙個jcenter，jcenter負責收集上報每個agent上報的狀態到zk集群。這麼多個jcenter中只有乙個是主用，主用的jcenter除了進行狀態上報還進行故障裁決和倒換。在主用的jcenter異常後，系統通過zk自動裁決挑選乙個備用的jcenter公升主。
jcenter和cagent是兩地三中心的控制和裁決節點。
對於資料庫節點，cn在每個idc至少部署乙個。dn在每個中心部署乙個，乙個為主，另外兩個併聯作為備機放在主機上，乙個為同步備機，另外乙個為非同步備機。
在主機故障宕機時，jcenter優先選擇同城的備機公升主。
問答mysql到postgresql的遷移?
摩拜的六脈神劍：每日 2500 萬次出行服務背後的技術支撐
海量技術實踐經驗，盡在雲加社群！
解讀微信終端開源背後的故事
問 mars的研發有沒有借用一些其它開源產品？趙原 最開始研發時，mars與業務相關，它的優化必須結合內部業務來完成，所有的技術都是自主研發完成。當然我們也會使用例如openssl這樣的一些非常基礎的開源庫。在mars選擇開源後，我們將其中很多業務相關的部分移除掉，將它改造成誰都可以使用的技術。趙原...
開通微信支付（微信商戶平台賬戶）流程及所需資料
1.聯絡資訊 聯絡人姓名 手機號碼 常用郵箱 2.經營資訊 商戶簡稱 經營類目 售賣商品場景 頁面截圖 公司 售賣商品 提供服務概述 補充材料 需形式 3.商戶資訊 營業執照 營業執照 營業執照註冊號 營業期限 經營範圍 基本資訊 商戶名稱 註冊位址 企業法人 經辦人 證件持有人型別 證件型別 身份...
微信一億使用者背後架構秘密
敏捷是一種態度 敏捷就是試錯 海量系統上的敏捷 無異於懸崖邊的跳舞 如何做到這一切？周顥認為，首先，必須建立起一種狂熱的技術信念，就是一定是可以做到的。然後，需要用一些穩固的技術 理念 來支撐，例如大系統小做 讓一切可擴充套件 必須有基礎元件 輕鬆上線 灰度 灰度 再灰度 精細監控 迅速響應 等等來...