魯 立

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

產(chǎn)品生命周期管理(PLM)系統(tǒng)針對(duì)產(chǎn)品設(shè)計(jì)、開(kāi)發(fā)、生產(chǎn)等各個(gè)環(huán)節(jié)進(jìn)行全生命周期管理，是制造業(yè)企業(yè)的重要支撐。目前，大部分制造企業(yè)已成立了信息化部門(mén)，采購(gòu)了一定數(shù)量的微型機(jī)、服務(wù)器、數(shù)據(jù)庫(kù)、網(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)的文檔管理，必須考慮其在多用戶操作場(chǎng)景下的數(shù)據(jù)一致性問(wèn)題。

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

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

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

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

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

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

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

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

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

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

常見(jiàn)的分布式事務(wù)模型包括DTP模型[11]、TCC模型、可靠消息模型和業(yè)務(wù)補(bǔ)償模型。其中，DTP模型采用2PC(兩階段提交)模式，可以保證事務(wù)的強(qiáng)一致性，且直接作用于資源層，對(duì)業(yè)務(wù)代碼沒(méi)有太多的侵入性。DTP模型具備一定的普適性，可滿足大部分場(chǎng)景的需求[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ù)處理模型為樹(shù)狀結(jié)構(gòu)，有一個(gè)根事務(wù)管理器，它負(fù)責(zé)事務(wù)的最終決斷(即提交或回滾)。該模型采用2PC模式。在第一階段，每個(gè)子事務(wù)管理器需要向上級(jí)節(jié)點(diǎn)報(bào)告它的狀態(tài)，這樣一直向上報(bào)告直到根事務(wù)管理器，由根事務(wù)管理器做出最終決斷。該樹(shù)狀結(jié)構(gòu)模型每個(gè)節(jié)點(diǎn)的決斷算法是：1)若子節(jié)點(diǎn)報(bào)告的全部狀態(tài)均為就緒，則向上級(jí)節(jié)點(diǎn)報(bào)告已就緒，可以作出提交的決斷；2)若至少有一個(gè)子節(jié)點(diǎn)報(bào)告的狀態(tài)為中止，則向上級(jí)節(jié)點(diǎn)報(bào)告，作出回滾的決斷。

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

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

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

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

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

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

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

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

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

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

3 模型驗(yàn)證

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

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

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

4 結(jié)束語(yǔ)

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

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

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