大話Oracle集群，分散式資料庫與區塊鏈

區塊鏈已經從社會的邊緣產品，變得被越來越多的人所熟悉和接受，並逐漸成為一種新趨勢和未來。在這個過程中，區塊鏈技術也取得了日新月異的發展，智能合約、共識機制、分片以及跨鏈等新概念，正在不斷刷新著我們的認知。

作為一個在資料庫領域奮鬥10餘年的老兵來看，區塊鏈的本質其實是一個多活的分散式資料庫，區塊鏈中的很多技術，在資料庫的漫長演進過程中也曾得到很多的應用和實踐，為了能更好的理解區塊鏈，我概述了從2000年開始這十幾年主流系統架構的演變。

我們將分成3個階段來闡述一下：

第一階段， Oracle集群時代

在這個時代中，如果想去選擇一個可以支撐每秒幾萬筆業務的成熟資料庫方案。工程師一定會推薦Oracle。

而這個時期系統的主要架構如下：

圖1 RAC架構圖

2001年，對Oracle公司來說是一個特殊的年份，在這一年Oracle發布了甲骨文資料庫產品的經典版本 Oracle 9i。在這個版本的產品中，Oracle極大的增強了集群服務能力（Real Application Cluster, RAC），促使Oracle完成了在生產環境中，從一個單一主機節點向多節點的轉換的過程。

RAC技術有效的解決了以往資料庫單節點運行的瓶頸，提升了資料庫系統的並發負載能力和高可用性，滿足了企業發展過程中，管理指數級數據增長的迫切需求。因此這個方案，被廣泛應用到了政府、運營商、銀行、證券等各個領域，當然也包括阿里巴巴和京東等互聯網巨頭企業。

隨著版本的升級，Oracle 10G的集群節點能力理論峰值擴充到了100多個。但是因為部署設備（小型機和存儲）昂貴等原因，不可能有企業可以完成這個量級的部署。從我所了解的數據來看，國內一些企業在實際的業務中，應用了6-8個節點的集群。

儘管應用廣泛，但是隨著國內互聯網業務的進一步發展，Oracle集群的一些問題也逐漸暴露出來，這也促使了後來國內轟轟烈烈「去IOE」運動的產生。

第一個問題：

架構所需要的軟硬體（IOE）價格昂貴

I

IBM小型機

O

ORACLE資料庫

E

EMC存儲

在圖1的架構圖中可以看到，為了保證事務的一致性，Oracle採用的是在多節點間共享存儲的方式，也就是說最終的數據在磁碟上只存儲一份，數據可以被多個節點讀寫，Oracle利用行鎖等技術解決讀寫爭用問題，並保障每個交易請求提交或回滾的一致性。

應用層主機通過Oracle Net Services路由到不同的資料庫節點中，提交資料庫交易請求後，資料庫節點會定時將交易數據寫入共享的磁碟陣列中。

我們知道IO請求在計算機請求中是非常緩慢的，這樣的架構設計，更加突出了IO讀寫的性能瓶頸。企業的應對辦法則是購買性能更好，更昂貴的磁碟陣列，提升IO性能，這也導致了IOE架構在很長一段時間內佔據著國內IT採購的主流地位。

第二個問題：

擴展能力有限，增加節點的性能收益並非線性增強

正如上面提到的，因為受限於IO請求的性能瓶頸。各個節點的交易數據發起IO請求將數據寫入磁碟會有一定的間隔。而這個過程中，實時交易信息則是由IPC協議在各個節點間傳輸內存數據來同步的。這時我們需要一個高速的數據傳輸網路，一般是由千兆網卡來完成。

但是，隨著節點的不斷越多，需要同步的交易數據就會越多，網路爭用和行鎖爭用也會變得越來越嚴重，從而導致擴展節點的性能收益並非線性增強。

第二個階段：分散式資料庫時代

隨著淘寶業務的飛速發展，2010年時，淘寶已經成為Oracle中國的頂級的客戶了。為了降低IT成本同時滿足業務的進一步發展需求，也鑒於在開源社區長期的技術積累驅動。2010年時，由淘寶技術團隊開啟了轟轟烈烈的「去IOE」運動，目標是用分散式的開源資料庫架構替代傳統的Oracle DB架構。淘寶「去IOE」的成功，有效的驗證了分散式資料庫在大規模生產應用中的負載能力，這也促使後續國內IT架構選型思路的轉變，以及分散式資料庫架構的演進。

分散式的資料庫方案有非常多種，目前在各個互聯網公司應用的也比較普遍，其本質就是將數據拆分存儲到不同的節點上，從而緩解單節點讀寫的壓力，比如按奇偶拆分數據就是一個簡單的分散式系統，示意圖如下：

當我們將數據拆分成分散式資料庫之後，就不得不考慮，分散式帶來的三個特性之間的權衡，正如 CAP所描述的：

C

Consistent ，各個節點數據始終是一致性

A

Available ，在可容忍的時間內，交易請求有返回結果

P

Partition tolerant ，單個分區宕機或斷網，系統依然可使用

系統架構師需要根據業務，用各種變通的手法優化CAP的三個特性，讓系統最終體現的效果可以與業務需求的預期一致。

目前看到的一些主流分散式方案，對這3個特性都有不同程度的選擇。我們在運營上一個創業項目OneAPM時，為了解決處理用戶訪問軌跡而產生的海量數據的問題，曾綜合使用過Kafka、Zookeeper、Clickhouse等架構來滿足業務需求，架構圖如下：

圖2 OneAPM AI 產品分散式架構圖

第三個階段：區塊鏈時代

從資料庫技術的角度來看，區塊鏈的本質是一個特定架構的多活分散式資料庫。分散式資料庫利用Paxos、RAFT等演算法來保障資料庫多副本的強一致性，而區塊鏈是用共識演算法來解決各個節點間數據一致性的問題。

POW、POS、DPOS等各類共識演算法其本質都是在競爭將由哪個節點擁有寫入區塊（賬本數據）的權力。在區塊鏈的經濟模型的設計中，對寫入區塊的行為進行了經濟激勵，極大的鼓舞了區塊鏈生態的發展。

但也正是因為每個節點都有可能擁有寫入區塊的權力，為了保障系統數據一致性，必須與系統的響應時間之間做出權衡。所以我們看到比特幣的 TPS是每秒7比業務，以太坊的 TPS也只有每秒幾十筆業務。分散式資料庫中的CAP問題，依然是區塊鏈需要挑戰的技術難題。

此外，從產品的功能上來看，目前的區塊鏈技術主要提供的交易記賬的能力，並不能支撐資料庫的標準能力「增刪改查」，所以以功能而言，目前的區塊鏈本質是資料庫技術棧的特殊子集。在區塊鏈上，擴充對文件和數據增刪改查的能力是DAPP生態發展的關鍵能力。

縱觀資料庫系統演進的這3個時代，技術發展的浪潮無法阻擋，我們唯一可以做的只有學習和面對。正如分散式資料庫最終替代了傳統 Oracle集群，去中心化模型的區塊鏈技術也將迭代中心化模型的業務系統。從目前的情況看，分片，閃電網路等新技術的出現，交易性能瓶頸在被不斷的優化，區塊鏈技術也正在逐步的向主流IT架構演進。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！