海量大數據分佈式數據庫解決方案思路

前言

　　隨着互聯網的發展，分佈式技術的逐漸成熟，動態水平擴展和自動容災備份、一鍵部署等技術方案不斷成熟，各大中小互聯網企業都在嘗試切換將產品的技術方案到分佈式的方案，可是分佈式的技術方案有一個業內比較難以解決的問題，就是分佈式事務的處理，大部分都是將業務儘可能限制在同庫中，避免跨庫事務，或者採用消息隊列處理分佈式事務，或者採用DTC來處理，可是性能都不是太理想。在閱讀關於淘寶數據庫OceanBase的一些文章時受到啓發，想到一個不成熟的方案，也能夠說是對OceanBase的一些思路的總結，在這裏寫出來給你們分享一下，也歡迎指出其中不合理或可改善的地方。

使用場景

　　1.海量數據；

　　2.讀取壓力大而更新操做的場景少；

　　3.保障高可用，最終一致性；

架構圖

節點功能

1. Application Server 應用服務器，這裏只畫了一臺，實際生產環境中多是幾百上千個Host的服務，主要是業務服務；

2.Gate Gate中保持着數據中心各個功能節點的狀態信息，Application Server從Gate中獲取到須要操做的主機地址，而後再與數據中心指定的節點進行通訊；Gate中保留的節點信息會記錄節點的路由ip和端口，節點的狀態，另外記錄節點的功能特色；Gate中會開一個守護進程負責與數據中心的各個節點進行通訊(每一個節點也有專門負責通訊的守護進程)，節點的可用狀態經過心跳檢測（節點是否拓機），節點是否處於busy狀態由節點本身彙報到Gate守護進程，Gate守護進程再更新配置信息；

3.Update Master 負責數據庫的更新操做，該節點並不保存全部數據，只是在須要更新時，將須要的數據從對應的查詢庫中獲取到數據，而後在本機作事務更新，完成後，也是提交到本機。並經過某種機制(定時器或達到某個閾值)，就備份本機數據，並提交到Data Transfer Station，提交成功後，清空本地數據庫。這裏的難點是若是知道須要獲取哪些數據，個人初步思路是，由應用服務本身告訴該節點，這是最簡單的方式；

4.Update Slave:備用的Update服務器，當Master拓機時自動成爲Master代替UpdateMaster的工做。守護進程實時監控Master狀態；

5.Data Transfer Station 數據中轉中心，負責收集變動數據，並備份存儲，以防須要跟蹤或恢復數據等。在Update Master提交備份數據後，查找空閒的Dispatcher，再由Dispatcher拉去須要的數據，分發同步到Query Server中；

6.Dispatcher 數據分發器，分發器從Data Transfer Station獲取到數據，並從Gate中獲取空閒的、未同步過該數據的Query Server，並將該Query Server標記爲同步數據中，而後同步數據，同步完成後，將同步日誌記錄，返回給Data Transfer Station，接着繼續下一個Query Server進行同步，直到全部都同步完成。完成後，Data Transfer Station將該份數據標記爲全部節點已同步（同步過程當中Query Server仍是能夠提供查詢服務）；

7.Query Server 查詢服務器，負責對外的數據查詢。這裏有一點還在考慮中，就是是否採用分片，由於數據量大，不分片確定會致使單機的查詢效率降低，分片的話，如採用Hash算法計算分片，會增長查詢的複雜度，最主要是，數據下發時，須要考慮該更新的數據是在哪一個分片上，相對會比較複雜；

 

查詢數據請求流程圖（未使用Hash MapReduce，若是使用，則須要在過程當中添加Hash計算數據所在的節點）

 

更新數據請求流程圖

 

 

這裏獲取更新數據時，應該是全量的，即Update Master裏的數據+Query Server的數據+Dispatcher未分發完成的數據；舉例來講，假設查詢到的某個帳戶餘額100，000元，須要作一個轉帳業務，須要轉出10000元，而且以前已經作過一次轉帳5000元，可是這筆5000元的轉帳還未同步到查詢服務器中，那麼該次轉帳應該是100,000元減去5,000元，而後再去作轉出10,000元的操做。最終帳戶餘額應該是85,000元。另外，若是查詢要作到強一致性，也應該這樣作一個差別性數據合併，再轉發給業務服務，這樣就能作到信息的一致性和實時性。

 

以上僅提供一種思路，實現可結合本身的業務，對該解決方案作一些更改，具體選取技術。具體細節也考慮不是很周全，若有思路上的錯誤，請多指教。

 

本文原創，若有轉載，請註明出處。