多人协作的形式:历史与发展
多人协作的历史十分悠久,起源于静态的多人协作模式,即每个人先完成自己的工作,然后再进行汇总。
静态的多人协作模式
- 递增式协作
- 邮件:你来我往
- 论坛:跟帖回复
- 独占式协作
- 文档传递
- 微软VSS
- 合并式协作
- SVN
- Git
- diff,patch,merge指令

常见的静态多人协作方式
从静态到动态
- 静态协作的比喻
- 拼接画
- 积木
- 静态协作的特点
- 多版本
- 块操作
- 有协作动作
- 静态协作的缺点
- 版本碎片化
- 缺乏时效性
- 协作动作成本高
静态多人协作的成本,会随着加入人数和项目的复杂度呈几何级数的增长。因此,对于企业来说,急需一种无协作动作、唯一版本、版本可控的无协作成本模式,即动态多人协作模式。
动态的多人协作
- 动态协作的比喻
- 一起画黑板
- 动态协作的特点
- 唯一版本
- 原子操作
- 无协作动作
- 动态协作的优点
- 版本可控
- 实时
- 无协作成本
- 典型产品
- Office Online
- 石墨
- OnlyOffice
多人协作的基础:原理与架构
- 操作化
- 可传输
- 可还原

举例说明多人协作的实现方式
操作化
操作化,指任何信息都可以转换为一组操作的集合。很容易理解,但它仍有不少值得思考的点:
- 分割与组合
- 如何保证:信息的所有变化都可以分解为操作的集合之,操作如何覆盖出信息的所有变化/li>
- 分割的颗粒度如何决定ul>
- 粗一点/li>
- 细一点/li>
- 如何兼顾解释性与扩展性/li>
- 绝对操作
- 针孔打印机的完美世界
- 相对操作
- 4K电视不是梦
- 为什么数字电视稳定性不如模拟电视
- 绝对操作与相对操作比喻:时间与空间的互换
- 好用的指令集,保证覆盖信息的全部变化与操作的集合
- 经过实践验证的颗粒度,完美兼顾解释性与扩展性平衡
可传输
可传输,就是指操作有办法通过 络传输给其他终端。实现动态多人协作,需要考虑以下几点:
- 传输内容
- 原始文本
- 清晰
- 冗余
- 压缩技术
- 逻辑压缩
- 协议压缩
- 手动压缩
- 原始文本
- 络协议
- Socket
- TCP
- UDP
- HTTP
- WebSocket
- Socket
- QoS(Quality of Service,服务质量)
- 快速失败
- 自动回滚
- 自动重连
- 自动恢复
可还原
可还原,就是指接收到来自 络的操作消息后,可以在本地完全一致地再次执行该操作。可还原包括了:
- 绝对操作的还原
- 控制体积
- 合理的提示
- 相对操作的还原
- 严格的顺序性
- 从源头保障顺序性
- 顺序性的补救
- 本地操作的还原
- 过滤收到的操作集合
- 从源头细化操作颗粒
- 本地保存本地执行
- 无入侵的还原
- 定义入侵
- 排除入侵
- 千人千面
多人协作的难点:乱序与冲突
乱序
乱序的表现形式如下图,小明在客户端执行了一系列操作,传递到服务器时发生乱序,导致小花看到了截然不同的信息:

为了解决乱序问题,可以尝试以下方法:
1. 用性能换取顺序正确——基于协议

2. 用性能换取顺序正确——基于回执

两种方法的优缺点
- 基于协议
- 优点
- 可靠,历经考验
- 简单,无需开发
- 缺点
- 资源开销高
- 必须整套使用
- 优点
- 基于回执
- 优点
- 自主可控,按需开发
- 资源开销可控
- 缺点
- 需要自己投入开发
- 应用层逻辑控制使得 络复杂度向外蔓延
- 复杂度带来维护成本
- 优点
基于乱序处理方法的总结
络不是绝对可靠的,为了实现相对可靠,需要付出一定的代价,企业需要考虑的是:如何衡量所付出的代价与产出成正比。
冲突
比乱序更高级的一种表现形式,存在多向、多维度等问题。

如何避免错误的蔓延/strong>
原则:任何一次不一致,都会导致后续的操作基于错误的信息进行,从而不断扩大错误,造成无法收拾的结果。因此,不一致是不能被容忍的。
解决办法:
- 严格一致性:独占
- 最终一致性:检查与修复
- 非技术手段:设计与提示
严格的一致性
独占就是同一时间同一范围只能由一人操作。
- 范围(以SpreadJS为例)
- 整个表格,类似VSS
- 工作表
- 单元格范围
- 排他性
- 独占冲突时,必有一方被弹开
- 直到占有者解开,不然无法占用
- 占用前无法操作
- 原理和锁基本一致
- 优点
- 可以确保严格一致性,不会产生多版本的错误累积
- 比起修复恢复这类弥补手段,一开始就不出错的成本最低
- 逻辑清楚简单,开发维护成本低
- 缺点
- 静态协作的味道
- 独占动作严重影响体验
- 大幅降低协作效率
- SpreadJS提供的支持
- 锁定工作表
- 锁定单元格
最终一致性
基于唯一正确顺序,察觉客户端的错误,撤销错误操作后重新执行正确的操作。
- 唯一正确
- 服务器到达顺序
- 协作边界分流
- P2P+选举算法
- 察觉错误
- 服务器回执id
- 服务器回执操作,MS
- 撤销错误
- 撤销到错误发生前的一步操作的结果
- 利用SpreadJS的撤销功能
- 利用操作版本快照
- 重新执行
- 操作队列需保存
- 区分好无感知执行与显式执行
非技术手段
技术手段追求错误0发生,而非技术手段则可以降低错误发生的可能性。
- 选中框
- 非常重要但不显眼
- 人性化的独占
- 操作的预期
- 协作感
- SpreadJS提供高度可自定义的边框
- 协作设计
- 设计协作区域与合并手段
- 设置权限
- SpreadJS提供几乎Excel的所有公式
- SpreadJS提供了工作表和单元格锁定功能
- 单向协作
- 区分单向与双向协作的场景
- 对单向协作尽量放开
- 对双向协作严谨设计
SpreadJS作为实现多人协作“在线excel”系统的巨大优势是什么/strong>
首先,可以明确一点:SpreadJS完全可以用作多人协作系统开发的组件。原因在于:
- SpreadJS的产品质量是毋庸置疑的
- SpreadJS在设计之初,便考虑到了多人协作的可能,而除此之外,绝大多数的前端产品都不是为了多人协作而设计的
- 多人协作需要中心系统的支持,SpreadJS基于纯前端的体系架构可以很容易的嵌入系统开发,而无需过多考虑与原生系统的兼容性,这是常规组件是无法做到的
- 要实现多人协作,需要投入一定的开发成本,SpreadJS作为一款开发工具,可以有效帮助开发人员减轻代码量多人协作表格的本质:
- Server – Clients 中心系统,类似数值敏感的小型 游
- 任何这类系统都是在体验和正确性中寻求平衡
多人协作表格的特点:
- 表格的数值敏感性高于 游,数据操作和存储的挑战更大
- 表格的计算复杂度更高,尤其涉及复杂公式嵌套与全量统计筛选
- Web存在天花板,所以复杂的页游并不多见,端游较多
对SpreadJS这类开发工具/组件的展望与期待
- SpreadJS已经可以很好地支持多人协作的最终一致性。如果能支持多人多撤销队列,或者撤销重做自定义,那么就可以给用户提供更加易用且多样化的体验效果,从此丝般顺滑不是梦。
- SpreadJS的绝大部分功能是支持命令的,这使得操作化变得更简单。如果SpreadJS能开放命令自定义,便可以让自主控制颗粒度成为可能,用户可以针对具体的业务逻辑做出更加精细化的操作转换,大幅提高协作效率。
- SpreadJS不仅在数据录入、数据填 等方面表现出强大的功能,其各类统计分析与图形化手段也是一个不少,一旦明年的透视表功能上线,使用SpreadJS开发在线协同系统的数据商业价值将更易体现,用户将体验到“表格”无限的魅力与威力。
- 表格在多人协作中的数据量增长速度比单人使用时快得多,希望SpreadJS可以支持更大的数据量,尤其是在大数据量情况下仍旧保持操作的性能与体验。
SpreadJS | 下载试用
纯前端表格控件SpreadJS,可满足 .NET、Java、App 等应用程序中的 Web Excel 组件开发、数据填 、在线文档、图表公式联动、类 Excel UI 设计等业务场景,并在数据可视化、Excel 导入导出、公式引用、数据绑定、框架集成中无需大量代码开发和测试,极大降低了企业研发成本和项目交付风险。
购正版SpreadJS 表控件授权限时优惠!最高立减万元!点击了解更多优惠
如果您对我们的产品还有任何疑问,欢迎咨询在线客服>>

标签:
声明:本站部分文章及图片源自用户投稿,如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢!