今天小編給大家?guī)��?lái)了2018基于web粒度可配的編輯鎖設(shè)計(jì)，有需要的小伙伴一起來(lái)參考一下吧，希望能給大家?guī)��?lái)幫助！

提出了多人同時(shí)編輯同一web頁(yè)面會(huì)引起版本沖突，抽象出問題的模型，針對(duì)問題設(shè)計(jì)了一種普通編輯鎖，借助Ajax技術(shù)，有效地解決了多人同時(shí)編輯同一web頁(yè)面版本沖突問題，同時(shí)也避免的傳統(tǒng)編輯鎖長(zhǎng)時(shí)間鎖定被編輯頁(yè)面的弊端。進(jìn)一步提出粒度可配的編輯鎖，除能有效解決普通編輯鎖能解決的問題外，還可以通過(guò)配置細(xì)粒度來(lái)鎖定更少的資源，使沒必要被鎖的資源處于可被編輯狀態(tài)，提高系統(tǒng)被編輯的效率和縮短了其他用戶的等待時(shí)間。

隨著大規(guī)模協(xié)作時(shí)代的到來(lái)，發(fā)動(dòng)社區(qū)內(nèi)成員共同編輯協(xié)作，集眾人之力，發(fā)揮每個(gè)人的特長(zhǎng)，高質(zhì)量地完成某項(xiàng)任務(wù)是一件非常有意義的事情�；�于“多人協(xié)作”的主要工具為wiki[1]，比較有代表性的有維基百科[2]、TraceWiki、HdWiki等[3]，這些工具允許多人編輯同一詞條，每編輯一次生成一個(gè)版本。近幾年來(lái)，基于web多人協(xié)作平臺(tái)的迅速發(fā)展，相關(guān)研究非常多，主要研究焦點(diǎn)集中在一些宏觀方面：比如在某方面的應(yīng)用[4]，組織模型[5]等。大多忽視了微觀小問題的研究，比如：多人同時(shí)編輯同一頁(yè)面時(shí)，發(fā)生沖突了怎么辦？本文通過(guò)抽象出多人同時(shí)編輯同一web頁(yè)面存在沖突問題的模型，設(shè)計(jì)出數(shù)據(jù)庫(kù)表，借助ajax技術(shù)，解決這個(gè)問題。

1 普通編輯鎖的設(shè)計(jì)

1.1 問題抽象

存在多人同時(shí)協(xié)作時(shí)的場(chǎng)景：某wiki網(wǎng)站，用戶A在編輯詞條A，用戶B也在編輯詞條A，此時(shí)，后提交的將覆蓋前面提交的熱藎造成沖突。如果詞條很長(zhǎng)，網(wǎng)站對(duì)詞條進(jìn)行了處理，將其分段，用戶A編輯詞條A的第一段，用戶B同時(shí)編輯詞條A的第二段，此時(shí)則不會(huì)造成沖突。

根據(jù)上述場(chǎng)景，將問題進(jìn)行抽象，對(duì)于協(xié)作者來(lái)講，不管是機(jī)構(gòu)、客戶端、網(wǎng)站用戶等統(tǒng)統(tǒng)定義為用戶user，對(duì)于被編輯的對(duì)象不管是文章還是頁(yè)面上的某個(gè)模塊，只要是可以被單獨(dú)編輯的對(duì)象，統(tǒng)統(tǒng)定義為資源resource，問題就抽象為user通過(guò)對(duì)resource加鎖獨(dú)享的問題。

1.2 數(shù)據(jù)庫(kù)設(shè)計(jì)

數(shù)據(jù)庫(kù)被簡(jiǎn)化成三張表：user{userId，userName}；resource{resourceId， resourceName ，content}；lock{lockId，userId，resourceId（unique），startTime，state，heartBeatTime}，User表和resource表在一般系統(tǒng)中已經(jīng)存在，只需添加lock表即可。其簡(jiǎn)單的ER圖如圖1所示。

每一個(gè)可被編輯的資源在lock表中最多對(duì)應(yīng)一條記錄，這個(gè)可以利用數(shù)據(jù)庫(kù)的唯一索引，將lock表中的resourceId設(shè)置為唯一索引來(lái)實(shí)現(xiàn)。

1.3 編輯鎖工作流程設(shè)計(jì)

在配置文件中設(shè)置兩個(gè)可配置項(xiàng)：一是超時(shí)時(shí)間timeout一是心跳頻率heartbeat，通過(guò)timeout來(lái)解決資源被惡意或無(wú)意長(zhǎng)期鎖定的問題，通過(guò)heartbeat來(lái)確定ajax（web頁(yè)面和服務(wù)器之間的異步通信[6]，可以在頁(yè)面無(wú)刷新的情況下完成數(shù)據(jù)在客戶端和服務(wù)器之間的交互）向服務(wù)器推送最新編輯時(shí)間的頻率。用戶請(qǐng)求對(duì)某一資源編輯及編輯中和編輯結(jié)束，編輯鎖的工作流程如圖2所示。

其中“insert記錄”是指往lock表中新添加一條記錄，userId為申請(qǐng)編輯的用戶id，resourceId為被編輯的資源的id，startTime和heartBeatTime均為系統(tǒng)當(dāng)前時(shí)間，state為1，表示此鎖可用。

“update記錄”是指更新lock表中的此資源對(duì)應(yīng)鎖記錄，主要是userId為此次申請(qǐng)鎖定的用戶id，startTime和heartBeatTime更新為系統(tǒng)當(dāng)前時(shí)間，state更新為1，表示此鎖可用。

判斷l(xiāng)ock表中該資源“記錄有效”的依據(jù)為：1）state狀態(tài)為0視為無(wú)效；2）state狀態(tài)為1，比較當(dāng)前時(shí)間與heartBeatTime之間的差值，如果該值大于heartbeat，視為無(wú)效；3）state狀態(tài)為1，比較當(dāng)前時(shí)間與heartBeatTime之間的差值，如果該值小于heartbeat，但startTime與當(dāng)前時(shí)間之間的差值大于timeout，視為無(wú)效；4）state狀態(tài)為1，比較當(dāng)前時(shí)間與heartBeatTime之間的差值，如果該值小于heartbeat，但startTime與當(dāng)前時(shí)間之間的差值小于timeout，視為有效。

2 粒度可配編輯鎖的設(shè)計(jì)

如果resource的粒度被劃分越大，資源越安全，但資源被鎖定的概率越大，編輯效率越低，如何鎖定小粒度的資源，讓更多用戶可編輯自己需要編輯的資源是本節(jié)要解決的問題。為了實(shí)現(xiàn)靈活配置是否對(duì)最小粒度資源實(shí)施鎖定，在配置文件中添加配置項(xiàng)isMinimum和HTMLtags，當(dāng)isMinimum值為1時(shí)表示開啟對(duì)最小粒度資源實(shí)施鎖定。HTMLtags內(nèi)容為html切分標(biāo)簽，以分號(hào)隔開，比如“p；pre”。

2.1 實(shí)現(xiàn)技術(shù)及流程

技術(shù)上采用開源的html解析工具，該工具使用純java編寫，能夠解析html文件。

當(dāng)isMinimum=1時(shí)，頁(yè)面的html內(nèi)容中以

或者修飾的段落都是可單獨(dú)編輯的，也是最小粒度資源。當(dāng)用戶請(qǐng)求編輯某段（最小粒度資源）時(shí)，其流程是與1.3節(jié)流程類似，判斷文章（非最小粒度資源）被鎖，流程不變。文章未被鎖，繼續(xù)判斷段落是否被鎖，流程類似于文章，只是resourceId由之前的資源id編程了原資源id+小粒度編號(hào)，在此不再重復(fù)敘述。

當(dāng)用戶請(qǐng)求編輯某篇文章時(shí)（非最小粒度資源）流程在圖2所示的流程圖中判斷過(guò)記錄有效為“N”時(shí)，要增加判斷段落是否被鎖定，如果段落沒有被鎖定，其后流程不變，如果段落被鎖，仍然可以給文章加鎖，進(jìn)入編輯頁(yè)后，被鎖定的段落“置灰”，顯示不可被編輯。 3 測(cè)試結(jié)果及分析

將設(shè)計(jì)的編輯鎖進(jìn)行簡(jiǎn)單的實(shí)現(xiàn)，以判斷這種編輯鎖是否能達(dá)到預(yù)期效果。準(zhǔn)備兩臺(tái)計(jì)算機(jī)，一臺(tái)計(jì)算機(jī)當(dāng)服務(wù)器：1）安裝常見的多人協(xié)作工具如開源的hdwiki；2）創(chuàng)建lock表；3）將編輯鎖的實(shí)現(xiàn)進(jìn)行封裝，以插件的形式部署到hdwiki當(dāng)中；4）在條目編輯頁(yè)面調(diào)用編輯鎖；5）配置文件配置heartbeat=120000（兩分鐘），timeout=3600000（一小時(shí)），isMinimum=1（開啟最小粒度資源編輯鎖），HTMLtags設(shè)置為“p；pre”。一臺(tái)機(jī)器上安裝虛擬機(jī)，模擬兩個(gè)用戶同時(shí)使用系統(tǒng)。

設(shè)計(jì)了幾個(gè)測(cè)試用例，測(cè)試用例一：用戶A編輯條目“北京”，且保存條目“北京”。用例二：用戶A編輯條目“北京”幾乎同時(shí)，用戶B請(qǐng)求編輯“北京”。用例三：用戶A編輯條目“北京”很短時(shí)間，比如5分鐘，此時(shí)，用戶B請(qǐng)求編輯“北京”。用例四：用戶A編輯條目“北京”很短時(shí)間，比如5分鐘，關(guān)掉瀏覽器離開電腦，用戶B在兩分鐘內(nèi)請(qǐng)求編輯詞條“北京”。用例五，用戶A編輯條目“北京”很短時(shí)間，比如5分鐘，關(guān)掉瀏覽器離開電腦，用戶B在5分鐘內(nèi)請(qǐng)求編輯詞條“北京”。用例六，用戶A編輯條目很久，比如超過(guò)1小時(shí)。用例7，用戶A編輯條目“北京”第二段，用戶B請(qǐng)求編輯條目“北京”。用例8，用戶A編輯條目“北京”第二段，用戶B請(qǐng)求編輯條目“北京”第二段。用例9，用戶A編輯條目“北京”第二段，用戶B請(qǐng)求編輯條目“北京”第三段。測(cè)試結(jié)果如表1所示。

測(cè)試用例覆蓋了編輯鎖的所有情況，且對(duì)編輯鎖加入之前的正常功能也進(jìn)行了覆蓋，從測(cè)試結(jié)果來(lái)看，編輯鎖可以對(duì)資源進(jìn)行有效的保護(hù)，對(duì)原系統(tǒng)功能不造成任何不利影響，達(dá)到了預(yù)先設(shè)計(jì)的要求。

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

本文分析了多人協(xié)作過(guò)程中，多人同時(shí)對(duì)同一資源進(jìn)行操作時(shí)可能產(chǎn)生沖突的問題進(jìn)行了抽象，設(shè)計(jì)出一種編輯鎖，有效的解決了這個(gè)問題，該編輯鎖還可以靈活的配置超時(shí)時(shí)間和心跳時(shí)間來(lái)解決應(yīng)系統(tǒng)可能存在的負(fù)載壓力和資源被長(zhǎng)期鎖定的問題。通過(guò)流程的改進(jìn)，實(shí)現(xiàn)了對(duì)更小粒度資源鎖定的需求，且靈活可配。

來(lái)源：網(wǎng)絡(luò)整理 免責(zé)聲明：本文僅限學(xué)習(xí)分享，如產(chǎn)生版權(quán)問題，請(qǐng)聯(lián)系我們及時(shí)刪除。

《2018基于web粒度可配的編輯鎖設(shè)計(jì)論文》由互聯(lián)網(wǎng)用戶整理提供,轉(zhuǎn)載分享請(qǐng)保留原作者信息,謝謝!
鏈接地址：http://www.taixiivf.com/gongwen/181482.html

• 上一篇：精選《共產(chǎn)黨宣言》讀后感10篇
• 下一篇：我的老師我的母校征文20篇