王會羽, 夏飛, 黃迅, 戚林成
(國網(wǎng)江蘇省電力有限公司 信息通信分公司, 江蘇 南京 210000)
當(dāng)前正處于信息技術(shù)快速發(fā)展的階段,許多新的網(wǎng)絡(luò)傳輸技術(shù)以及計(jì)算機(jī)處理技術(shù)都獲得了廣泛應(yīng)用,對整個(gè)社會的生產(chǎn)生活方式造成了明顯影響[1-3],同時(shí)也產(chǎn)生了大量的數(shù)據(jù),因此對于存儲設(shè)備的容量與數(shù)據(jù)處理效率都提出了更高的要求,在這種情況下采用普通的單體數(shù)據(jù)庫已無法滿足實(shí)際應(yīng)用需求,許多企業(yè)只能通過分布式數(shù)據(jù)庫系統(tǒng)來存儲大量的數(shù)據(jù)[4-7]。該數(shù)據(jù)庫的特點(diǎn)是可以能夠?qū)?jié)點(diǎn)進(jìn)行線性增加,因此具有良好的可擴(kuò)展性,從而使整個(gè)系統(tǒng)獲得更大的吞吐量[8-9]。根據(jù)相關(guān)研究可知,現(xiàn)階段分布式數(shù)據(jù)庫因具備分布式ACID屬性,從而對其數(shù)據(jù)擴(kuò)展造成了明顯的約束[10-11]。隨著分布式數(shù)據(jù)庫中的節(jié)點(diǎn)不斷增加達(dá)到某一臨界值后,便會降低數(shù)據(jù)庫性能的提升速率,最終處于一個(gè)相對穩(wěn)定的狀態(tài)。因此,如何更有效地提高可擴(kuò)展性以達(dá)到高擴(kuò)展性水平,同時(shí)依然具備事務(wù)ACID屬性成為了當(dāng)前研究分布式數(shù)據(jù)庫的一項(xiàng)關(guān)鍵內(nèi)容[12]。
本文采用確定性執(zhí)行策略構(gòu)建得到分布式數(shù)據(jù)庫,同時(shí)克服數(shù)據(jù)庫所具有的不確定性?,F(xiàn)階段人們已經(jīng)開發(fā)出了許多不同功能的數(shù)據(jù)庫中間件,不過這些產(chǎn)品都無法滿足確定性執(zhí)行策略的應(yīng)用條件。針對上述情況,本文對數(shù)據(jù)庫中間件進(jìn)行了重新優(yōu)化設(shè)計(jì),同時(shí)分析了此數(shù)據(jù)庫的各中間模塊能夠?qū)崿F(xiàn)的具體功能。
中間件集群技術(shù)指的是以特定方式來組合多個(gè)獨(dú)立運(yùn)作的分布式數(shù)據(jù)庫,并以中間件對上述過程實(shí)施協(xié)調(diào)。可以利用數(shù)據(jù)庫中間件來獨(dú)立歸類網(wǎng)絡(luò)通信和數(shù)據(jù)庫的訪問類型,以此消除各平臺差異性,能夠?qū)崿F(xiàn)對各類異構(gòu)平臺進(jìn)行數(shù)據(jù)庫訪問的功能。分布式數(shù)據(jù)庫內(nèi)的中間件位置,如圖1所示。
圖1 數(shù)據(jù)庫中間件位置
由技術(shù)人員對中間件進(jìn)行了長期改進(jìn)后,目前已在市場上獲得全面應(yīng)用。該技術(shù)的優(yōu)點(diǎn)較多,主要表現(xiàn)如下。首先,此技術(shù)具備良好的運(yùn)行安全性。可以利用中間件來連接數(shù)據(jù)庫和外部系統(tǒng),能夠消除不必要的限制,當(dāng)外部對數(shù)據(jù)庫進(jìn)行訪問的過程中應(yīng)符合中間件設(shè)置的協(xié)議,如果為滿足設(shè)定要求則中間件可能會拒絕來自外界的數(shù)據(jù)庫訪問請求。此外,也可以通過中間件來篩選外部連接方式,能夠排出存在風(fēng)險(xiǎn)的訪問操作,確保數(shù)據(jù)庫達(dá)到安全運(yùn)行的目標(biāo)。其次,具備良好的使用性能。當(dāng)應(yīng)用層以中間件進(jìn)行數(shù)據(jù)庫訪問的時(shí)候,底層結(jié)構(gòu)可以被中間件所屏蔽,中間件接收應(yīng)用層的請求后再執(zhí)行相關(guān)操作,之后再把得到的結(jié)果反饋至應(yīng)用層,由此能夠以更加高效、便捷的方式開發(fā)得到所需的應(yīng)用程序。當(dāng)現(xiàn)有條件下,通過中間件來實(shí)現(xiàn)數(shù)據(jù)訪問已經(jīng)成為分布式存儲的一種重要模式,并且還可以實(shí)現(xiàn)數(shù)據(jù)的一致性與可靠性。
應(yīng)用Calvin數(shù)據(jù)庫時(shí),系統(tǒng)通常被分成存儲層、排序?qū)?、?yīng)用層、調(diào)用層,本研究采用Calvin數(shù)據(jù)庫來整合各層的功能,可以將其置于數(shù)據(jù)庫中來實(shí)現(xiàn)上述功能,通??梢园汛讼到y(tǒng)分成不同的功能層。上述系統(tǒng)的具體各個(gè)組成部分,如圖2所示。
圖2 中間件系統(tǒng)架構(gòu)圖
事務(wù)請求通過應(yīng)用層進(jìn)行發(fā)送,并將數(shù)據(jù)存儲到數(shù)據(jù)庫層中,利用中間件層來實(shí)現(xiàn)連接應(yīng)用層和數(shù)據(jù)庫層的過程,同時(shí)可以將其作為中間件集群進(jìn)行處理。為了保證底層數(shù)據(jù)庫符合確定性條件,需要以中間件作為連接結(jié)構(gòu)。并且以中間件層進(jìn)行事務(wù)請求時(shí),可以使應(yīng)用層操作獲得充分簡化。
各數(shù)據(jù)庫中間件與同一底層數(shù)據(jù)庫相對應(yīng),信息的交換需要以中間件構(gòu)建連接通道,再跟底層數(shù)據(jù)庫之間完成數(shù)據(jù)交換過程。通過分析可知,在數(shù)據(jù)庫中間件中包含了二個(gè)功能模塊,具體功能結(jié)構(gòu),如圖3所示。
圖3 中間件功能結(jié)構(gòu)圖
由于在數(shù)據(jù)傳輸過程中需要為應(yīng)用層設(shè)置和中間件連接的結(jié)構(gòu),這時(shí)需要發(fā)揮數(shù)據(jù)收發(fā)接口的作用,并以此作為連接橋梁來完成對事務(wù)請求的分析,實(shí)現(xiàn)對各項(xiàng)參數(shù)的全局定序并把計(jì)算得到的結(jié)果傳輸?shù)綄?yīng)的管理子模塊內(nèi)。本數(shù)據(jù)系統(tǒng)進(jìn)行數(shù)據(jù)收發(fā)的工作模式,如圖4所示。
圖4 數(shù)據(jù)收發(fā)示意圖
為了保證應(yīng)用層數(shù)據(jù)獲得了準(zhǔn)確接收,需利用專業(yè)化監(jiān)聽設(shè)施對數(shù)據(jù)通信子模塊狀況進(jìn)行檢測,在初始化系統(tǒng)的時(shí)候需要對監(jiān)聽器也進(jìn)行同步初始化,同時(shí)確保實(shí)現(xiàn)實(shí)時(shí)監(jiān)聽的功能。當(dāng)來自應(yīng)用層的事務(wù)數(shù)量滿足監(jiān)聽器設(shè)置條件時(shí),需把接收到的參數(shù)傳輸至數(shù)據(jù)通信子模塊再對其進(jìn)行計(jì)算分析,由此實(shí)現(xiàn)接收數(shù)據(jù)的過程。
數(shù)據(jù)定序處理屬于通信子模塊的一項(xiàng)關(guān)鍵功能,可以有效滿足事務(wù)請求全局定序的需求,并且通常會以協(xié)商方法構(gòu)建符合要求的序列。對于上述通過確定性執(zhí)行策略實(shí)現(xiàn)的分布式數(shù)據(jù)庫進(jìn)行分析可以發(fā)現(xiàn),其中包含了許多不同的數(shù)據(jù)庫中間件,為方便區(qū)分,需對各數(shù)據(jù)庫中間件實(shí)施編號。
完成數(shù)據(jù)庫中間件的編號后,再選擇合適的主節(jié)點(diǎn)。需通過主節(jié)點(diǎn)準(zhǔn)確判斷各事務(wù)的運(yùn)行先后順序,考慮到數(shù)據(jù)庫中間件的數(shù)量較多,當(dāng)不存在主節(jié)點(diǎn)時(shí),可以通過數(shù)據(jù)庫中間件把得到的處理結(jié)果傳輸?shù)綉?yīng)用層,采用上述處理方法會造成網(wǎng)絡(luò)中產(chǎn)生大量的通信數(shù)據(jù),從而造成堵塞的問題,導(dǎo)致性能得不到充分利用,由此提高了應(yīng)用層接收與識別的難度。當(dāng)主節(jié)點(diǎn)屬于數(shù)據(jù)庫中間件時(shí),更加快速地接收和分辨最終處理結(jié)果。
在各Layer中傳輸數(shù)據(jù)時(shí),應(yīng)先結(jié)合實(shí)際需求構(gòu)建一個(gè)Event,其類型需要結(jié)合實(shí)際應(yīng)用條件進(jìn)行分析,在此基礎(chǔ)上滿足相應(yīng)的功能。當(dāng)Event構(gòu)建結(jié)束后,再利用Appia接口函數(shù)來發(fā)送數(shù)據(jù)??紤]到在Qos內(nèi)含有多個(gè)層結(jié)構(gòu),并且各Laye都有對應(yīng)的Qos位置,因此在傳遞Event的過程中應(yīng)規(guī)定實(shí)際傳遞方向,可以選擇UP或選擇DOWN等不同形式。利用這種設(shè)置便能夠?qū)vent傳輸至對應(yīng)Layer的相鄰層中再進(jìn)行分析。
(1) 主節(jié)點(diǎn)進(jìn)行原子廣播。當(dāng)DdChannel接收Event后,需要先把Event傳遞至DdAppl內(nèi)再對其進(jìn)行計(jì)算。當(dāng)判斷結(jié)果屬于主節(jié)點(diǎn)時(shí)應(yīng)構(gòu)建PaxosPropose類型的Event時(shí),則將其傳輸至其它數(shù)據(jù)庫中間件第三層DdAccept中;當(dāng)判斷發(fā)現(xiàn)不屬于主節(jié)點(diǎn)時(shí),需把Event的數(shù)據(jù)賦值到DdTOB的cachedTom變量中,以Event的epoch值作為該節(jié)點(diǎn)epoch。上述具體過程,如圖5所示。
(2) 利用主節(jié)點(diǎn)DdAccept監(jiān)聽來自其它各數(shù)據(jù)庫的Event數(shù)據(jù)包。如果此Event屬于WriteAck,則判斷WriteAck內(nèi)的epoch,當(dāng)兩者不同時(shí)將其拋棄,當(dāng)具有和主節(jié)點(diǎn)相同的epoch時(shí),則對主節(jié)點(diǎn)的WriteAck數(shù)增加1。如果WriteAck包的數(shù)量增加至數(shù)據(jù)庫總量50%以上時(shí),表明此時(shí)事務(wù)請求可以達(dá)到全局有序狀態(tài)。當(dāng)主節(jié)點(diǎn)DdTOB接收PaxosReturn時(shí),把cachedTom的參數(shù)傳遞給DdTomResult類的Event,同時(shí)往上傳輸?shù)紻dAppl中再對其實(shí)施計(jì)算。上述處理過程的具體流程,如圖6所示。
圖5 發(fā)送原子廣播
圖6 主節(jié)點(diǎn)判斷流程圖
通過數(shù)據(jù)通信子模塊構(gòu)建得到數(shù)據(jù)傳輸?shù)耐ǖ溃瑫r(shí)將處理后事務(wù)請求序列傳輸?shù)绞聞?wù)管理子模塊。該模塊總共含有服務(wù)器端和客戶端共兩類,可以通過ServerAppl類與ClientAppl類來實(shí)現(xiàn)相關(guān)功能。上述二個(gè)類可以通過P2PMessage來完成通信,為便于監(jiān)聽P2PMessage,兩者都需要保持與P2PMessagelistener接口同樣的屬性。
由于P2PMessage是對Serializable接口進(jìn)行繼承得到的結(jié)果,這使得P2PMessage具有可序列化的特征。P2PMessage的具體結(jié)構(gòu),如表1所示。
表1 P2PMessage結(jié)構(gòu)
系統(tǒng)利用數(shù)據(jù)收發(fā)功能來連接數(shù)據(jù)庫的不同功能層,再把完成全局定序處理后的事務(wù)轉(zhuǎn)移至事務(wù)管理子模塊中。
在事務(wù)管理子模塊中進(jìn)行Storedl數(shù)據(jù)存儲,之后再把接收到的數(shù)據(jù)在Storedl內(nèi)完成打包處理。需要先進(jìn)行數(shù)據(jù)存儲后再運(yùn)行事務(wù)管理子模塊,接著再把Storedl包含的各項(xiàng)參數(shù)傳輸至存儲結(jié)構(gòu)中并執(zhí)行相關(guān)操作。在接收數(shù)據(jù)時(shí)形成的函數(shù)調(diào)用時(shí)序,如圖7所示。
圖7 數(shù)據(jù)接收功能時(shí)序圖
利用數(shù)據(jù)通信子模塊完成數(shù)據(jù)定序后,再將其傳輸至Message()函數(shù),利用此函數(shù)調(diào)用Messag(e)函數(shù),在事務(wù)管理子模塊中執(zhí)行TotalOrder Message。進(jìn)行數(shù)據(jù)發(fā)送的具體時(shí)序結(jié)構(gòu),如圖8所示。
圖8 數(shù)據(jù)發(fā)送時(shí)序圖
通過客戶端的ClientAppl類把Storedl序列傳輸至P2pMessage,之后由服務(wù)器ServerAppl類接收ClientAppl類sendP2pMessage()函數(shù)。具體時(shí)序圖,如圖9所示。
圖9 Client時(shí)序圖
利用主節(jié)點(diǎn)DdAccept類的handleWriteAck()函數(shù)來監(jiān)聽writeAck包。此時(shí)只存在主節(jié)點(diǎn)DdAccept類處理writeAck包,而其它各節(jié)點(diǎn)則不會對writeAck包進(jìn)行接收。在handleWriteAck()中包含了全局變量wAck,對于來自其它數(shù)據(jù)庫的中間件WriteAck,將會先分析epoch與之前epoch是否一致。當(dāng)兩者不同時(shí)進(jìn)入等待狀態(tài),當(dāng)兩者相同時(shí)對全局變量wAck進(jìn)行增加1的數(shù)量。上述處理過程的具體流程,如圖10所示。
圖10 處理WriteAck流程圖
1) 在分析分布式數(shù)據(jù)庫內(nèi)的中間件位置的基礎(chǔ)上,對系統(tǒng)整體架構(gòu)及關(guān)鍵模塊展開了設(shè)計(jì)。采用Calvin數(shù)據(jù)庫來整合各層的功能,可以將其置于數(shù)據(jù)庫中來實(shí)現(xiàn)上述功能。給出了本數(shù)據(jù)系統(tǒng)進(jìn)行數(shù)據(jù)收發(fā)的工作模式。完成數(shù)據(jù)庫中間件的編號后,再選擇合適的主節(jié)點(diǎn)。當(dāng)主節(jié)點(diǎn)屬于數(shù)據(jù)庫中間件時(shí),更加快速地接收和分辨最終處理結(jié)果。
2) 通過數(shù)據(jù)通信子模塊構(gòu)建得到數(shù)據(jù)傳輸?shù)耐ǖ?,同時(shí)將處理后事務(wù)請求序列傳輸?shù)绞聞?wù)管理子模塊。系統(tǒng)利用數(shù)據(jù)收發(fā)功能來連接數(shù)據(jù)庫的不同功能層,再把完成全局定序處理后的事務(wù)轉(zhuǎn)移至事務(wù)管理子模塊中。通過客戶端的ClientAppl類把Storedl序列傳輸至P2pMessage,之后由服務(wù)器實(shí)現(xiàn)消息定序功能。