因商務(wù)上的需要，在工作中接觸到網(wǎng)上文檔，在線Excel。但調(diào)查階段發(fā)現(xiàn)國內(nèi)相關(guān)文章較少，因此結(jié)合工作實踐和自己的一些思考，撰寫幾篇文章剖析了網(wǎng)上文檔和在線Excel實現(xiàn)的一些技術(shù)方案。為避免涉及公司隱私，本文中某些數(shù)據(jù)結(jié)構(gòu)的設(shè)計和非關(guān)鍵性場景都相當簡單。本文從需求分析、方案設(shè)計、技術(shù)選型等方面介紹了如何實現(xiàn)多人協(xié)同在線文檔。接下來，小編就將詳細介紹多人實時協(xié)作的文檔怎么做的相關(guān)內(nèi)容，一起來看看吧。

語雀空間

3.6

40條點評

咨詢產(chǎn)品

免費試用

解決用戶選型困難的好軟件，有各維度的信息

客戶案例

暫無

合作品牌

15

多人實時協(xié)作的文檔怎么做

1.多人實時協(xié)作的文檔怎么做

    需求分析

    參考了領(lǐng)域驅(qū)動模式下的需求分析思想。要求有兩個實體：人和文件。人類主要屬性是：用戶ID，用戶名。文件主要屬性是：文件ID、文件內(nèi)容、創(chuàng)建者、創(chuàng)建時間。人員與文件之間的關(guān)系很簡單：一個人可以有多個文件，一個文件只屬于某個人，并且屬于一對多關(guān)系。

    由于文件內(nèi)容無法隨意讀取和修改，因此還需要進行權(quán)限管理，權(quán)限是一個值對象。許可值是：閱讀，編輯。人們可以有閱讀或編輯文檔的權(quán)限。

    此外，最重要的問題之一是合作。協(xié)同就是多個個體，同時處理一個文檔。合作過程中需要將多個人編輯的內(nèi)容，經(jīng)合并后轉(zhuǎn)換成最終保存的文檔內(nèi)容。在協(xié)作過程中，需要讓文檔編輯者看到當前協(xié)同工作的對象和實時編輯的內(nèi)容。

    要實現(xiàn)上述功能，將系統(tǒng)劃分為五個主要模塊：人員管理、文件管理、權(quán)限管理、協(xié)作、前臺文件編輯。

    前置發(fā)送文檔名，文檔內(nèi)容交給服務(wù)方。

    服務(wù)臺產(chǎn)生一個惟一的文檔ID，從Token中獲得用戶ID，獲得服務(wù)器時間，然后將這些數(shù)據(jù)一起存入數(shù)據(jù)庫。

    服務(wù)方將文檔ID返回到前端。

    修改文檔

    此處修改意味著對文檔內(nèi)容的修改。在用戶編輯過程中，為了及時地保存用戶編輯的內(nèi)容，需要實時地將數(shù)據(jù)傳送到服務(wù)端。若每一次都將文檔內(nèi)容全部發(fā)送到服務(wù)端，盡管服務(wù)端的處理邏輯比較簡單，但每一次請求都存在大量冗余數(shù)據(jù)，浪費了大量的帶寬。因此，我們最好只將更改的內(nèi)容發(fā)送到服務(wù)端，讓服務(wù)端根據(jù)當前文檔內(nèi)容和更改的內(nèi)容合并產(chǎn)生最新的文檔內(nèi)容。

    怎樣傳遞更改過的內(nèi)容？將用戶對文件內(nèi)容的操作分為三種類型：添加，修改，刪除。新增加是為文檔添加內(nèi)容，修改是修改文檔中某一部分內(nèi)容，刪除即是刪除文檔中某一部分內(nèi)容。

    服務(wù)者從數(shù)據(jù)庫中提取文檔內(nèi)容，然后根據(jù)用戶行為進行合并操作，最后將其存入數(shù)據(jù)庫。

    當編輯一篇文章時，經(jīng)常需要傳送大量的數(shù)據(jù)。Json的數(shù)據(jù)格式雖然可以很好地表達語意，但每次傳送都要發(fā)送大量字節(jié)，浪費帶寬；同時，Json的串行化、反序列化過程效率較低。而Google的Protobuf協(xié)議則是基于二進制的傳輸協(xié)議，在內(nèi)容大小和解析速度方面均優(yōu)于Json。

    在多個人同時修改一個文檔時，可以采用多種方法處理內(nèi)容沖突：

    文件鎖定：當某人修改了一個文檔，對整個文檔加寫鎖定，其他人只能看到不可編輯。盡管實現(xiàn)很簡單，但是協(xié)作的體驗尤其糟糕。

    diff+patch的合并算法：diff+patch是文檔內(nèi)容比較和合并的常用算法，Linux本身提供對diff和patch命令的比較和合并功能。git還使用diff+patch方法合并文件，在不能解決沖突的情況下，將沖突拋給用戶手工合并。

    OT算法：與diff+patch相比，OT算法常常能得到更好的合并效果。但是OT算法的實現(xiàn)也比較復(fù)雜。當前Google文件，騰訊文件，石墨文件等均采用OT算法。在后面的文章中，我們將分別討論diff+patch和OT算法。

    協(xié)作通知

    要想更好地合作，文檔編輯人員需要同時查看文檔編輯人員，還要查看其他人修改過的內(nèi)容，以減少沖突，并達成合作。

    每個人打開文檔編輯頁面的時間是不同步的，為了讓大家看到彼此，又看到對方修改過的內(nèi)容，需要服務(wù)端主動為客戶端推送消息。這種情況下，較適合采用長鏈路的方案。

    前面還提到，經(jīng)常修改文檔時，數(shù)據(jù)的發(fā)送頻率會很高，如果是HTTP請求導(dǎo)致每次請求都帶有頭信息，建立連接等開銷，因此修改文檔內(nèi)容的數(shù)據(jù)上報也可以使用長鏈接。與此同時，服務(wù)端維護一個協(xié)作列表，以保存正在編輯的文件和文檔的在線用戶，類似于一個聊天室。

    文件修訂程序加入。

    當前端打開文檔時，將請求發(fā)送到服務(wù)端，服務(wù)端檢查協(xié)作列表中是否有當前文檔。如有，請將當前用戶加入到該文檔修改者列表中；如果未將當前文檔添加到協(xié)作列表中，并將當前用戶ID寫入。服務(wù)者將一個長鏈接發(fā)送到文檔列表中的所有其他用戶推送消息，告訴每個人都加入了合作。在不需要討論的情況下，文檔修改者退出邏輯和加入基本相同。以上就是多人實時協(xié)作的文檔怎么做的相關(guān)內(nèi)容，感謝您的閱讀。