基于確定性的分布式數據庫中間件設計及實現

王會羽， 夏飛， 黃迅， 戚林成

(國網江蘇省電力有限公司 信息通信分公司， 江蘇 南京 210000)

0 引言

當前正處于信息技術快速發展的階段，許多新的網絡傳輸技術以及計算機處理技術都獲得了廣泛應用，對整個社會的生產生活方式造成了明顯影響[1-3]，同時也產生了大量的數據，因此對于存儲設備的容量與數據處理效率都提出了更高的要求，在這種情況下采用普通的單體數據庫已無法滿足實際應用需求，許多企業只能通過分布式數據庫系統來存儲大量的數據[4-7]。該數據庫的特點是可以能夠對節點進行線性增加，因此具有良好的可擴展性，從而使整個系統獲得更大的吞吐量[8-9]。根據相關研究可知，現階段分布式數據庫因具備分布式ACID屬性，從而對其數據擴展造成了明顯的約束[10-11]。隨著分布式數據庫中的節點不斷增加達到某一臨界值后，便會降低數據庫性能的提升速率，最終處于一個相對穩定的狀態。因此，如何更有效地提高可擴展性以達到高擴展性水平，同時依然具備事務ACID屬性成為了當前研究分布式數據庫的一項關鍵內容[12]。

本文采用確定性執行策略構建得到分布式數據庫，同時克服數據庫所具有的不確定性。現階段人們已經開發出了許多不同功能的數據庫中間件，不過這些產品都無法滿足確定性執行策略的應用條件。針對上述情況，本文對數據庫中間件進行了重新優化設計，同時分析了此數據庫的各中間模塊能夠實現的具體功能。

1 中間件集群技術

中間件集群技術指的是以特定方式來組合多個獨立運作的分布式數據庫，并以中間件對上述過程實施協調。可以利用數據庫中間件來獨立歸類網絡通信和數據庫的訪問類型，以此消除各平臺差異性，能夠實現對各類異構平臺進行數據庫訪問的功能。分布式數據庫內的中間件位置，如圖1所示。

圖1 數據庫中間件位置

由技術人員對中間件進行了長期改進后，目前已在市場上獲得全面應用。該技術的優點較多，主要表現如下。首先，此技術具備良好的運行安全性。可以利用中間件來連接數據庫和外部系統，能夠消除不必要的限制，當外部對數據庫進行訪問的過程中應符合中間件設置的協議，如果為滿足設定要求則中間件可能會拒絕來自外界的數據庫訪問請求。此外，也可以通過中間件來篩選外部連接方式，能夠排出存在風險的訪問操作，確保數據庫達到安全運行的目標。其次，具備良好的使用性能。當應用層以中間件進行數據庫訪問的時候，底層結構可以被中間件所屏蔽，中間件接收應用層的請求后再執行相關操作，之后再把得到的結果反饋至應用層，由此能夠以更加高效、便捷的方式開發得到所需的應用程序。當現有條件下，通過中間件來實現數據訪問已經成為分布式存儲的一種重要模式，并且還可以實現數據的一致性與可靠性。

2 系統整體架構及關鍵模塊的設計

應用Calvin數據庫時，系統通常被分成存儲層、排序層、應用層、調用層，本研究采用Calvin數據庫來整合各層的功能，可以將其置于數據庫中來實現上述功能，通常可以把此系統分成不同的功能層。上述系統的具體各個組成部分，如圖2所示。

圖2 中間件系統架構圖

事務請求通過應用層進行發送，并將數據存儲到數據庫層中，利用中間件層來實現連接應用層和數據庫層的過程，同時可以將其作為中間件集群進行處理。為了保證底層數據庫符合確定性條件，需要以中間件作為連接結構。并且以中間件層進行事務請求時，可以使應用層操作獲得充分簡化。

各數據庫中間件與同一底層數據庫相對應，信息的交換需要以中間件構建連接通道，再跟底層數據庫之間完成數據交換過程。通過分析可知，在數據庫中間件中包含了二個功能模塊，具體功能結構，如圖3所示。

圖3 中間件功能結構圖

2.1 數據收發功能的設計

由于在數據傳輸過程中需要為應用層設置和中間件連接的結構，這時需要發揮數據收發接口的作用，并以此作為連接橋梁來完成對事務請求的分析，實現對各項參數的全局定序并把計算得到的結果傳輸到對應的管理子模塊內。本數據系統進行數據收發的工作模式，如圖4所示。

圖4 數據收發示意圖

為了保證應用層數據獲得了準確接收，需利用專業化監聽設施對數據通信子模塊狀況進行檢測，在初始化系統的時候需要對監聽器也進行同步初始化，同時確保實現實時監聽的功能。當來自應用層的事務數量滿足監聽器設置條件時，需把接收到的參數傳輸至數據通信子模塊再對其進行計算分析，由此實現接收數據的過程。

2.2 消息定序功能的設計

數據定序處理屬于通信子模塊的一項關鍵功能，可以有效滿足事務請求全局定序的需求，并且通常會以協商方法構建符合要求的序列。對于上述通過確定性執行策略實現的分布式數據庫進行分析可以發現，其中包含了許多不同的數據庫中間件，為方便區分，需對各數據庫中間件實施編號。

完成數據庫中間件的編號后，再選擇合適的主節點。需通過主節點準確判斷各事務的運行先后順序，考慮到數據庫中間件的數量較多，當不存在主節點時，可以通過數據庫中間件把得到的處理結果傳輸到應用層，采用上述處理方法會造成網絡中產生大量的通信數據，從而造成堵塞的問題，導致性能得不到充分利用，由此提高了應用層接收與識別的難度。當主節點屬于數據庫中間件時，更加快速地接收和分辨最終處理結果。

在各Layer中傳輸數據時，應先結合實際需求構建一個Event，其類型需要結合實際應用條件進行分析，在此基礎上滿足相應的功能。當Event構建結束后，再利用Appia接口函數來發送數據。考慮到在Qos內含有多個層結構，并且各Laye都有對應的Qos位置，因此在傳遞Event的過程中應規定實際傳遞方向，可以選擇UP或選擇DOWN等不同形式。利用這種設置便能夠將Event傳輸至對應Layer的相鄰層中再進行分析。

(1) 主節點進行原子廣播。當DdChannel接收Event后，需要先把Event傳遞至DdAppl內再對其進行計算。當判斷結果屬于主節點時應構建PaxosPropose類型的Event時，則將其傳輸至其它數據庫中間件第三層DdAccept中；當判斷發現不屬于主節點時，需把Event的數據賦值到DdTOB的cachedTom變量中，以Event的epoch值作為該節點epoch。上述具體過程，如圖5所示。

(2) 利用主節點DdAccept監聽來自其它各數據庫的Event數據包。如果此Event屬于WriteAck，則判斷WriteAck內的epoch，當兩者不同時將其拋棄，當具有和主節點相同的epoch時，則對主節點的WriteAck數增加1。如果WriteAck包的數量增加至數據庫總量50%以上時，表明此時事務請求可以達到全局有序狀態。當主節點DdTOB接收PaxosReturn時，把cachedTom的參數傳遞給DdTomResult類的Event，同時往上傳輸到DdAppl中再對其實施計算。上述處理過程的具體流程，如圖6所示。

圖5 發送原子廣播

圖6 主節點判斷流程圖

3 數據通信子模塊的實現

通過數據通信子模塊構建得到數據傳輸的通道，同時將處理后事務請求序列傳輸到事務管理子模塊。該模塊總共含有服務器端和客戶端共兩類，可以通過ServerAppl類與ClientAppl類來實現相關功能。上述二個類可以通過P2PMessage來完成通信，為便于監聽P2PMessage，兩者都需要保持與P2PMessagelistener接口同樣的屬性。

由于P2PMessage是對Serializable接口進行繼承得到的結果，這使得P2PMessage具有可序列化的特征。P2PMessage的具體結構，如表1所示。

表1 P2PMessage結構

3.1 數據收發功能的實現

系統利用數據收發功能來連接數據庫的不同功能層，再把完成全局定序處理后的事務轉移至事務管理子模塊中。

在事務管理子模塊中進行Storedl數據存儲，之后再把接收到的數據在Storedl內完成打包處理。需要先進行數據存儲后再運行事務管理子模塊，接著再把Storedl包含的各項參數傳輸至存儲結構中并執行相關操作。在接收數據時形成的函數調用時序，如圖7所示。

圖7 數據接收功能時序圖

利用數據通信子模塊完成數據定序后，再將其傳輸至Message()函數，利用此函數調用Messag(e)函數，在事務管理子模塊中執行TotalOrder Message。進行數據發送的具體時序結構，如圖8所示。

圖8 數據發送時序圖

3.2 消息定序功能的實現

通過客戶端的ClientAppl類把Storedl序列傳輸至P2pMessage，之后由服務器ServerAppl類接收ClientAppl類sendP2pMessage()函數。具體時序圖，如圖9所示。

圖9 Client時序圖

利用主節點DdAccept類的handleWriteAck()函數來監聽writeAck包。此時只存在主節點DdAccept類處理writeAck包，而其它各節點則不會對writeAck包進行接收。在handleWriteAck()中包含了全局變量wAck，對于來自其它數據庫的中間件WriteAck，將會先分析epoch與之前epoch是否一致。當兩者不同時進入等待狀態，當兩者相同時對全局變量wAck進行增加1的數量。上述處理過程的具體流程，如圖10所示。

圖10 處理WriteAck流程圖

4 總結

1) 在分析分布式數據庫內的中間件位置的基礎上，對系統整體架構及關鍵模塊展開了設計。采用Calvin數據庫來整合各層的功能，可以將其置于數據庫中來實現上述功能。給出了本數據系統進行數據收發的工作模式。完成數據庫中間件的編號后，再選擇合適的主節點。當主節點屬于數據庫中間件時，更加快速地接收和分辨最終處理結果。

2) 通過數據通信子模塊構建得到數據傳輸的通道，同時將處理后事務請求序列傳輸到事務管理子模塊。系統利用數據收發功能來連接數據庫的不同功能層，再把完成全局定序處理后的事務轉移至事務管理子模塊中。通過客戶端的ClientAppl類把Storedl序列傳輸至P2pMessage，之后由服務器實現消息定序功能。