今天小編給大家?guī)�來�?018基于web粒度可配的編輯鎖設計，有需要的小伙伴一起來參考一下吧，希望能給大家?guī)�來幫助�?/p>

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

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

1 普通編輯鎖的設計

1.1 問題抽象

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

根據上述場景，將問題進行抽象，對于協(xié)作者來講，不管是機構、客戶端、網站用戶等統(tǒng)統(tǒng)定義為用戶user，對于被編輯的對象不管是文章還是頁面上的某個模塊，只要是可以被單獨編輯的對象，統(tǒng)統(tǒng)定義為資源resource，問題就抽象為user通過對resource加鎖獨享的問題。

1.2 數(shù)據庫設計

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

每一個可被編輯的資源在lock表中最多對應一條記錄，這個可以利用數(shù)據庫的唯一索引，將lock表中的resourceId設置為唯一索引來實現(xiàn)。

1.3 編輯鎖工作流程設計

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

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

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

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

2 粒度可配編輯鎖的設計

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

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

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

當isMinimum=1時，頁面的html內容中以

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

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

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

設計了幾個測試用例，測試用例一：用戶A編輯條目“北京”，且保存條目“北京”。用例二：用戶A編輯條目“北京”幾乎同時，用戶B請求編輯“北京”。用例三：用戶A編輯條目“北京”很短時間，比如5分鐘，此時，用戶B請求編輯“北京”。用例四：用戶A編輯條目“北京”很短時間，比如5分鐘，關掉瀏覽器離開電腦，用戶B在兩分鐘內請求編輯詞條“北京”。用例五，用戶A編輯條目“北京”很短時間，比如5分鐘，關掉瀏覽器離開電腦，用戶B在5分鐘內請求編輯詞條“北京”。用例六，用戶A編輯條目很久，比如超過1小時。用例7，用戶A編輯條目“北京”第二段，用戶B請求編輯條目“北京”。用例8，用戶A編輯條目“北京”第二段，用戶B請求編輯條目“北京”第二段。用例9，用戶A編輯條目“北京”第二段，用戶B請求編輯條目“北京”第三段。測試結果如表1所示。

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

4 結束語

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

來源：網絡整理 免責聲明：本文僅限學習分享，如產生版權問題，請聯(lián)系我們及時刪除。

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

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