由于業(yè)務(wù)需要，在工作中接觸到了在線文檔、在線Excel。但是在調(diào)研階段發(fā)現(xiàn)國內(nèi)相關(guān)文章比較匱乏，所以結(jié)合工作實踐和自己的一些思考，寫幾篇文章剖析實現(xiàn)在線文檔和在線Excel的一些技術(shù)方案。為了避免涉及到公司隱私，所以文章中一些數(shù)據(jù)結(jié)構(gòu)的設(shè)計和非關(guān)鍵場景都寫的比較簡略。我們主要從需求分析、方案設(shè)計、技術(shù)選型等幾個方面介紹如何實現(xiàn)多人協(xié)作的在線文檔。

需求分析

我們借鑒領(lǐng)域驅(qū)動模型的思路進行需求分析。需求中包含「人」和「文檔」兩個實體。「人」的主要屬性有：用戶ID、用戶名。「文檔」的主要屬性有：文檔ID、文檔內(nèi)容、創(chuàng)建者、創(chuàng)建時間。人和文檔的關(guān)系非常簡單：一個人可以有多個文檔，一個文檔只歸屬某一個人，屬于一對多的關(guān)系。

因為文檔內(nèi)容不能被隨便閱讀和修改，所以還要有權(quán)限管理，「權(quán)限」是一種值對象。權(quán)限的值有：閱讀、編輯。人對文檔可以有閱讀權(quán)限或編輯權(quán)限。

還有一個最關(guān)鍵的問題就是「協(xié)作」。協(xié)作是多個「人」，對一篇文檔同時操作。協(xié)作的過程中需要把多個人編輯的內(nèi)容，經(jīng)過合并轉(zhuǎn)換為最終保存的文檔內(nèi)容。協(xié)作的過程中需要讓文檔編輯人員看到當(dāng)前「一起協(xié)作的對象」和協(xié)作對象「實時編輯的內(nèi)容」。

為了實現(xiàn)以上功能我們把系統(tǒng)拆分成五大模塊：人員管理、文檔管理、權(quán)限管理、協(xié)作和前端文檔編輯器。

方案設(shè)計

人員管理

因為人員管理不是本文的重點，所以我們只做一個簡要的設(shè)計，主要是為了輔助說明后面的設(shè)計。

表結(jié)構(gòu)主要字段有：

下面介紹下該模塊的主要邏輯。

用戶注冊

1. 前端把用戶填寫的用戶名、密碼、手機號等信息加密后發(fā)送給服務(wù)端。
2. 服務(wù)端拿到數(shù)據(jù)，再和生成的唯一用戶ID一起，存入表中。

用戶登錄

1. 前端要求用戶輸入用戶名+密碼并發(fā)送給服務(wù)端，服務(wù)端校驗用戶名和密碼的正確性。
2. 校驗通過后，根據(jù)「用戶名+密碼+密鑰+時間戳」生成有時效性的Token，返回給客戶端。
3. 登錄之后前端所有請求都帶著Token信息。服務(wù)端根據(jù)Token獲取當(dāng)前登錄用戶信息并判斷請求是否合法。

文檔管理

文檔的表結(jié)構(gòu)設(shè)計：

下面介紹下該模塊的主要邏輯。

創(chuàng)建文檔

1. 前端發(fā)送文檔名稱、文檔內(nèi)容給服務(wù)端
2. 服務(wù)端生成唯一的文檔ID，從Token中獲取到用戶ID，獲取服務(wù)器時間然后把數(shù)據(jù)一起存入數(shù)據(jù)庫中
3. 服務(wù)端返回文檔ID給前端

修改文檔

這里的修改是指修改文檔的內(nèi)容。我們?yōu)榱思皶r保存用戶編輯的內(nèi)容，需要在用戶編輯過程中實時把數(shù)據(jù)傳遞給服務(wù)端。如果每次都發(fā)送全部文檔內(nèi)容給服務(wù)端，雖然服務(wù)端的處理邏輯會比較簡單，但是每次請求都有很多冗余數(shù)據(jù)，浪費大量的帶寬。所以我們最好只發(fā)送變化的內(nèi)容給服務(wù)端，讓服務(wù)端根據(jù)當(dāng)前文檔內(nèi)容和變化內(nèi)容合并生成最新的文檔內(nèi)容。

如何發(fā)送變化的內(nèi)容呢？我們可以把用戶對文檔內(nèi)容的操作分成三類：「新增、修改、刪除」。新增就是給文檔添加內(nèi)容，修改就是修改文檔的某一段內(nèi)容，刪除就是刪除了文檔的某一段內(nèi)容。對這三類操作我們可以使用Json形式來表示：

{  
  op:"", // 操作 add：新增，update：修改， delete：刪除     
  start:"", // 開始位置下標     
  end: "", // 結(jié)束位置下標     
  text:"", // 修改內(nèi)容 
} 

這樣修改文檔的流程就是

1. 前端生成修改數(shù)據(jù)發(fā)送給服務(wù)端
2. 服務(wù)端從數(shù)據(jù)庫中獲取文檔內(nèi)容，然后根據(jù)用戶的行為合并操作，最后保存到數(shù)據(jù)庫中。

用戶在編輯一篇文章時，往往需要很多次數(shù)據(jù)傳輸。Json的數(shù)據(jù)格式雖然能很好的表達語意，但是每次傳輸也需要發(fā)送較多的字節(jié)，浪費帶寬；而且Json的序列化和反序列化過程也相對低效。我們可以采用Google的Protobuf協(xié)議來代替，它是基于二進制的傳輸協(xié)議，在傳輸內(nèi)容大小和解析速度上都強于Json。

message Doc {     
  enum Op{         
    add:0;         
    update:1;         
    delete:2;     
  }     
  required Op op = 0;     
  required int32 start = 1;        
  required int32 end = 5;     
  string text = "修改內(nèi)容"     
} 

這里協(xié)議比較簡單，自己按照規(guī)則拼接字符串也是可以的?？紤]到后續(xù)功能的可擴展性，還是建議采用Protobuf協(xié)議。

修改文檔的流程還有順序問題，我們假設(shè)用戶的操作是這樣的:

1. 用戶先刪除了5個字“12345”
2. 添加了5個字“一二三四五”
3. 又修改了其中的前兩個字是“你好”

正常順序下最后的結(jié)果是：「你好三四五」。但是如果服務(wù)端的執(zhí)行順序變成了3、1、2，那最后的結(jié)果變成了：「一二三四五」。這顯然是不符合預(yù)期的。所以我們要保證服務(wù)端順序處理前端發(fā)過來的請求。

保證順序執(zhí)行有幾個方案：

1. 前端請求由異步變成同步
2. 前端每次請求都生成連續(xù)遞增的ID，服務(wù)端判斷如果遞增ID不連續(xù)了，就短暫的等待
3. 把對同一個文檔的操作代理到同一個服務(wù)器，服務(wù)端單進程接收請求，并把數(shù)據(jù)存入有序隊列。隊列的消費端正常消費就可以了。

方案一在請求多的時候，處理效率太低會影響用戶體驗，可以直接排除掉。方案二主要依賴客戶端生成遞增ID，是比較不錯的方案。方案三依賴單進程和有序隊列保證順序。雖然單進程在并發(fā)量高的情況下很難抗壓，但是如果根據(jù)文檔ID去做負載均衡也可以比較好的控制流量，畢竟對一個文檔的修改QPS也高不到哪去。
當(dāng)然也可以把方案二和方案三結(jié)合使用。

查看文檔

1. 前端發(fā)送要查看的文檔ID給服務(wù)端
2. 服務(wù)端根據(jù)文檔ID返回文檔內(nèi)容

刪除文檔

1. 前端發(fā)送要刪除的文檔ID給服務(wù)端
2. 服務(wù)端根據(jù)文檔ID刪除對應(yīng)文檔

權(quán)限管理

當(dāng)前需求的權(quán)限場景特別適合「ABAC」的權(quán)限模型。
用戶屬性：只要是正常登錄用戶即可
環(huán)境屬性：普通的文檔內(nèi)容
操作屬性：文檔的讀和寫
對象屬性：文檔

所以，我們存儲權(quán)限信息的表結(jié)構(gòu)主要字段有：

下面介紹下該模塊的主要邏輯。

開通權(quán)限

1. 前端發(fā)送文檔ID和權(quán)限類型（讀/寫）給服務(wù)端
2. 服務(wù)端根據(jù)文檔ID和Token中的用戶ID，在權(quán)限表中添加記錄，并返回成功

刪除權(quán)限

1. 前端發(fā)送文檔ID和權(quán)限類型（讀/寫）給服務(wù)端
2. 服務(wù)端根據(jù)文檔ID和Token中的用戶ID，在權(quán)限表中刪除記錄，并返回成功

校驗權(quán)限

我們可以實現(xiàn)一個中間鍵，當(dāng)用戶請求某文檔內(nèi)容時，判斷其是否為創(chuàng)建者。如果不是再從權(quán)限表中查詢用戶是否有權(quán)限查看或者編輯權(quán)限。修改文檔內(nèi)容時也是同樣的邏輯，就不再贅述了。

協(xié)作

合并沖突

當(dāng)多個人同時修改一個文檔時，處理內(nèi)容沖突的幾種方式：

1. 文檔加鎖：當(dāng)有人修改文檔時，對整個文檔加寫鎖，別人都只能看不可編輯。雖然實現(xiàn)簡單，不過協(xié)作的體驗會特別差。
2. diff+patch的合并算法：diff+patch是常用的文檔內(nèi)容比較和合并算法，Linux本身就提供了diff和patch命令支持文件的比較和合并。git也使用了diff+patch方法來合并文件，當(dāng)無法解決沖突時，會把沖突拋給用戶手動合并。
3. OT算法：相比diff+patch來講OT算法往往能帶來更好的合并結(jié)果。不過OT算法的實現(xiàn)也更復(fù)雜一些。目前Google文檔、騰訊文檔、石墨文檔等都是采用了OT算法。我們后面單獨寫文章來聊一聊diff+patch和OT算法。

協(xié)作通知

為了更好的協(xié)作，文檔編輯者需要看到同時編輯文檔的人，還需要看到別人修改的內(nèi)容，來減少沖突，達到協(xié)作的目的。

大家打開文檔編輯頁面的時間是不同步的，為了讓大家「互相看到」，而且互相看到對方「修改的內(nèi)容」，就需要服務(wù)端主動給客戶端推送消息。此場景下采用長鏈接的方案是比較合適的。

前文也提到過，文檔修改頻繁的時候，發(fā)送數(shù)據(jù)的頻次會很高，如果是HTTP請求會導(dǎo)致每次請求都攜帶頭信息，建立連接等開銷，所以修改文檔內(nèi)容的數(shù)據(jù)上報也可以采用長鏈接。同時，服務(wù)端維護一個「協(xié)作列表」來存放所有正在被編輯的文檔和每個文檔的在線用戶，可以類比為一個聊天室。

文檔修改者加入

1. 前端打開一個文檔時，發(fā)送請求給服務(wù)端，服務(wù)端檢查協(xié)作列表中是否有當(dāng)前文檔。
2. 如果有則把當(dāng)前用戶加入此文檔修改者列表；如果沒有就把當(dāng)前文檔加入?yún)f(xié)作列表，同時把當(dāng)前用戶ID寫入其中。
3. 服務(wù)端通過長鏈接給文檔列表中的所有其他用戶推送消息，告知大家有用戶加入?yún)f(xié)作。

文檔修改者退出邏輯和加入基本相同就不再贅述了。

「修改內(nèi)容」

1. 前端把修改數(shù)據(jù)發(fā)送給服務(wù)端
2. 服務(wù)端暫存多個用戶的操作，并根據(jù)OT算法把用戶操作合并，最后和數(shù)據(jù)庫存儲的文檔內(nèi)容合并
3. 把合并完的文檔內(nèi)容保存到數(shù)據(jù)庫中
4. 服務(wù)端根據(jù)文檔ID，讀取協(xié)作列表中的用戶，給所有用戶發(fā)送合并結(jié)果
5. 客戶端把合并結(jié)果與本地文檔內(nèi)容合并

文檔編輯器

「編輯功能」

文檔編輯器需要支持，文檔內(nèi)容編輯、文字樣式調(diào)整、插入圖片、插入鏈接等一系列功能。 實現(xiàn)內(nèi)容可編輯的方案有textarea標簽和contenteditable屬性可以選擇。但是textarea標簽對其他需求的實現(xiàn)很難支持，而且不方便控制。所以我們選用contenteditable=true來實現(xiàn)文檔內(nèi)容的編輯。

「上報功能」

文檔修改時，內(nèi)容的上報，需要文檔編輯器處理好。不能用戶每輸入一個字符就上報一次，這樣頻繁的發(fā)送數(shù)據(jù)會給服務(wù)端帶來很大壓力，也是沒有必要的。所以客戶端的上報需要做防抖處理。上報的過程中有可能會因為網(wǎng)絡(luò)閃斷等原因?qū)е律蠄笫。藭r需要重試。

服務(wù)可能因為長時間的網(wǎng)絡(luò)中斷或者服務(wù)器異常導(dǎo)致數(shù)據(jù)上報失敗。此時前端可以先把用戶修改存儲在瀏覽器本地的LocalStorage中，不過需要注意瀏覽器本地緩存通常有5M的大小限制。本地存儲除了在網(wǎng)絡(luò)異常時發(fā)揮作用，在實現(xiàn)Ctrl+Z操作時，也可以起到記錄之前操作的作用。

「長鏈接」

需要有一個單獨的模塊管理長鏈接，統(tǒng)一處理上報的接口和服務(wù)端下發(fā)的數(shù)據(jù)，做好數(shù)據(jù)的封裝和解析；并及時的反饋給用戶連接成功、數(shù)據(jù)保存成功、連接異常等信息。

「大文檔的加載」

對于大文檔的加載，我們需要做異步處理。根據(jù)滾動條滾動的位置，在服務(wù)端異步的獲取更多數(shù)據(jù)。

「其他功能」

前端編輯器的其他模塊我們可以根據(jù)其功能范圍拆分：比如控制文字大小、顏色的功能模塊；控制文字對齊方式的模塊；控制插入內(nèi)容的模塊；支持Ctrl+C、Ctrl+V、Ctrl+Z的模塊等等。拆分好之后根據(jù)功能實現(xiàn)就可以了，這里就不一一分析了。

技術(shù)選型

「存儲」

存儲方面，當(dāng)前場景使用關(guān)系型數(shù)據(jù)庫比較合適。我們可以根據(jù)文檔和用戶的數(shù)量級選擇合適的數(shù)據(jù)庫。通常千萬級別的數(shù)據(jù)量選擇MySQL就可以了，如果數(shù)據(jù)更多的話我們可以選擇TIDB或者MySQL分庫分表的方案。
當(dāng)然采用MongoDB和PG也都可以滿足需求，我們可以結(jié)合公司的DBA運維能力自行選擇。

補充一下，如果考慮文檔內(nèi)容的搜索，只選擇一種存儲結(jié)構(gòu)是不夠的。需要單獨為文檔建立索引，可以選擇使用ES集群為文檔創(chuàng)建全文索引。而且索引的創(chuàng)建和MySQL的增刪改比起來是比較耗時的操作，所以創(chuàng)建索引往往放在異步流程中。而且用戶創(chuàng)建一個文檔也很少立馬就對它搜索。

「長鏈接」

當(dāng)前常用的長鏈接方案主要有“HTTP/2 + SSE”和WebSocket兩種，WebSocket更成熟一些，優(yōu)先選擇。

「消息隊列」

建議采用RocketMQ，因為

1. RocketMQ支持同步/異步刷盤，支持同步/異步寫副本，消息的可靠性更有保障。
2. RocketMQ支持順序消息。

當(dāng)然寫入性能方面要比Kafka弱一些。但是在線文檔的場景里，消息的可靠性和順序更加重要。

架構(gòu)設(shè)計

基于上面的分析，我們設(shè)計的部署架構(gòu)圖如下

其中，接入層負責(zé)用戶的鑒權(quán)和長鏈接保持；其他各模塊負責(zé)各自的功能。文檔修改的隊列我們采用MQ發(fā)送，文檔管理模塊消費。Redis我們用來存放多人協(xié)作時的文檔和用戶對應(yīng)關(guān)系。當(dāng)然數(shù)據(jù)量不大時MQ也可以使用Redis臨時代替。

總結(jié)

以上就是我對多人協(xié)作在線文檔的分析和設(shè)計方案，其中包含了前后端交互流程、文檔的存儲和服務(wù)的部署方案。為了突出主要問題和邏輯，文中很多設(shè)計和技術(shù)點都是點到為止，給大家造成困擾的地方大家可以自行搜索下關(guān)鍵字或者留言交流。