魯 立

(武漢開目信息技術(shù)股份有限公司，湖北 武漢 430074)

產(chǎn)品生命周期管理(PLM)系統(tǒng)針對產(chǎn)品設(shè)計、開發(fā)、生產(chǎn)等各個環(huán)節(jié)進(jìn)行全生命周期管理，是制造業(yè)企業(yè)的重要支撐。目前，大部分制造企業(yè)已成立了信息化部門，采購了一定數(shù)量的微型機(jī)、服務(wù)器、數(shù)據(jù)庫、網(wǎng)絡(luò)設(shè)備等IT基礎(chǔ)設(shè)施，具備分布式系統(tǒng)的搭建條件。基礎(chǔ)設(shè)施的成熟也促進(jìn)了PLM系統(tǒng)架構(gòu)的轉(zhuǎn)變。當(dāng)前，PLM系統(tǒng)在架構(gòu)上已由單機(jī)系統(tǒng)轉(zhuǎn)變?yōu)榉植际较到y(tǒng)，采用服務(wù)化的方式構(gòu)建。分布式PLM系統(tǒng)提供包括零部件管理、文檔管理、工作流管理等多種服務(wù)，其中文檔管理尤為重要?；诜植际较到y(tǒng)的文檔管理，必須考慮其在多用戶操作場景下的數(shù)據(jù)一致性問題。

對分布式系統(tǒng)數(shù)據(jù)一致性的研究由來已久，研究方向從單一的、特定的技術(shù)方法逐步轉(zhuǎn)變到綜合的、通用的協(xié)議上來，與工業(yè)界的聯(lián)系也越來越緊密。文獻(xiàn)[1]和文獻(xiàn)[2]分別給出基于數(shù)據(jù)一致性的消息隊列的數(shù)據(jù)副本復(fù)制法和復(fù)制服務(wù)器法，二者均采用異步方式復(fù)制數(shù)據(jù)，可成功維護(hù)數(shù)據(jù)一致性，但實時性很低，且一旦失敗后數(shù)據(jù)恢復(fù)的難度很大；文獻(xiàn)[3]給出了利用ADO.NET維護(hù)數(shù)據(jù)一致性的一個工程實例，但是該實例所用的數(shù)據(jù)一致性維護(hù)方法僅適用于數(shù)據(jù)庫，并不適合散列文檔數(shù)據(jù)；文獻(xiàn)[4]提出了一種基于時間戳的數(shù)據(jù)副本一致性模型，提升了副本讀取的速度，但對于維護(hù)多源異構(gòu)數(shù)據(jù)副本同步工程實現(xiàn)的難度較大；文獻(xiàn)[5]給出了利用ZooKeeper協(xié)同系統(tǒng)回調(diào)機(jī)制實現(xiàn)元數(shù)據(jù)緩存一致性方法及其優(yōu)化方法，但受限于平臺環(huán)境，可移植性不高；文獻(xiàn)[6]和文獻(xiàn)[7]從一致性協(xié)議出發(fā)，綜述了經(jīng)典的分布式一致性協(xié)議及其在分布式數(shù)據(jù)庫系統(tǒng)中的應(yīng)用，分析評估了其實現(xiàn)的代價和局限性，并從讀寫操作、節(jié)點類型與網(wǎng)絡(luò)通信等方面進(jìn)行對比分析，對分布式系統(tǒng)一致性理論和實踐具有較強(qiáng)的指導(dǎo)意義，但缺乏適用于Windows環(huán)境下的工程實踐細(xì)節(jié)。由于PLM系統(tǒng)更多地部署在Windows環(huán)境下，管理包括數(shù)據(jù)庫和散列文檔等多種形式的數(shù)據(jù)，對數(shù)據(jù)可用性和保密性有一定的要求，因此需要進(jìn)一步研究分布式系統(tǒng)關(guān)于文檔管理的數(shù)據(jù)一致性問題。

本文首先分析了分布式系統(tǒng)中文檔管理一致性的關(guān)鍵問題，然后針對該問題提出了一種實現(xiàn)起來較為方便、易于在Windows環(huán)境下部署的解決方案，即文件操作的統(tǒng)一事務(wù)處理模型，并就文件上傳和文件刪除兩種應(yīng)用場景給出具體的操作流程，最后通過實驗驗證了該模型的可用性。

1 分布式系統(tǒng)中文檔管理的一致性問題

文檔管理有兩方面內(nèi)容：一是文檔對象的管理，文檔對象是文件的抽象，它按面向?qū)ο蟮姆绞絹砉芾砭哂泄餐瑢傩缘囊活愇募?，文件可看作是文檔對象的具體實例；二是對物理文件的管理?；诖?，分布式PLM系統(tǒng)的文檔管理包含兩個獨(dú)立的服務(wù)，一是數(shù)據(jù)服務(wù)，負(fù)責(zé)數(shù)據(jù)庫中文檔對象屬性的存儲與更新;二是文件服務(wù)，負(fù)責(zé)磁盤文件的上傳、下載、刪除等操作。這兩個分布式服務(wù)之間如何保持一致性是本文探討的核心問題。一致性包括操作一致性和事務(wù)一致性，操作一致性和事務(wù)一致性會影響系統(tǒng)的可用性[8]。對于分布式PLM系統(tǒng)而言，保證事務(wù)一致性是基本要求。

下面給出一個典型操作示例。將用戶操作記為三元組Op(User, Func, Obj)，其中User為用戶名， Func為操作方法，Obj為操作對象。假定系統(tǒng)中存在兩個用戶A和B,他們在不同的客戶端上使用系統(tǒng)。令D1為一個文檔對象，其屬性集合為{Att1,Att2,Att3}，關(guān)聯(lián)的一個物理文件為F1(F1存儲在服務(wù)端機(jī)器上)?？紤]如下場景：用戶A在文檔對象D1代表的文件集合中上傳一個新的文件F2，此時系統(tǒng)會進(jìn)行如下操作：1)Op(A,Update,D1.Attr1)，即更新文檔對象D1的屬性，添加F2作為其新的關(guān)聯(lián)文件；2)Op(A,Copy,F2 ) ，即將文件F2的實體從客戶機(jī)傳輸?shù)椒?wù)器。

上述兩個操作并沒有進(jìn)行附加的控制，因此考慮如下的可能執(zhí)行結(jié)果：操作Op(A,Update,D1.Attr1)成功，即文檔對象D1的屬性已更新，而操作Op(A,Copy,F2 )失敗，導(dǎo)致服務(wù)器上不存在文件F2。此時，若用戶B登錄系統(tǒng)，發(fā)現(xiàn)文檔對象D1包含關(guān)聯(lián)文件F2，則他會嘗試執(zhí)行預(yù)覽操作Op(B,Preview, F2) ，然而此時服務(wù)器上并不存在文件F2，于是該操作會失敗。此時文檔對象屬性和實際的文件狀態(tài)不一致，導(dǎo)致系統(tǒng)可用性降低。

造成上述不一致性問題的原因是，文件上傳服務(wù)和數(shù)據(jù)庫服務(wù)分別在兩個分布式事務(wù)的作用域中，而事務(wù)與事務(wù)之間是隔離的[9]，它們之間是相互獨(dú)立的。圖1所示為上述過程的操作模型。

圖1 獨(dú)立文檔管理事務(wù)模型

為解決上述問題，一種解決方案是采用線性消息處理，即等待數(shù)據(jù)服務(wù)的事務(wù)完成后，發(fā)送消息，通知文件服務(wù)執(zhí)行更新、刪除等操作。但是這種方案在實踐中可能造成無限等待，嚴(yán)重影響用戶體驗。本文提出另一種解決方案，即建立文檔管理的統(tǒng)一事務(wù)模型，該模型是一種基于分布式的事務(wù)模型[10]。

2 文檔管理的事務(wù)處理模型

常見的分布式事務(wù)模型包括DTP模型[11]、TCC模型、可靠消息模型和業(yè)務(wù)補(bǔ)償模型。其中，DTP模型采用2PC(兩階段提交)模式，可以保證事務(wù)的強(qiáng)一致性，且直接作用于資源層，對業(yè)務(wù)代碼沒有太多的侵入性。DTP模型具備一定的普適性，可滿足大部分場景的需求[12]。本文以DTP模型為基礎(chǔ)，構(gòu)造文檔管理的統(tǒng)一事務(wù)處理模型，將文件服務(wù)納入到該事務(wù)，與數(shù)據(jù)服務(wù)事務(wù)協(xié)同管理。

2.1 模型結(jié)構(gòu)

文檔管理統(tǒng)一事務(wù)模型基本結(jié)構(gòu)如圖2所示。

圖2 統(tǒng)一文檔管理事務(wù)模型

統(tǒng)一的文件事務(wù)處理模型為樹狀結(jié)構(gòu)，有一個根事務(wù)管理器，它負(fù)責(zé)事務(wù)的最終決斷(即提交或回滾)。該模型采用2PC模式。在第一階段，每個子事務(wù)管理器需要向上級節(jié)點報告它的狀態(tài)，這樣一直向上報告直到根事務(wù)管理器，由根事務(wù)管理器做出最終決斷。該樹狀結(jié)構(gòu)模型每個節(jié)點的決斷算法是：1)若子節(jié)點報告的全部狀態(tài)均為就緒，則向上級節(jié)點報告已就緒，可以作出提交的決斷；2)若至少有一個子節(jié)點報告的狀態(tài)為中止，則向上級節(jié)點報告，作出回滾的決斷。

一旦根事務(wù)管理器做出決斷，它會進(jìn)入第二階段，即向每個子事務(wù)管理器下發(fā)第一階段的決斷并執(zhí)行，然后將執(zhí)行結(jié)果向上級節(jié)點反饋，直至根事務(wù)管理器。當(dāng)根事務(wù)管理器收到所有節(jié)點的執(zhí)行結(jié)果后，會根據(jù)結(jié)果來判斷是否結(jié)束第二階段：1)若收到的結(jié)果全部為執(zhí)行成功，則第二階段正常結(jié)束。2)若收到的結(jié)果至少有一個執(zhí)行失敗，則根事務(wù)管理器會下發(fā)回滾通知，所有子節(jié)點執(zhí)行回滾操作。此項操作會重復(fù)3次，若3次后仍然無法全部成功，則強(qiáng)制結(jié)束第二階段，并報告異常。

如果在第一階段結(jié)束后，網(wǎng)絡(luò)斷開，則子節(jié)點無法收到根事務(wù)管理器的決斷，此后網(wǎng)絡(luò)恢復(fù)時子節(jié)點的狀態(tài)是未決狀態(tài)。此情況下，子節(jié)點會向上級節(jié)點發(fā)送查詢請求，查詢上級節(jié)點的決斷，如果上級節(jié)點也不能給出決斷，則會一直向上查找直至根節(jié)點。根事務(wù)管理器總是能給出最終決斷(在超時情況下可以強(qiáng)制作出回滾的決斷)。這樣節(jié)點就能獲取到在第二階段需要執(zhí)行的操作(提交或回滾)并執(zhí)行。

當(dāng)?shù)诙A段結(jié)束時，根事務(wù)管理器控制的作用域內(nèi)一系列操作就實現(xiàn)了一致性，即要么全部提交要么全部回滾，且寫入的數(shù)據(jù)不會丟失。

文件服務(wù)支持的操作包括上傳文件和刪除文件兩種。下面分別給出利用統(tǒng)一文檔管理事務(wù)模型對這兩種操作的處理流程，以實現(xiàn)與數(shù)據(jù)庫服務(wù)的一致性。

2.2 文件上傳事務(wù)處理流程

在統(tǒng)一文檔管理事務(wù)模型機(jī)制下上傳文件流程如圖3所示?？蛻舳碎_始上傳后，開啟事務(wù)A，由事務(wù)管理器統(tǒng)一控制數(shù)據(jù)庫服務(wù)和文件服務(wù)。數(shù)據(jù)庫服務(wù)負(fù)責(zé)寫入文件的狀態(tài)，文件服務(wù)負(fù)責(zé)上傳臨時文件。如果事務(wù)A正常提交，則開啟事務(wù)B——利用數(shù)據(jù)庫服務(wù)更新文件狀態(tài)，并利用文件服務(wù)重命名文件，作為正式文件名；否則事務(wù)A回滾，開啟事務(wù)C——數(shù)據(jù)庫服務(wù)更新文件狀態(tài)，同時文件服務(wù)刪除臨時文件。事務(wù)A、事務(wù)B、事務(wù)C 3個事務(wù)由統(tǒng)一的事務(wù)管理器管理。

圖3 文件上傳操作事務(wù)處理流程

2.3 文件刪除事務(wù)處理流程

統(tǒng)一文檔管理事務(wù)模型機(jī)制下刪除文件流程如圖4所示。刪除文件請求發(fā)出后，系統(tǒng)并不是直接調(diào)用文件服務(wù)執(zhí)行刪除操作，而是先建立一個事務(wù)A，該事務(wù)中的操作為使用數(shù)據(jù)庫服務(wù)更新文件狀態(tài)，然后事務(wù)A提交且操作無異常后，再執(zhí)行統(tǒng)一的事務(wù)B——數(shù)據(jù)庫服務(wù)更新文件狀態(tài)和文件服務(wù)中的刪除文件操作。如果事務(wù)A執(zhí)行失敗，則事務(wù)回滾，執(zhí)行事務(wù)C——通過更新文件狀態(tài)，將文件狀態(tài)恢復(fù)到事務(wù)A提交前。與文件上傳相同，事務(wù)A、事務(wù)B和事務(wù)C由統(tǒng)一的事務(wù)管理器管理。

圖4 文件刪除操作事務(wù)處理流程

3 模型驗證

采用.NET平臺對模型進(jìn)行實驗驗證。利用C#語言根據(jù)該模型構(gòu)建一個原型系統(tǒng)，構(gòu)造文件服務(wù)和數(shù)據(jù)服務(wù)，在客戶端提交上傳文件和刪除文件請求，觀察服務(wù)端的文件狀態(tài)和文檔對象狀態(tài)是否一致。實驗平臺的配置為：Windows 10 64位操作系統(tǒng)，Oracle 11g 64位數(shù)據(jù)庫，數(shù)據(jù)庫IP地址為192.168.60.178，文件服務(wù)地址為http://192.168.60.178:7011/FileService.svc，其對應(yīng)的服務(wù)端目錄為 \192.168.60.178結(jié)構(gòu)化oracleFileHostfileFileDirectory。

實驗顯示，用戶在客戶端上傳文件后，系統(tǒng)通過數(shù)據(jù)服務(wù)將文檔對象狀態(tài)更新，文檔對象的文件列表中增加了一條文件記錄，同時文件服務(wù)將該文件從客戶端上傳到服務(wù)端指定目錄，如圖5所示。用戶在客戶端刪除文件后，客戶端無法查看該文件記錄(數(shù)據(jù)服務(wù)已經(jīng)將該記錄刪除)，而該文件記錄存儲在服務(wù)端對應(yīng)的文件實體也已經(jīng)刪除，如圖6所示。

實驗驗證了該模型能夠?qū)崿F(xiàn)數(shù)據(jù)服務(wù)和文件服務(wù)的一致性，達(dá)到了預(yù)期的目標(biāo)。

4 結(jié)束語

本文分析了文檔管理中的不一致性問題，結(jié)合文件操作的特點，提出了一種分布式系統(tǒng)中的文檔管理統(tǒng)一事務(wù)處理模型。實踐證明，該模型能夠較好地解決文檔管理的一致性問題。該模型為保證事務(wù)一致性會犧牲部分執(zhí)行效率，后續(xù)會探索該模型在效率上的優(yōu)化空間。

圖5 上傳文件后的文檔對象文件列表和服務(wù)端目錄

圖6 刪除文件后的文檔對象文件列表和服務(wù)端目錄