互聯網和移動應用的普及讓人們使用信息服務越來越方便，也使各類信息系統面臨著越來越大的數據規模和訪問請求的壓力。隨著分布式數據庫在互聯網行業的廣泛應用，通過分布式數據庫來擴展信息系統的處理能力，成為近年來服務提供商的一種普遍選擇。目前，分布式數據庫解決方案已經呈現百花齊放的態勢，如何選擇合適的分布式數據庫又成為困擾決策者的一個問題。

從技術角度來看，分布式數據庫解決方案大致可以分為兩大類，即分布式數據庫中間件和原生分布式數據庫。分布式數據庫中間件是架構在多個傳統單點數據庫系統上的中間層解決方案，通過將數據分拆到不同的數據庫節點上，利用中間件來管理和訪問各個數據庫中的數據，通常需要用戶參與到數據分拆和節點管理過程中。互聯網行業最初所使用的分布式數據庫方案多是基于中間件的，在解決服務壓力問題上也取得了較好的效果，但同時也暴露出不少問題。原生分布式數據庫是指從架構設計、底層存儲和查詢處理均面向分布式數據管理需求，數據庫集群作為一個整體對外提供服務，用戶無需關注集群內部的實現細節。由于原生數據庫系統開發的難度大，最初的版本通常功能簡單，限制了其應用的場景。隨著版本的不斷成熟，原生分布式數據庫已經展現出了取代分布式數據庫中間件的趨勢。

本文將從數據可靠性、副本同步和服務可用性等幾個方面進行分析，對比兩種方案的區別。

數據可靠性

幾乎所有的分布式數據庫解決方案都宣稱可以在普通PC服務器集群上實現超過高端共享存儲的數據可靠性。這一點都是通過冗余來實現的，即將數據進行分片，然后將每個分片復制出n個副本，并且存儲在集群中的n個不同節點上，當集群中宕機的節點數少于n時，總能保證有一個副本的數據不會丟失。由于節點宕機等原因導致分片副本的數量少于n時，需要通過將副本復制到新節點來保證副本數量。

在分布式數據庫中間件方案中，由于底層的每個節點都是一個獨立的數據庫系統，中間件很難實現分片副本在不同節點間的復制，因此多利用底層數據庫的主備同步機制為每個節點配置獨立的備份節點。為了實現更好的數據可靠性，通常需要一主兩備3個副本，這樣會導致服務器利用率降低和管理的復雜性升高。對于原生分布式數據庫系統來說，系統支持數據的自動分片，以及分片副本在集群節點間的自動遷移和復制，實現負載均衡，在服務器利用率和管理復雜性上均明顯優于中間件方案。

副本同步

多副本技術雖然保證了分布式數據庫中的數據可靠性，但同時帶來了副本同步的問題，即如何保證數據分片不同副本的同步更新。具體實現副本同步的技術可以分為四類：

a) 更新主副本，同步復制到從副本：數據副本有主從之分，所有的更新發生在主副本，當更新被同步復制到從副本后，更新完成。這種方式可以保證副本間的數據一致性，但更新的性能會受節點間通訊影響。

b) 更新主副本，異步復制到從副本：數據副本有主從之分，所有的更新發生在主副本，且即時生效，主副本的更新以異步方式復制給從副本。這種方式的更新性能較好，但不同副本間存在更新延遲，在主副本宕機場景下有丟失更新的風險。

c) 并發更新不同副本：數據副本無主從之分，數據更新可以發生在任何副本，并且更新可以同步或異步方式復制到其它副本。這種方式需要解決不同副本間的更新沖突，即所有存在沖突的更新應當以相同順序被寫入所有的副本。在更新沖突較少的場景下具有很好的更新性能。

d) 集中保存更新，定期合并副本：數據副本無主從之分，所有的更新被保存在集群中的特定節點上，定期被合并到各個副本中。這種方式易于實現，能夠保證副本間的數據一致性，并且更新性能較好，但查詢數據時需要將更新與數據副本進行融合。

不同的原生分布式數據庫系統根據針對的應用場景不同，可以選擇其中的一種或多種實現技術，并且技術實現的細節對用戶透明。對于分布式數據庫中間件來說，由于其數據副本是依賴于底層數據庫的主從復制機制實現的，只可能采用技術a或者b，并且用戶需要對每個節點的主從復制進行配置和監控。

服務可用性

服務可用性是指集群中的任何一個或多個節點宕機都不會影響數據庫服務的可用性。在分布式數據庫系統中，通常都會有管理節點和服務節點兩類角色。管理節點負責感知集群中各節點的狀態，實現管理數據分布和節點上下線等功能;服務節點中保存數據分片副本，對外提供數據庫服務。可容忍宕機節點的角色和數量是影響分布式數據庫可用性的重要因素，一般來說管理節點宕機會直接影響服務可用性，而少于數據副本數量的服務節點宕機不會影響服務可用性。

在原生分布式數據庫系統中，管理節點通常是輕節點，僅需維護數據分布等少量的元數據，通過心跳和租約機制監控集群中其它節點的狀態。為了避免管理節點宕機造成的單點故障，原生分布式數據庫中會部署多個管理節點，然后采用Paxos協議來自動選舉主管理節點。所有服務節點是對等的，通過心跳機制與主管理節點保持通訊，少于數據副本數量的服務節點宕機不會影響服務可用性。通過向主管理節點注冊，可以方便地添加新的節點，從而實現良好的擴展性。 在分布式數據庫中間件方案中，中間件節點不僅需要維護數據分布等元數據，還需要實現查詢解析、查詢重寫和結果聚合等功能，因此可以看成是包含管理節點和服務節點功能的復合節點。為了保證服務可用性，早期的中間件通常采用HA軟件來實現中間件節點的容災，但在實際使用過程中往往暴露出不夠穩定的缺點。近來，也有一些分布式數據庫中間件開始將管理功能和服務功能分離成單獨的管理節點和中間件節點，然后采用Paxos協議來自動選舉主管理節點。底層的數據庫節點雖然負責存儲數據，但并不能直接對外提供服務，必須和中間件節點配合才能對外提供服務。由于底層數據庫節點的容災是依賴于各自的主備同步機制，因此，任何一個數據庫節點的主備庫同時宕機都會導致整個系統的服務不可用。

綜合來看，影響分布式數據庫中間件解決方案服務可用性的因素要比原生分布式數據庫更多并且更復雜，需要用戶花費更多的精力去配置和管理。

跨節點訪問

將數據分片后冗余存儲于集群中的各個節點，是分布式數據庫實現大規模數據的可靠存儲的有效手段。然而，當用戶需要在一個事務中同時訪問位于不同節點上的數據時，如何保證事務的ACID特性成為所有解決方案的共同難題。有一些分布式數據庫中間件產品建議用戶對數據進行劃分，避免出現跨節點訪問數據，從一定程度上來緩解這個難題;在無法避免跨節點訪問數據時，通過最終一致性和補償機制來解決。然而，一方面這種思路大幅度增加了用戶使用的難度，另一方面，很多場景下是無法應用最終一致性和補償機制的。

目前，兩階段提交協議(2PC)是公認的解決這一難題的有效手段。2PC是一種阻塞協議，即當事務處理過程中出現協調者故障時，部分參與者的事務會處于未決狀態，影響到所涉及數據的可用性，必須等待協調者恢復后才能解決。分布式數據庫系統中2PC實現效率和故障恢復機制是影響跨節點事務性能的主要因素。對于原生分布式數據庫系統來說，在協議通訊、日志系統和恢復算法方面是作為一個整體進行規劃和實現的，比較容易實現一個高效的2PC機制。也有一些原生分布式數據庫產品將基線數據和增量數據分開管理，通過集中進行事務處理，以犧牲單個查詢性能的代價，有效地避免了分布式事務。對于分布式數據庫中間件來說，底層的節點都是獨立的數據庫系統，有各自的日志系統和事務處理機制，只能在中間件節點上來實現2PC，其實現的難度相當于重寫一個數據庫引擎，所實現的效率也難以與原生數據庫相媲美。因此，雖然有部分分布式數據庫中間件也提供2PC的支持，但通常不建議用戶使用或者建議用戶自行解決使用過程中的未決事務。

數據快照

分布式系統中的時間同步是一個難以解決的問題。使用NTP協議或原子鐘對每個節點的時鐘進行同步，能夠滿足對時效性要求不高的應用需求，但對于毫秒級的交易系統來說，所存在的誤差仍然是不可接受的。在分布式數據庫系統中，基于各節點的時間來獲取一個全局的數據快照是不可行的，存在著數據不一致的風險。通常的解決辦法是設置一個全局協調者，來為所有的事務分配全局唯一的事務號，這個事務號可以作為一個邏輯時間來使用。

對于原生分布式數據庫系統，全局唯一事務號分配機制是集成在事務處理過程中的，并沒有額外的處理開銷。而對于分布式數據庫中間件來說，底層的每個數據庫節點都有自己獨立的事務處理機制，如果不設置全局協調者來分配全局唯一的事務號，則在不停機的狀態下用戶無法獲取統一的全局數據快照;如果設置全局協調者來分配事務號，一方面會增加額外申請事務號的開銷，另一方面還需要對底層數據庫節點的事務處理機制進行改造，使其必須按照事務號順序執行事務，這都會對極大地影響數據庫的性能。

小結

分布式數據庫中間件技術是十多年前伴隨互聯網應用的興起而發展起來的，幫助很多互聯網企業有效地解決了控制成本和應對服務壓力等問題，也誕生了很多優秀的中間件產品，但同時也暴露出對應用開發的侵入、功能性能受限和管理運維難度大等問題。究其原因，這類技術是在特定的歷史時期利用現有數據庫產品來解決問題的一種應用級方案，雖然其中用到了一些數據庫實現技術，但本質上并不是一個數據庫系統。原生分布式數據庫系統從誕生之初便是針對大規模數據存儲和高并發數據訪問而設計的系統級解決方案，假以時日，它一定會取代中間件成為這一領域的主流技術。