[發明專利]一種強一致性的分布式鍵值數據庫系統及其讀寫方法

有效

• 申請號: 201310131454.8
• 申請日: 2013-04-16
• 公開（公告）號: CN103268318A
• 公開（公告）日: 2013-08-28
• 發明（設計）人: 馮丹;黨永興;譚支鵬;孫建良;徐鵬;劉景寧
• 申請（專利權）人: 華中科技大學
• 主分類號: G06F17/30
• 分類號: G06F17/30
• 代理公司: 華中科技大學專利中心 42201
• 代理人: 朱仁玲

技術領域

本發明屬于數據庫及數據存儲技術領域，更具體地，涉及一種強一致性的分布式鍵值數據庫系統及其讀寫方法。

背景技術

隨著數字化時代的到來，數據信息呈爆炸式增長趨勢。特別是隨著近年來web2.0時代的到來、大規模的互聯網應用的出現以及云存儲的興起，積累了大量的非結構化的數據，這些應用逐步擴展其存儲需求從而超出了傳統企業數據庫所能管理的數據容量。

針對該類場景，成功的解決方案是利用分布式鍵值（key-value）型No?sql數據庫結合壓縮、分塊等技術提高數據的壓縮效率和存儲規模。典型的分布式鍵值型No?sql數據庫有Google的Bigtable，Apache的Hbase，Amazon的Dynamo以及Yahoo的PNUTS。

除了擴展性方面的需求，許多網絡和云計算應用還需要數據庫提供24*7的高可靠、高可用性性服務，然而在數千個節點的集群中，節點失效是不可避免的，因此，需要一定的副本策略來保證系統的高可用性和容錯。一種解決方案是采用主備副本協議，然而主備協議不是一種好的解決方案，其在處理兩個節點失效時很難保證副本間的一致性以及系統的可用性；在系統中有3個及以上的副本數時，paxos協議被證明是唯一可保證副本強一致性的協議，對于有2F+1個副本的系統中，paxos協議可以容忍F個節點失效，使系統具有較高的可用性。

上述幾種典型的解決方案都存在有以下缺陷：一致性不好，或者導致開銷大。Amazon的Dynamo只能提供副本之間的最終一致性，不同副本之間的數據出現不一致時，需要使用復雜的沖突避免和解決機制；Google的Bigtable可以提供副本強一致性并且支持單操作事務，但是Bigtable依賴于GFS文件系統，Bigtable在處理事務操作時開銷很大；Yahoo的PNUTS提供弱一致性保證，而且其關注的是跨數據中心的副本一致性。

發明內容

針對現有技術的缺陷，本發明的目的在于提供一種強一致性的分布式鍵值數據庫系統，其針對現有系統的存儲引擎做了優化，并實現了在較小的開銷的情況下，提供數據副本之間的強一致性。

為實現上述目的，本發明提供了一種強一致性的分布式鍵值數據庫系統，包括客戶端和數據服務器集群，客戶端包括哈希模塊、定位模塊和轉發模塊，數據服務器集群包括多個數據區間，每個數據區間包括一個主節點和多個從節點，主節點包括第一讀模塊、寫模塊、第一恢復模塊、第一日志模塊、第一決議模塊、第一存儲引擎模塊，從節點包括第二讀模塊、第二決議模塊、第二日志模塊、第二恢復模塊、第二存儲引擎模塊，哈希模塊用于接收從客戶發來的寫請求，并根據寫請求的鍵將該寫請求定位到數據區間，每個寫請求都具有一個系統自動分配的編號，定位模塊用于將寫請求定位到數據區間的主節點，轉發模塊用于將寫請求發送到主節點的寫模塊，主節點的寫模塊用于將寫請求發送到第一日志模塊和第一決議模塊，第一日志模塊用于將寫請求寫入日志，第一決議模塊用于將寫請求發送到多個從節點的第二決議模塊，從節點的第二決議模塊用于將寫請求發送到第二日志模塊，并將應答信息發送到主節點的第一決議模塊，第二日志模塊用于將寫請求寫入日志，第一決議模塊還用于統計來自從節點的第二決議模塊的應答信息的數量，并判斷其是否大于從節點數量的一半，如果大于則表示該寫請求可以被繼續執行，將寫請求寫入主節點的第一存儲引擎模塊，否則過程結束，第一決議模塊還用于定時將提交信息發送到從節點的第二決議模塊，第二決議模塊還用于根據接收到的提交信息將寫請求寫入第二存儲引擎模塊，哈希模塊還用于接收從客戶發來的讀請求，并根據讀請求的鍵值將該讀請求定位到相應的數據區間，定位模塊還用于判斷讀請求是否需要讀取最新的數據，若是則將該讀請求定位到數據區間的主節點，否則將該讀請求定位到數據空間的主節點或任意從節點，轉發模塊還用于將讀請求發送到定位模塊所定位到的主節點的第一讀模塊或者從節點的第二讀模塊，第一讀模塊用于從轉發模塊接收讀請求，并從第一存儲引擎模塊中讀取所需數據，并將數據返回給客戶端，第二讀模塊用于從轉發模塊接收讀請求，并從第二存儲引擎模塊中讀取所需數據，并將數據返回給客戶端。

第一決議模塊具體是從系統中得到該主節點所屬數據區間的從節點ip列表，然后根據ip逐個給從節點發送寫請求以及該寫請求的編號。

第二決議模塊具體是首先獲得該從節點已經收到的寫請求的最大編號x，并跟當前收到的寫請求編號y相比，如果x+1=y，則第二決議模塊會給主節點發送應答信息，如果x+1≠y，則第二決議模塊不會給主節點發送應答信息。

提交信息為主節點最近處理的寫請求的編號。