主頁 > 軟體設計 > 想實作多人協作的“在線Excel”?真沒那么簡單

想實作多人協作的“在線Excel”?真沒那么簡單

2020-09-14 07:45:26 軟體設計

本文由葡萄城技術團隊原創并首發

轉載請注明出處:葡萄城官網,葡萄城為開發者提供專業的開發工具、解決方案和服務,賦能開發者,

 

Excel是我們辦公中常用的工具 ,它幾乎能為我們處理大部分資料,友好的互動界面、豐富的公式函式和易于上手的圖表為我們在資料統計方面提供了不小的幫助,但經過一段時期運行,就會出現下面的情況:

 

 

 

這樣多分枝的混亂狀況就會難以保證檔案的安全性及權威性,

于是聰明的小伙伴想到了一個解決方案,共享出一份Excel檔案,根據人員的職級不同,設定僅可只讀和編輯的權限,同時根據為不同人制定不同規則,例如:張某每天十點編輯,王某每天十一點編輯的方式來解決沖突的問題,這種方式很聰明,從流程上解決了多副本的問題,但不能同時編輯的問題依然沒有被解決,如果一個部門的人足夠多,這樣分時的策略可能需要花一天時間才能完成一份Excel的編輯,

所以多人協作在線檔案的需求也變得越發變得強烈,因為在日常作業中,與團隊的其他人進行檔案協作是一種再常見不過的作業方式,由于作業分工、作業進展的不同,團隊內部的資訊往往需要及時同步,然而伴隨著團隊經營規模的不斷擴大,在線協同、多人協作,以及軟體專案管理等問題將會接踵而至,成為制約企業高效發展的瓶頸,

而這些問題,通常表現為:

  1. 跨部門、地區溝通協作的不便
  2. 過度依賴檔案、檔案夾共享的形式,不能確保檔案的安全性
  3. 沒法紀錄和體現職工對文本檔案的意見和評價
  4. 檔案記錄發生變更時,無法及時通知到相關部門和員工
  5. 檔案無法在線協同編輯,缺失必要的流程管控
  6. 多人共同編輯一個檔案,無法留存修改記錄和歷史版本

 

針對上述問題,現在在市面上,已經有了很多這類多人協作的工具,例如:國外的Google Docs、Office365,及國內的騰訊檔案、石墨檔案、有道云協作等,

因為這篇文章我們的目的是想向大家從企業IT管理者的角度出發深入研究協同辦公系統的形式、基礎和難點等實作原理,所以成品軟體我們在這不做過多贅述,那我們正式開始吧,

多人協作的形式:歷史與發展

多人協作的歷史十分悠久,起源于靜態的多人協作模式,即每個人先完成自己的作業,然后再進行匯總,

多人協作的初期:靜態協作

  • 遞增式協作
    • 郵件:你來我往
    • 論壇:跟帖回復
  • 獨占式協作
    • 檔案傳遞
    • 微軟VSS
  • 合并式協作
    • SVN
    • Git
    • diff,patch,merge指令

 

常見的靜態多人協作方式

多人協作的發展期:從靜態到動態

  • 靜態協作的比喻
    • 拼接畫
    • 積木
  • 靜態協作的特點
    • 多版本
    • 塊操作
    • 有協作動作
  • 靜態協作的缺點
    • 版本碎片化
    • 缺乏時效性
    • 協作動作成本高

靜態多人協作的成本,會隨著加入人數和專案的復雜度呈幾何級數的增長,因此,對于企業來說,急需一種無協作動作、唯一版本、版本可控的無協作成本模式,即動態多人協作模式,

多人協作的蓬勃期:動態

  • 動態協作的比喻
    • 一起畫黑板
  • 動態協作的特點
    • 唯一版本
    • 原子操作
    • 無協作動作
  • 動態協作的優點
    • 版本可控
    • 實時
    • 無協作成本
  • 典型產品
    • Office Online
    • 石墨
    • OnlyOffice

多人協作的基礎:原理與架構

任何資訊,無論其是什么展現形式,如果要做到多人實時編輯與展現,只需要實作以下三步而已:

  1. 操作化
  2. 可傳輸
  3. 可還原

舉例說明多人協作的實作方式

操作化

操作化,指任何資訊都可以轉換為一組操作的集合,很容易理解,但它仍有不少值得思考的點:

  • 分割與組合
    • 如何保證:資訊的所有變化都可以分解為操作的集合?反之,操作如何覆寫出資訊的所有變化?
    • 分割的顆粒度如何決定?
      • 粗一點?
      • 細一點?
      • 如何兼顧解釋性與擴展性?
  • 絕對操作與相對操作
    • 絕對操作
      • 針孔列印機的完美世界
      • 列印機時代的編輯噩夢
    • 相對操作
      • 4K電視不是夢
      • 為什么數字電視穩定性不如模擬電視
    • 絕對操作與相對操作比喻:時間與空間的互換

可傳輸

可傳輸,就是指操作有辦法通過網路傳輸給其他終端,實作動態多人協作,需要考慮以下幾點:

  • 傳輸內容
    • 原始文本
      • 清晰
      • 冗余
    • 壓縮技術
      • 邏輯壓縮
      • 協議壓縮
      • 手動壓縮
  • 網路協議
    • Socket
      • TCP
      • UDP
    • HTTP
    • WebSocket
  • QoS(Quality of Service,服務質量)
    • 快速失敗

    • 自動回滾

    • 自動重連

    • 自動恢復

可還原

可還原,就是指接收到來自網路的操作訊息后,可以在本地完全一致地再次執行該操作,可還原包括了:

  1. 絕對操作的還原
    • 控制體積
    • 合理的提示
  2. 相對操作的還原
    • 嚴格的順序性
    • 從源頭保障順序性
    • 順序性的補救
  3. 本地操作的還原
    • 過濾收到的操作集合
    • 從源頭細化操作顆粒
    • 本地保存本地執行
  4. 無入侵的還原
    • 定義入侵
    • 排除入侵
    • 千人千面

多人協作的難點:亂序與沖突

亂序

亂序的表現形式如下圖,小明在客戶端執行了一系列操作,傳遞到服務器時發生亂序,導致小花看到了截然不同的資訊:

 

 

 

為了解決亂序問題,可以嘗試以下方法:

1. 用性能換取順序正確——基于協議

 

 

 

2. 用性能換取順序正確——基于回執

 

 

 

兩種方法的優缺點
  1. 基于協議
  • 優點
    • 可靠,歷經考驗
    • 簡單,無需開發
  • 缺點
    • 資源開銷高
    • 必須整套使用
  • 優點
    • 自主可控,按需開發
    • 資源開銷可控
  • 缺點
    • 需要自己投入開發
    • 應用層邏輯控制使得網路復雜度向外蔓延
    • 復雜度帶來維護成本
  1. 基于回執

 

基于亂序處理方法的總結

網路不是絕對可靠的,為了實作相對可靠,需要付出一定的代價,企業需要考慮的是:如何衡量所付出的代價與產出成正比,

沖突

比亂序更高級的一種表現形式,存在多向、多維度等問題,

 

 

 

如何避免錯誤的蔓延?

原則:任何一次不一致,都會導致后續的操作基于錯誤的資訊進行,從而不斷擴大錯誤,造成無法收拾的結果,因此,不一致是不能被容忍的,

解決辦法:

  1. 嚴格一致性:獨占
  2. 最終一致性:檢查與修復
  3. 非技術手段:設計與提示
嚴格的一致性

獨占就是同一時間同一范圍只能由一人操作,

  1. 范圍
    1. 整個表格,類似VSS
    2. 作業表
    3. 單元格范圍
  2. 排他性
    1. 獨占沖突時,必有一方被彈開
    2. 直到占有者解開,不然無法占用
    3. 占用前無法操作
    4. 原理和鎖基本一致
  3. 優點
    1. 可以確保嚴格一致性,不會產生多版本的錯誤累積
    2. 比起修復恢復這類彌補手段,一開始就不出錯的成本最低
    3. 邏輯清楚簡單,開發維護成本低
  4. 缺點
    1. 靜態協作的味道
    2. 獨占動作嚴重影響體驗
    3. 大幅降低協作效率
  5. 需對表格實作的 功能
    1. 鎖定作業表
    2. 鎖定單元格
最終一致性

基于唯一正確順序,察覺客戶端的錯誤,撤銷錯誤操作后重新執行正確的操作,

  1. 唯一正確
    1. 服務器到達順序
    2. 協作邊界分流
    3. P2P+選舉演算法
  2. 察覺錯誤
    1. 服務器回執id
    2. 服務器回執操作,MS
  3. 撤銷錯誤
    1. 撤銷到錯誤發生前的一步操作的結果
    2. 保存副本實作撤銷功能
    3. 利用操作版本快照
  4. 重新執行
    1. 操作佇列需保存
    2. 區分好無感知執行與顯式執行

 

針對多人協作難點的總結

如何實作Excel相關功能是需要開發人員需要花時間去研究的,另外為了滿足需求,適配多設備和平臺的兼容性也非常重要,

另外,多人協作表格的本質還具有如下本質和特點:

  •  Server – Clients 中心系統,類似數值敏感的小型網游
  • 任何這類系統都是在體驗和正確性中尋求平衡
  • 表格的數值敏感性高于網游,資料操作和存盤的挑戰更大
  • 表格的計算復雜度更高,尤其涉及復雜公式嵌套與全量統計篩選
  • Web存在天花板,所以復雜的頁游并不多見,端游較多

 

最后,假如您想了解更多如何實作多人協作平臺相關的內容,歡迎參加2019年12月18日(周三) 14點由上海佳軟CTO帶來的一場線上直播:https://live.vhall.com/483759540,相信屆時我們都會受益良多的,

 

轉載請註明出處,本文鏈接:https://www.uj5u.com/ruanti/32408.html

標籤:架構設計

上一篇:Springboot vue.js html 跨域 前后分離 shiro權限 集成代碼生成器

下一篇:Nginx環境搭建與使用

標籤雲
其他(157675) Python(38076) JavaScript(25376) Java(17977) C(15215) 區塊鏈(8255) C#(7972) AI(7469) 爪哇(7425) MySQL(7132) html(6777) 基礎類(6313) sql(6102) 熊猫(6058) PHP(5869) 数组(5741) R(5409) Linux(5327) 反应(5209) 腳本語言(PerlPython)(5129) 非技術區(4971) Android(4554) 数据框(4311) css(4259) 节点.js(4032) C語言(3288) json(3245) 列表(3129) 扑(3119) C++語言(3117) 安卓(2998) 打字稿(2995) VBA(2789) Java相關(2746) 疑難問題(2699) 细绳(2522) 單片機工控(2479) iOS(2429) ASP.NET(2402) MongoDB(2323) 麻木的(2285) 正则表达式(2254) 字典(2211) 循环(2198) 迅速(2185) 擅长(2169) 镖(2155) 功能(1967) .NET技术(1958) Web開發(1951) python-3.x(1918) HtmlCss(1915) 弹簧靴(1913) C++(1909) xml(1889) PostgreSQL(1872) .NETCore(1853) 谷歌表格(1846) Unity3D(1843) for循环(1842)

熱門瀏覽
  • 面試突擊第一季,第二季,第三季

    第一季必考 https://www.bilibili.com/video/BV1FE411y79Y?from=search&seid=15921726601957489746 第二季分布式 https://www.bilibili.com/video/BV13f4y127ee/?spm_id_fro ......

    uj5u.com 2020-09-10 05:35:24 more
  • 第三單元作業總結

    1.前言 這應該是本學期最后一次寫作業總結了吧。總體來說,對作業的節奏也差不多掌握了,作業做起來的效率也更高了。雖然和之前的作業一樣,作業中都要用到新的知識,但是相比之前,更加懂得了如何利用工具以及資料。雖然之間卡過殼,但總體而言,這幾次作業還算完成的比較好。 2.作業程序總結 相比前兩個單元,此單 ......

    uj5u.com 2020-09-10 05:35:41 more
  • 北航OO(2020)第四單元博客作業暨課程總結博客

    北航OO(2020)第四單元博客作業暨課程總結博客 本單元作業的架構設計 在本單元中,由于UML圖具有比較清晰的樹形結構,因此我對其中需要進行查詢操作的元素進行了包裝,在樹的父節點中存盤所有孩子的參考。考慮到性能問題,我采用了快取機制,一次查詢后盡可能快取已經遍歷過的資訊,以減少遍歷次數。 本單元我 ......

    uj5u.com 2020-09-10 05:35:48 more
  • BUAA_OO_第四單元

    一、UML決議器設計 ? 先看下題目:第四單元實作一個基于JDK 8帶有效性檢查的UML(Unified Modeling Language)類圖,順序圖,狀態圖分析器 MyUmlInteraction,實際上我們要建立一個有向圖模型,UML中的物件(元素)可能與同級元素連接,也可與低級元素相連形成 ......

    uj5u.com 2020-09-10 05:35:54 more
  • 6.1邏輯運算子

    邏輯運算子 1. && 短路與 運算式1 && 運算式2 01.運算式1為true并且運算式2也為true 整體回傳為true 02.運算式1為false,將不會執行運算式2 整體回傳為false 03.只要有一個運算式為false 整體回傳為false 2. || 短路或 運算式1 || 運算式2 ......

    uj5u.com 2020-09-10 05:35:56 more
  • BUAAOO 第四單元 & 課程總結

    1. 第四單元:StarUml檔案決議 本單元采用了圖模型決議UML。 UML檔案可以抽象為圖、子圖、邊的邏輯結構。 在實作中,圖的節點包括類、介面、屬性,子圖包括狀態圖、順序圖等。 采用了三次遍歷UML元素的方法建圖,第一遍遍歷建點,第二、三次遍歷設定屬性、連邊,實作圖物件的初始化。這里借鑒了一些 ......

    uj5u.com 2020-09-10 05:36:06 more
  • 談談我對C# 多型的理解

    面向物件三要素:封裝、繼承、多型。 封裝和繼承,這兩個比較好理解,但要理解多型的話,可就稍微有點難度了。今天,我們就來講講多型的理解。 我們應該經常會看到面試題目:請談談對多型的理解。 其實呢,多型非常簡單,就一句話:呼叫同一種方法產生了不同的結果。 具體實作方式有三種。 一、多載 多載很簡單。 p ......

    uj5u.com 2020-09-10 05:36:09 more
  • Python 資料驅動工具:DDT

    背景 python 的unittest 沒有自帶資料驅動功能。 所以如果使用unittest,同時又想使用資料驅動,那么就可以使用DDT來完成。 DDT是 “Data-Driven Tests”的縮寫。 資料:http://ddt.readthedocs.io/en/latest/ 使用方法 dd. ......

    uj5u.com 2020-09-10 05:36:13 more
  • Python里面的xlrd模塊詳解

    那我就一下面積個問題對xlrd模塊進行學習一下: 1.什么是xlrd模塊? 2.為什么使用xlrd模塊? 3.怎樣使用xlrd模塊? 1.什么是xlrd模塊? ?python操作excel主要用到xlrd和xlwt這兩個庫,即xlrd是讀excel,xlwt是寫excel的庫。 今天就先來說一下xl ......

    uj5u.com 2020-09-10 05:36:28 more
  • 當我們創建HashMap時,底層到底做了什么?

    jdk1.7中的底層實作程序(底層基于陣列+鏈表) 在我們new HashMap()時,底層創建了默認長度為16的一維陣列Entry[ ] table。當我們呼叫map.put(key1,value1)方法向HashMap里添加資料的時候: 首先,呼叫key1所在類的hashCode()計算key1 ......

    uj5u.com 2020-09-10 05:36:38 more
最新发布
  • 【中介者設計模式詳解】C/Java/JS/Go/Python/TS不同語言實作

    * 中介者模式是一種行為型設計模式,它可以用來減少類之間的直接依賴關系,
    * 將物件之間的通信封裝到一個中介者物件中,從而使得各個物件之間的關系更加松散。
    * 在中介者模式中,物件之間不再直接相互互動,而是通過中介者來中轉訊息。 ......

    uj5u.com 2023-04-20 08:20:47 more
  • 露天煤礦現場調研和交流案例分享

    他們集團的資訊化公司及研究院在一個礦區正在做智能礦山的統一平臺的 試點,專案投資大概1億,包括了礦山的各方面的內容,顯示得我們這次交流有點多余。他們2年前開始做智能礦山的規劃,有很多煤礦行業專家的加持,他們的描述是非常完美,但是去年底應該上線的平臺,現在還沒有看到影子。他們確實有很多場景需求,但是被... ......

    uj5u.com 2023-04-20 08:20:25 more
  • 《社區人員管理》實戰案例設計&個人案例分享

    設計是一個讓人夢想成真程序,開始編碼、測驗、除錯之前進行需求分析和架構設計,才能保證關鍵方面都做正確 ......

    uj5u.com 2023-04-20 08:20:17 more
  • 軟體架構生態化-多角色交付的探索實踐

    作為一個技術架構師,不僅僅要緊跟行業技術趨勢,還要結合研發團隊現狀及痛點,探索新的交付方案。在日常中,你是否遇到如下問題 “ 業務需求排期長研發是瓶頸;非研發角色感受不到研發技改提效的變化;引入ISV 團隊又擔心質量和安全,培訓周期長“等等,基于此我們探索了一種新的技術體系及交付方案來解決如上問題。 ......

    uj5u.com 2023-04-20 08:20:10 more
  • 【中介者設計模式詳解】C/Java/JS/Go/Python/TS不同語言實作

    * 中介者模式是一種行為型設計模式,它可以用來減少類之間的直接依賴關系,
    * 將物件之間的通信封裝到一個中介者物件中,從而使得各個物件之間的關系更加松散。
    * 在中介者模式中,物件之間不再直接相互互動,而是通過中介者來中轉訊息。 ......

    uj5u.com 2023-04-20 08:19:44 more
  • 露天煤礦現場調研和交流案例分享

    他們集團的資訊化公司及研究院在一個礦區正在做智能礦山的統一平臺的 試點,專案投資大概1億,包括了礦山的各方面的內容,顯示得我們這次交流有點多余。他們2年前開始做智能礦山的規劃,有很多煤礦行業專家的加持,他們的描述是非常完美,但是去年底應該上線的平臺,現在還沒有看到影子。他們確實有很多場景需求,但是被... ......

    uj5u.com 2023-04-20 08:19:07 more
  • 《社區人員管理》實戰案例設計&個人案例分享

    設計是一個讓人夢想成真程序,開始編碼、測驗、除錯之前進行需求分析和架構設計,才能保證關鍵方面都做正確 ......

    uj5u.com 2023-04-20 08:18:57 more
  • 軟體架構生態化-多角色交付的探索實踐

    作為一個技術架構師,不僅僅要緊跟行業技術趨勢,還要結合研發團隊現狀及痛點,探索新的交付方案。在日常中,你是否遇到如下問題 “ 業務需求排期長研發是瓶頸;非研發角色感受不到研發技改提效的變化;引入ISV 團隊又擔心質量和安全,培訓周期長“等等,基于此我們探索了一種新的技術體系及交付方案來解決如上問題。 ......

    uj5u.com 2023-04-20 08:18:49 more
  • 05單件模式

    #經典的單件模式 public class Singleton { private static Singleton uniqueInstance; //一個靜態變數持有Singleton類的唯一實體。 // 其他有用的實體變數寫在這里 //構造器宣告為私有,只有Singleton可以實體化這個類! ......

    uj5u.com 2023-04-19 08:42:51 more
  • 【架構與設計】常見微服務分層架構的區別和落地實踐

    軟體工程的方方面面都遵循一個最基本的道理:沒有銀彈,架構分層模型更是如此,每一種都有各自優缺點,所以請根據不同的業務場景,并遵循簡單、可演進這兩個重要的架構原則選擇合適的架構分層模型即可。 ......

    uj5u.com 2023-04-19 08:42:41 more