因商務上的需要,在工作中接觸到網上文檔,在線Excel。但調查階段發現國內相關文章較少,因此結合工作實踐和自己的一些思考,撰寫幾篇文章剖析了網上文檔和在線Excel實現的一些技術方案。為避免涉及公司隱私,本文中某些數據結構的設計和非關鍵性場景都相當簡單。本文從需求分析、方案設計、技術選型等方面介紹了如何實現多人協同在線文檔。接下來,小編就將詳細介紹多人實時協作的文檔怎么做的相關內容,一起來看看吧。
多人實時協作的文檔怎么做
需求分析
參考了領域驅動模式下的需求分析思想。要求有兩個實體:人和文件。人類主要屬性是:用戶ID,用戶名。文件主要屬性是:文件ID、文件內容、創建者、創建時間。人員與文件之間的關系很簡單:一個人可以有多個文件,一個文件只屬于某個人,并且屬于一對多關系。
由于文件內容無法隨意讀取和修改,因此還需要進行權限管理,權限是一個值對象。許可值是:閱讀,編輯。人們可以有閱讀或編輯文檔的權限。
此外,最重要的問題之一是合作。協同就是多個個體,同時處理一個文檔。合作過程中需要將多個人編輯的內容,經合并后轉換成最終保存的文檔內容。在協作過程中,需要讓文檔編輯者看到當前協同工作的對象和實時編輯的內容。
要實現上述功能,將系統劃分為五個主要模塊:人員管理、文件管理、權限管理、協作、前臺文件編輯。
前置發送文檔名,文檔內容交給服務方。
服務臺產生一個惟一的文檔ID,從Token中獲得用戶ID,獲得服務器時間,然后將這些數據一起存入數據庫。
服務方將文檔ID返回到前端。
修改文檔
此處修改意味著對文檔內容的修改。在用戶編輯過程中,為了及時地保存用戶編輯的內容,需要實時地將數據傳送到服務端。若每一次都將文檔內容全部發送到服務端,盡管服務端的處理邏輯比較簡單,但每一次請求都存在大量冗余數據,浪費了大量的帶寬。因此,我們最好只將更改的內容發送到服務端,讓服務端根據當前文檔內容和更改的內容合并產生最新的文檔內容。
怎樣傳遞更改過的內容?將用戶對文件內容的操作分為三種類型:添加,修改,刪除。新增加是為文檔添加內容,修改是修改文檔中某一部分內容,刪除即是刪除文檔中某一部分內容。
服務者從數據庫中提取文檔內容,然后根據用戶行為進行合并操作,最后將其存入數據庫。
當編輯一篇文章時,經常需要傳送大量的數據。Json的數據格式雖然可以很好地表達語意,但每次傳送都要發送大量字節,浪費帶寬;同時,Json的串行化、反序列化過程效率較低。而Google的Protobuf協議則是基于二進制的傳輸協議,在內容大小和解析速度方面均優于Json。
在多個人同時修改一個文檔時,可以采用多種方法處理內容沖突:
文件鎖定:當某人修改了一個文檔,對整個文檔加寫鎖定,其他人只能看到不可編輯。盡管實現很簡單,但是協作的體驗尤其糟糕。
diff+patch的合并算法:diff+patch是文檔內容比較和合并的常用算法,Linux本身提供對diff和patch命令的比較和合并功能。git還使用diff+patch方法合并文件,在不能解決沖突的情況下,將沖突拋給用戶手工合并。
OT算法:與diff+patch相比,OT算法常常能得到更好的合并效果。但是OT算法的實現也比較復雜。當前Google文件,騰訊文件,石墨文件等均采用OT算法。在后面的文章中,我們將分別討論diff+patch和OT算法。
協作通知
要想更好地合作,文檔編輯人員需要同時查看文檔編輯人員,還要查看其他人修改過的內容,以減少沖突,并達成合作。
每個人打開文檔編輯頁面的時間是不同步的,為了讓大家看到彼此,又看到對方修改過的內容,需要服務端主動為客戶端推送消息。這種情況下,較適合采用長鏈路的方案。
前面還提到,經常修改文檔時,數據的發送頻率會很高,如果是HTTP請求導致每次請求都帶有頭信息,建立連接等開銷,因此修改文檔內容的數據上報也可以使用長鏈接。與此同時,服務端維護一個協作列表,以保存正在編輯的文件和文檔的在線用戶,類似于一個聊天室。
文件修訂程序加入。
當前端打開文檔時,將請求發送到服務端,服務端檢查協作列表中是否有當前文檔。如有,請將當前用戶加入到該文檔修改者列表中;如果未將當前文檔添加到協作列表中,并將當前用戶ID寫入。服務者將一個長鏈接發送到文檔列表中的所有其他用戶推送消息,告訴每個人都加入了合作。在不需要討論的情況下,文檔修改者退出邏輯和加入基本相同。以上就是多人實時協作的文檔怎么做的相關內容,感謝您的閱讀。
[免責聲明]
文章標題: 多人實時協作的文檔要怎么做
文章內容為網站編輯整理發布,僅供學習與參考,不代表本網站贊同其觀點和對其真實性負責。如涉及作品內容、版權和其它問題,請及時溝通。發送郵件至36dianping@36kr.com,我們會在3個工作日內處理。