1 協(xié)作文檔編輯服務(wù)的設(shè)計(jì)方式

1.1 C/S架構(gòu)的集中式設(shè)施

為所有用戶提供文檔編輯服務(wù)。所有用戶都連接到一個(gè)中心服務(wù)器，該服務(wù)器負(fù)責(zé)存儲和處理文檔數(shù)據(jù)，用戶通過連接到該服務(wù)器來協(xié)作編輯文檔。提供更好的安全性和可控性，但有單點(diǎn)故障問題

1.2 點(diǎn)對點(diǎn)技術(shù)設(shè)計(jì)

以便在單個(gè)文檔上協(xié)作。將文檔數(shù)據(jù)分散存儲在多個(gè)用戶設(shè)備，每個(gè)用戶都可直接編輯文檔并將更改同步到其他用戶設(shè)備。提供更好靈活性和可擴(kuò)展性，但可能會有數(shù)據(jù)同步不及時(shí)或數(shù)據(jù)沖突問題

大多數(shù)商業(yè)方案側(cè)重C/S架構(gòu)，以實(shí)現(xiàn)更精細(xì)控制。因此，本文也使用C/S架構(gòu)設(shè)計(jì)服務(wù)。

2 需求

2.1 功能性

① 文檔協(xié)作

多用戶能同時(shí)編輯文檔。大量用戶應(yīng)能查看文檔。

② 沖突解決

系統(tǒng)應(yīng)將一個(gè)用戶做的編輯推送給所有其他協(xié)作者。若他們正在編輯文檔同一部分，系統(tǒng)還應(yīng)解析用戶之間的沖突。

③ 建議

• 在文檔中完成常用單詞、短語和關(guān)鍵詞的建議
• 修復(fù)語法錯(cuò)誤的建議

④ 查看計(jì)數(shù)

文檔的編輯應(yīng)能看到該文檔的查看計(jì)數(shù)。

⑤ 歷史

用戶能查看文檔的協(xié)作歷史。

2.2 非功能性

① 延遲

不同的用戶可連接起來協(xié)作同一份文檔。為來自不同區(qū)域的用戶維護(hù)低延遲訪問。

② 一致性

系統(tǒng)應(yīng)能解析用戶并發(fā)編輯文檔時(shí)之間的沖突，從而實(shí)現(xiàn)文檔的一致視圖。不同區(qū)域的用戶應(yīng)看到文檔的更新狀態(tài)。

對連接到同一區(qū)域和不同區(qū)域的用戶來說，保持一致性都很重要。

③ 可用性

該服務(wù)應(yīng)一直可用，并展示對故障的魯棒性。

④ 可擴(kuò)展性

大量用戶應(yīng)能同時(shí)使用該服務(wù)。他們可查看相同的文檔，也可創(chuàng)建新文檔。

3 組件

3.1 數(shù)據(jù)存儲

• 關(guān)系數(shù)據(jù)庫，用于保存用戶信息和文檔相關(guān)信息以施加特權(quán)限制
• NOSQL，用于存儲用戶評論以獲得更快的訪問速度
• 時(shí)間序列，用于保存文檔的編輯歷史記錄
• Blob 存儲，用于存儲文檔中的視頻和圖像
• 緩存，分布式緩存如 Redis 和 CDN，為最終用戶提供良好的性能。使用 Redis存儲不同數(shù)據(jù)結(jié)構(gòu)，包括用戶會話、類型預(yù)期服務(wù)的功能、頻繁訪問的文檔。CDN存儲頻繁訪問的文檔和重量級對象如圖像和視頻。

3.2 處理隊(duì)列

針對每次微小字符更改使用 HTTP 調(diào)用是低效的。因此使用 WebSockets 減少開銷，并通過不同用戶實(shí)時(shí)觀察文檔的更改。

3.3 其他

會話服務(wù)器，維護(hù)用戶的會話信息。通過會話服務(wù)器管理文檔訪問權(quán)限。還要有配置、監(jiān)控、發(fā)布-訂閱和日志記錄服務(wù)來處理監(jiān)控任務(wù)，如在服務(wù)器失敗時(shí)監(jiān)控和選舉領(lǐng)導(dǎo)者，排隊(duì)用戶通知等任務(wù)及記錄調(diào)試信息。

協(xié)作文檔編輯服務(wù)的詳細(xì)設(shè)計(jì)：

圖片

4 工作流程

4.1 協(xié)作編輯和沖突解決

每個(gè)請求都會轉(zhuǎn)發(fā)到操作隊(duì)列。這是解析同一文檔的不同協(xié)作者之間沖突的地方。如果沒有沖突，則通過會話服務(wù)器將數(shù)據(jù)批量存儲在時(shí)間序列數(shù)據(jù)庫中。像視頻和圖像這樣的數(shù)據(jù)會被壓縮以優(yōu)化存儲,而字符會被立即處理。歷史:借助時(shí)間序列數(shù)據(jù)庫,可以恢復(fù)文檔的不同版本。可以使用 DIFF 操作來比較版本并標(biāo)識差異以恢復(fù)同一文檔的舊版本。

4.2 異步操作

通知、電子郵件、查看次數(shù)和評論都是可以通過像 Kafka 這樣的發(fā)布-訂閱組件排隊(duì)的異步操作。API 網(wǎng)關(guān)生成這些請求并將它們轉(zhuǎn)發(fā)到發(fā)布-訂閱模塊。

4.3 建議

建議以類型提前服務(wù)（typeahead service）的形式出現(xiàn),該服務(wù)提供通常使用的單詞和短語的自動完成功能。類型提前服務(wù)還可以從文檔中提取屬性和關(guān)鍵詞并向用戶提供建議。由于單詞數(shù)量可能很高,我們將為此目的使用 NoSQL 數(shù)據(jù)庫。此外,最常用的單詞和短語將存儲在像 Redis 這樣的緩存系統(tǒng)中。

4.4 導(dǎo)入和導(dǎo)出文檔

應(yīng)用程序服務(wù)器執(zhí)行許多重要任務(wù),包括導(dǎo)入和導(dǎo)出文檔。應(yīng)用程序服務(wù)器還將文檔從一種格式轉(zhuǎn)換為另一種格式。例如,.doc 或 .docx 文檔可以轉(zhuǎn)換為 .pdf 或反之亦然。應(yīng)用程序服務(wù)器也負(fù)責(zé)為類型預(yù)期服務(wù)提取特征。

5 詳細(xì)設(shè)計(jì)

5.1 文檔編輯器

文檔由以特定順序排列的字符組成。每個(gè)字符都有一個(gè)值和一個(gè)位置索引。字符可以是字母、數(shù)字、回車()或空格。索引表示字符在有序字符列表中的位置。

文本或文檔編輯器的作用是在文檔中的字符上執(zhí)行插入()、刪除()、編輯()等操作。下面是文檔的描繪以及編輯器將如何執(zhí)行這些操作。

文檔編輯器如何執(zhí)行各種操作

圖片

5.2 并發(fā)性

不同用戶對同一文檔的協(xié)作可能導(dǎo)致并發(fā)問題。若多個(gè)用戶編輯文檔的同一部分，可能出現(xiàn)沖突。由于用戶在本地有文檔的副本，服務(wù)器上的最終文檔狀態(tài)可能與用戶在他們端看到的不同。在服務(wù)器推送更新版本后，用戶會發(fā)現(xiàn)意外結(jié)果。

① 在同一位置索引處添加字符

兩個(gè)用戶修改同一字符可能導(dǎo)致并發(fā)問題：

圖片

② 刪除同一字符

刪除同一字符，可能導(dǎo)致意外更改：

圖片

第二個(gè)例子表明，不同用戶應(yīng)用相同的操作不會是冪等的。因此，在多個(gè)協(xié)作者同時(shí)編輯文檔同一部分時(shí)，需沖突解決。

協(xié)作編輯中并發(fā)問題的解決方案應(yīng)遵循規(guī)則：

• 交換律：應(yīng)用操作的順序不應(yīng)影響最終結(jié)果
• 冪等性：重復(fù)的相似操作只應(yīng)用一次

6 沖突解決技術(shù)

6.1 操作轉(zhuǎn)換（OT）

廣泛用于協(xié)作編輯中的沖突解決的技術(shù)，一種【無鎖】、【非阻塞】的沖突解決方法。若協(xié)作者之間的操作沖突，OT會解析沖突并將正確的匯聚狀態(tài)推給最終用戶。因此，OT為用戶提供一致性。

OT 使用位置索引方法執(zhí)行操作來解析上面討論的那些沖突。通過保持交換律、冪等性來解決上述問題。

OT示例：

圖片

基于 OT 的協(xié)作編輯器在滿足以下兩個(gè)屬性時(shí)一致：

• 因果關(guān)系保持：如果操作 a 發(fā)生在操作 b 前，那先執(zhí)行操作 a，然后執(zhí)行操作 b
• 收斂：不同客戶端上的所有文檔副本最終相同

上述屬性是 CC 一致性模型的一部分，CC 一致性模型是協(xié)作編輯中一致性維護(hù)的模型。

OT的缺點(diǎn)

對字符的每個(gè)操作都可能需要更改位置索引。這意味著操作之間存在順序依賴關(guān)系。它的開發(fā)和實(shí)現(xiàn)具有挑戰(zhàn)性。

OT是一組復(fù)雜算法，其正確實(shí)現(xiàn)在實(shí)際應(yīng)用中已被證明有挑戰(zhàn)性。Google Wave 團(tuán)隊(duì)花兩年時(shí)間實(shí)現(xiàn)OT。

6.2 無沖突復(fù)制數(shù)據(jù)類型 (CRDT)

是為了改進(jìn) OT。CRDT 具有：

• 復(fù)雜的數(shù)據(jù)結(jié)構(gòu)
• 但簡化的算法

CRDT 通過為每個(gè)字符分配兩個(gè)關(guān)鍵屬性來滿足交換律和冪等性：

• 為每個(gè)字符賦予全局唯一標(biāo)識
• 全局訂購每個(gè)字符

每個(gè)操作現(xiàn)在都有一個(gè)更新后的數(shù)據(jù)結(jié)構(gòu)：CRDT 簡化的數(shù)據(jù)結(jié)構(gòu)

圖片

SiteID 唯一標(biāo)識請求操作的用戶站點(diǎn)，帶有一個(gè)值和一個(gè) PositionalIndex。PositionalIndex值可以是分?jǐn)?shù)：

• 某些操作不會改變其他字符的 PositionalIndex
• 避免不同用戶操作之間的順序依賴性

示例描繪來自站點(diǎn) ID 123e4567-e89b-12d3 的用戶在 PositionalIndex 為 1.5 的位置插入一個(gè)值為 A 的字符。盡管添加了新字符,但使用小數(shù)索引保留了現(xiàn)有字符的位置索引。因此,避免了操作之間的順序依賴性。如下所示,在 O 和 T 之間插入()并沒有影響 T 的位置。

防止操作之間的順序依賴性：

圖片

CRDT 確保用戶之間的強(qiáng)一致性。即使一些用戶處于離線狀態(tài),當(dāng)他們重新聯(lián)機(jī)時(shí),最終用戶處的本地副本也將匯聚。

盡管眾所周知的在線編輯平臺如 Google 文檔、Etherpad 和 Firepad 使用 OT,但 CRDT 使協(xié)作文檔編輯中的并發(fā)和一致性變得容易。事實(shí)上,使用 CRDT,可以實(shí)現(xiàn)無服務(wù)器點(diǎn)對點(diǎn)協(xié)作文檔編輯服務(wù)。

6.3 注意

OT 和 CRDT 是協(xié)作編輯中沖突解決的良好解決方案，但我們使用 WebSockets 可高亮協(xié)作者的光標(biāo)。其他用戶也能預(yù)期該協(xié)作者的下一個(gè)操作的位置，并自然和自覺地避免沖突。

7 總結(jié)

7.1 一致性

操作轉(zhuǎn)換(OT)和沖突不定決議數(shù)據(jù)類型(CRDT)在文檔中實(shí)現(xiàn)沖突解決的強(qiáng)一致性。

時(shí)間序列數(shù)據(jù)庫能保留事件的順序。一旦 OT 或 CRDT 解析了任何沖突，最終結(jié)果就保存在數(shù)據(jù)庫。這有助我們在單個(gè)操作方面實(shí)現(xiàn)一致性。

在IDC內(nèi)的不同服務(wù)器之間保持文檔狀態(tài)的一致性。要在同一IDC內(nèi)同時(shí)復(fù)制更新后的文檔狀態(tài)，可使用 Gossip 協(xié)議這樣的點(diǎn)對點(diǎn)協(xié)議。這不僅提高一致性，還會提高可用性。

7.2 可用性

我們的設(shè)計(jì)通過使用副本以及使用監(jiān)控服務(wù)監(jiān)控主副本服務(wù)器來確?？捎眯浴２僮麝?duì)列和數(shù)據(jù)存儲等關(guān)鍵組件在內(nèi)部管理自己的復(fù)制。

由于使用 WebSockets，WebSocket 服務(wù)器可將用戶連接到會話維護(hù)服務(wù)器，這些服務(wù)器將確定用戶是否正在主動查看或協(xié)作文檔。

因此，保留多個(gè) WebSocket 服務(wù)器將增加設(shè)計(jì)的可用性。最后，采用緩存服務(wù)和 CDN 改進(jìn)可用性。

7.2 可擴(kuò)展性

由于使用微服務(wù)，若操作隊(duì)列的請求數(shù)量超過其容量，可輕松單獨(dú)擴(kuò)展每個(gè)組件?？墒褂枚鄠€(gè)操作隊(duì)列。此時(shí)，每個(gè)操作隊(duì)列將負(fù)責(zé)單個(gè)文檔。可將不同用戶請求的與單個(gè)文檔相關(guān)的操作轉(zhuǎn)發(fā)到特定隊(duì)列。生成的隊(duì)列數(shù)量將等于活動文檔的數(shù)量。因此可實(shí)現(xiàn)水平擴(kuò)展性。

參考：

• 編程嚴(yán)選網(wǎng)