大話Oracle集群,分布式數(shù)據庫與區(qū)塊鏈

【何曉陽專欄】大話Oracle集群，分布式數(shù)據庫與區(qū)塊鏈原創(chuàng)47天前區(qū)塊鏈已經從社會的邊緣產品，變得被越來越多的人所熟悉和接受，并逐漸成為一種新趨勢和未來。在這個過程中，區(qū)塊鏈技術也取得了日新月異的發(fā)展，智能合約、共識機制、分片以及跨鏈等新概念，正在不斷刷新著我們的認知。作為一個在數(shù)據庫領域奮斗10余年的老兵來看，區(qū)塊鏈的本質其實是一個多活的分布式數(shù)據庫，區(qū)塊鏈中的很多技術，在數(shù)據庫的漫長演進過程中也曾得到很多的應用和實踐，為了能更好的理解區(qū)塊鏈，我概述了從2000年開始這十幾年主流系統(tǒng)架構的演變。我們將分成3個階段來闡述：第一階段，Oracle集群時代在這個時代中，如果想去選擇一個可以支撐每秒幾萬筆業(yè)務的成熟數(shù)據庫方案。工程師一定會推薦Oracle。而這個時期系統(tǒng)的主要架構如下：2001年，對Oracle公司來說是一個特殊的年份，在這一年Oracle發(fā)布了甲骨文數(shù)據庫產品的經典版本Oracle9i。在這個版本的產品中，Oracle極大的增強了集群服務能力(RealApplicationCluster，RAC)，促使Oracle完成了在生產環(huán)境中，從一個單一主機節(jié)點向多節(jié)點的轉換的過程。RAC技術有效的解決了以往數(shù)據庫單節(jié)點運行的瓶頸，提升了數(shù)據庫系統(tǒng)的并發(fā)負載能力和高可用性，滿足了企業(yè)發(fā)展過程中，管理指數(shù)級數(shù)據增長的迫切需求。因此這個方案，被廣泛應用到了政府、運營商、銀行、證券等各個領域，當然也包括阿里巴巴和京東等互聯(lián)網巨頭企業(yè)。隨著版本的升級，Oracle10G的集群節(jié)點能力理論峰值擴充到了100多個。但是因為部署設備（小型機和存儲）昂貴等原因，不可能有企業(yè)可以完成這個量級的部署。從我所了解的數(shù)據來看，國內一些企業(yè)在實際的業(yè)務中，應用了6-8個節(jié)點的集群。盡管應用廣泛，但是隨著國內互聯(lián)網業(yè)務的進一步發(fā)展，Oracle集群的一些問題也逐漸暴露出來，這也促使了后來國內轟轟烈烈「去IOEJ運動的產生。第一個問題：架構所需要的軟硬件（IOE）價格昂貴在圖1的架構圖中可以看到，為了保證事務的一致性，Oracle采用的是在多節(jié)點間共享存儲的方式，也就是說最終的數(shù)據在磁盤上只存儲一份，數(shù)據可以被多個節(jié)點讀寫，Oracle利用行鎖等技術解決讀寫爭用問題，并保障每個交易請求提交或回滾的一致性。應用層主機通過OracleNetServices路由到不同的數(shù)據庫節(jié)點中，提交數(shù)據庫交易請求后，數(shù)據庫節(jié)點會定時將交易數(shù)據寫入共享的磁盤陣列中。我們知道IO請求在計算機請求中是非常緩慢的，這樣的架構設計，更加突出了IO讀寫的性能瓶頸。企業(yè)的應對辦法則是購買性能更好，更昂貴的磁盤陣列，提升IO性能，這也導致了IOE架構在很長一段時間內占據著國內IT采購的主流地位。第二個問題：擴展能力有限，增加節(jié)點的性能收益并非線性增強正如上面提到的，因為受限于IO請求的性能瓶頸。各個節(jié)點的交易數(shù)據發(fā)起IO請求將數(shù)據寫入磁盤會有一定的間隔。而這個過程中，實時交易信息則是由IPC協(xié)議在各個節(jié)點間傳輸內存數(shù)據來同步的。這時我們需要一個高速的數(shù)據傳輸網絡，一般是由千兆網卡來完成。但是，隨著節(jié)點的不斷越多，需要同步的交易數(shù)據就會越多，網絡爭用和行鎖爭用也會變得越來越嚴重，從而導致擴展節(jié)點的性能收益并非線性增強。第二個階段：分布式數(shù)據庫時代隨著淘寶業(yè)務的飛速發(fā)展，2010年時，淘寶已經成為Oracle中國的頂級的客戶了。為了降低IT成本同時滿足業(yè)務的進一步發(fā)展需求，也鑒于在開源社區(qū)長期的技術積累驅動。2010年時，由淘寶技術團隊開啟了轟轟烈烈的「去IOE」運動，目標是用分布式的開源數(shù)據庫架構替代傳統(tǒng)的OracleDB架構。淘寶「去IOE」的成功，有效的驗證了分布式數(shù)據庫在大規(guī)模生產應用中的負載能力，這也促使后續(xù)國內IT架構選型思路的轉變，以及分布式數(shù)據庫架構的演進。分布式的數(shù)據庫方案有非常多種，目前在各個互聯(lián)網公司應用的也比較普遍，其本質就是將數(shù)據拆分存儲到不同的節(jié)點上，從而緩解單節(jié)點讀寫的壓力，比如按奇偶拆分數(shù)據就是一個簡單的分布式系統(tǒng)，示意圖如下：

當我們將數(shù)據拆分成分布式數(shù)據庫之后，就不得不考慮，分布式帶來的三個特性之間的權衡，正如CAP所描述的：CConystent，谷個節(jié)點數(shù)據始終備遂性AAvailable,在可容忍的時間內,交易請求有淄結果PPartitiontolerant,單個分區(qū)宕網,系狗燃可使用系統(tǒng)架構師需要根據業(yè)務，用各種變通的手法優(yōu)化CAP的三個特性，讓系統(tǒng)最終體現(xiàn)的效果可以與業(yè)務需求的預期一致。

目前看到的一些主流分布式方案，對這3個特性都有不同程度的選擇。我們在運營上一個創(chuàng)業(yè)項目OneAPM時，為了解決處理用戶訪問軌跡而產生的海量數(shù)據的問題，曾綜合使用過Kafka、Zookeeper、Clickhouse等架構來滿足業(yè)務需求，架構圖如下：第三個階段：區(qū)塊鏈時代從數(shù)據庫技術的角度來看，區(qū)塊鏈的本質是一個特定架構的多活分布式數(shù)據庫。分布式數(shù)據庫利用Paxos、RAFT等算法來保障數(shù)據庫多副本的強一致性，而區(qū)塊鏈是用共識算法來解決各個節(jié)點間數(shù)據一致性的問題。

POW、POS、DPOS等各類共識算法其本質都是在競爭將由哪個節(jié)點擁有寫入區(qū)塊（賬本數(shù)據）的權力。在區(qū)塊鏈的經濟模型的設計中，對寫入區(qū)塊的行為進行了經濟激勵，極大的鼓舞了區(qū)塊鏈生態(tài)的發(fā)展。但也正是因為每個節(jié)點都有可能擁有寫入區(qū)塊的權力，為了保障系統(tǒng)數(shù)據一致性，必須與系統(tǒng)的響應時間之間做出權衡。所以我們看到比特幣的TPS是每秒7比業(yè)務，以太坊的TPS也只有每秒幾十筆業(yè)務。分布式數(shù)據庫中的CAP問題，依然是區(qū)塊鏈需要挑戰(zhàn)的技術難題。當然，目前隨著分片，閃電網絡等新技術的出現(xiàn)，交易性能的瓶頸再被不斷的優(yōu)化。此外，從產品的功能上來看，目前的區(qū)塊鏈技術主要提供的交易記賬的能力，并不能支撐數(shù)據庫的標準能力「增刪改查」，所以以功能而言，目前的區(qū)塊鏈本質是數(shù)據庫技術棧的特殊子集。在區(qū)塊鏈上，擴充對文件和數(shù)據增刪改查的能力是DAPP生態(tài)發(fā)展的關鍵能力?？v觀數(shù)據庫系統(tǒng)演進的這3個時代，技術發(fā)展的浪潮無法阻擋，我們唯一可以做的只有學習和面對。正如分布式數(shù)據庫最終替代了傳統(tǒng)O