SACC2017：資料庫架構設計與實踐的後半生

  在支付領域各佔一席之地的財付通和京東金融很少在公開場合分享各自在資料庫架構設計上的問題和思考，在SACC大會的資料庫架構設計專場，財付通和京東金融來了一次正面碰撞，來自摩拜、360的資深專家也加入了這場紛爭。

　　京東金融資料庫團隊負責人高新剛：京東金融資料庫多場景架構實踐

　　面對支付場景對資料庫高可靠、高可用的更高要求，京東金融目前的資料庫架構採用MHA、CDS、HDB;資料治理架構選用R2M、DBRep和HCenter。整體架構自底層向上分為三個部分：大資料層、DB層和應用層。大資料層主要由資料倉儲、HCenter、DBRep和ETL組成，DB層也就是上述提到的三大資料庫架構支撐，應用層主要是業務應用，由JMQ、R2M和直連組成。

　　DBA可能無法直接為企業帶來價值，但可以降低運維成本。京東金融的DBA團隊通過DB分級和DB孵化優先為重要業務配備資源，進行分級調控，最終實現成本降低的同時保證業務高效可用。

　　財付通高階DBA成江東：財付通交易核心演進之路

　　成江東，財付通高階DBA，負責財付通分散式交易核心與賬戶資料庫運維，網名“最醉紅樓”。

　　從每天10萬筆到每秒峰值100萬筆交易，騰訊財付通經歷了哪些改變?在這種情況下，騰訊財付通的資料庫架構是如何設計的呢?

　　從磁碟櫃、冷熱災備、同城雙活、核心雙活+雙向複製到核心N地N中心，財付通的資料庫架構演進之路隨著交易量的增加不斷給出新的解決方案。成江東現場打趣道，之前火熱興起的去IOE活動與我們一點關係也沒有，因為我們從來就沒用過這些。財付通從MySQL 4.1到MySQL 5.7，一直在使用MySQL資料庫。自2014年至今，財付通一直在使用分散式管控系統：

　　未來，財付通在資料庫架構上的設計將會向著餘額支付全路徑的條帶化、更多的邏輯SET、跨IDC資料強一致，實現秒級IDC切換、資源雲化，動態伸縮的方向發展。

　　360基礎架構組技術經理陳宗志：大容量redis儲存方案--Pika

　　Pika是360的開源專案，是360所有DBA 和基礎架構團隊一起設計開發的大容量redis解決方案，完全相容redis 協議, 使用者不需要修改任何程式碼進行遷移。陳宗志表示，Pika力求在完全相容Redis協議、繼承Redis便捷運維設計的前提下通過持久化儲存的方式解決Redis 在大容量場景下的問題。

　　目前的網路模組Pink支援pb, redis, pg, http等協議，可抽象各種不同型別執行緒：DispatchThread、WorkThread、BGThread。儲存引擎--Nemo實現了Hash, List, Set, Zset 等資料結構、Rocksdb 啟動只需要載入log 檔案、Rocksdb使用的本地硬碟, 對SSD盤友好。日誌模組--Binlog順序寫檔案, 通過Index + offset 進行同步點檢查，解決了緩衝區小的問題，支援全同步與增量同步。

　　陳宗志表示，由於Pika是基於記憶體和檔案來存放資料, 所以效能肯定比Redis低一些。但Pika容量大、載入db速度快、備份速度快、對網路容忍度高以及價效比高，這些可以很好地補充Redis的不足。

　　摩拜資料庫團隊負責人李凱：開源技術的線上應用之路

　　作為新興獨角獸企業的代表，摩拜深深改變了大眾的出行方式。李凱表示，目前摩拜使用者已達1.5億，單車數量700萬+，每日訪問80億，資料總量逼近300億。面對如此龐大的資料體系，摩拜是如何管理的呢?

　　李凱表示，目前資料儲存面臨的主要問題是自身穩定性、多AZ/Region容災、業務國際化/單元化部署、業務持續增長、自動化運維等。摩拜使用的關聯式資料庫是MySQL，文件資料庫是MongoDB，快取正在從Redis向Codis遷移，分散式資料庫採用TiDB，摩拜主要採用了騰訊雲的服務，之後也會逐漸向線下遷移。

　　之後，摩拜的主要技術方向是全自動SQL稽核、Codis自動伸縮以及TiDB，TiDB主要有RocksDB Compaction優化、Region物理隔離、獨佔物理機、多模型統一儲存SQL，KV，Cache等方向。

　　不難看出，各大廠的資料庫架構設計都歷經了多個階段，隨著雲端計算時代的到來，搭建簡易資料庫架構的門檻並不是特別高，很多提供雲服務的企業都有各種介面方便整個過程，但技術負責人應該儘早考慮後續是否走向線下的問題。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/31077337/viewspace-2153966/，如需轉載，請註明出處，否則將追究法律責任。