Zxch3n's Blog

About Me

I’m the founder of Loro. We build tools for local-first development and collaboration.

Currently, my main focus is on this startup company. I aim to create the best local-first collaboration tool, one that users can easily use, trust, and rely on for a lifetime.

I’ve been writing code for over a decade, and it’s often something that brings me joy. My main areas of interest are Rust, CRDTs, and text editors.

Loro Debug 日志 20240925

Wed, 25 Sep 2024 22:00:02 GMT

这个 Bug 出现在我试图用 Loro 来导入整个 Git Repo 的时候出现。分析了好几个小时最终才定位到 Bug，希望以后不要再有这种体验了，浅浅记录一下。
这 Bug 是以让人一头雾水的形态出现的。
首先背景是 Loro 支持记录 DAG 的操作历史结构，于是我想让它能够支持同步整个 Workspace 的内容，像 Git 一样。于是我这样设计：
- 根文档：是一片 Loro Doc，内部用 Tree 的结构存储“目录”信息。它会保存整个仓库的 Git 历史，但它不会记录每个文件的具体修改，而是记录这些文件修改前后的具体版本。具体方式是把每个文件夹和文件都当作 CRDT Tree 上的一个节点，这个节点会有 name 信息，是否是文件夹的信息，以及到它内容的指针；如果它是纯文本文档就会用 CRDT 文档的方式记录，并且会记录它的版本信息
- 内容指针：一个 Workspace 内的内容分成两种，一种是 CRDT 文档（用于同步纯文本信息），一种是二进制文件；所以在内容指针上也分成两种，分别指向不同的内容。
- 纯文本 CRDT 文档：会在自己的 CRDT 文档的 DAG 保存自己这个文件的完整的编辑历史
- 二进制文件：对于所有没办法转成合法 utf8 的内容都会直接用覆盖方式进行更新
最开始报的错误是根文档中 CRDT Tree 上的节点的 name 没有被设置。为了检查这个问题，我把所有对节点初始化的操作收束到一起，让它一定会在初始化的时候就设置好 name。但是无济于事，还是会有这个错误。加了相关的 Log 之后，发现这个节点 ID 就是被设置过 name。
会不会是因为出现了重复的 Peer ID 导致了呢？在导入 Git Repo 过程中，有时有些情况会允许我们重用 Peer ID，所以做了一些优化。但这个 bug 的出现让我对这些优化都产生了不自信，于是把它们关了，但是 bug 依旧存在。
我还继续检查了是不是 rename/copy 导致的错误，会不会是 delete 导致的错误。但都一一排除了。
会不会是因为我加了能够在单文档的不同版本上进行编辑的能力 https://github.com/loro-dev/loro/pull/473 之后出了错？这个功能会不会和现有的 Tree 内部的设计的 Invariants 产生冲突了？但思来想去没有想到合理的解释。
那还有一种可能性是我最不愿意考虑的：loro 内部的 bug 导致当前状态错误。Loro 老的版本中不支持在 detached 模式下进行编辑，有可能因为它的加入导致有些以前没考虑过的 corner case 被暴露出来。我们切换版本的时候往往都是根据版本之间的差异计算完成的，如果这里的差异计算出错，那么文档的状态就可能会错误。检查这种错误的最简便的方法就是回放历史，从而就能对比确认当前版本的状态复合从头开始回放文档计算出来的状态。
于是我在会出现找不到 name 的情况的位置加了确认 state 正确性的检查，结果发现真的是这里出错！正确的文档上是不存在这个节点的，我们恰好多了一个节点。那就是 Loro 内部的错误，之前没有被暴露出来。于是我先进行了下面的检查
- 如果 DiffCalculator 不用复杂的优化会不会出错
- 看看多出来的节点是不是曾经被删除过 - 不是
- 确认 Consistency Check 本身的代码是不是正确的
- 确认 Loro 现在是能够通过本身自己的所有内部测试的
- Frontiers 转 VersionVector 和 VV 转 Frontiers 的实现是正确的
- (感慨如果能通过 Log 直接生成测试用例来回放现场就好了，复现起来挺麻烦的
- 测试了 Tree 的内部 State 的 Invariants 的正确性
上面这些检查都没有发现问题
随后的一个突破点来自添加了更多的 log 之后发现，出问题的那个节点它的节点 ID 大于当前的文档的 Version Vector，也就意味着这个节点在一次版本切换中本来应该被 Revert 掉的，结果没有发生这个 Revert。于是就顺着这个线索找问题。
我们的文档状态可以理解为是通过 Diff Calculator 来完成更新的，Diff Calculator 会通过事件告诉文档需要进行什么样的更新。随后我发现事件中存在这个文档的创建事件，但不存在 Revert 事件。那就意味着 Tree 相关的 Diff Calculator 上出问题了，Tree State 不背这个锅。
那到 Tree Diff Calculator 这一侧，它就是一棵保存了树的相关操作历史的树，当发生版本切换的时候就在它上面执行这些切换操作计算出 InternalDiff，然后交给 State 完成更新。这部分的代码相关的 invariants 很多，但是相关的自动检查不多，于是就加了一波检查，然后又再是读日志分析问题，把一些可能有问题的优化去掉，看看病症有没有好起来。
最后定位到了是一处优化上错误的过滤了 ops，导致有一个本应该被记录到 tree 中的 op 没有被记录，从而导致后续计算错误才产生了这个问题。将这个优化去掉之后整体就恢复正常了。

教训

目前 Fuzz 的覆盖率还不够高，没有覆盖到刚刚那种场景，未来要加强 Fuzz 的覆盖率
Tree Diff Calculator 内部的 Invariants 需要加更多的检查来保证行为正确性
要引入一些机制让 State 错误更容易暴露出来
- 例如提供对状态的 Hash，落盘前对内容做一次 Hash，在版本切换的时候检查 Hash 正确性
- 在合适的时机做完整性检查

The Cook and the Chef: Musk's Secret Sauce 书摘

Sun, 04 Sep 2022 16:10:00 GMT

最近读了一篇 Wait But Why 2015 年的长文，The Cook and the Chef: Musk’s Secret Sauce, 讨论的是马斯克的秘方：他为什么做这些事，为什么能够做到这些事。以马斯克为切入点，文章主要讨论了人们的思考方式，醍醐灌顶，在此摘录一下。（原文实在太长，本文只是其中的一小部分核心的记录）

两种不同的地质学

1681年，英国神学家托马斯-伯内特出版了《地球的神圣理论》，他解释了地质学的工作原理：当6000年前，地球形成为一个完美的球体，表面是田园风光的土地，内部是水。但后来，当表面干涸后，在其表面形成了裂缝，释放了内部的大部分水。这造成了《圣经》中的大洪水，诺亚不得不在整个星期内处理。一旦事情稳定下来，地球就不再是一个完美的球体—地球的表面被扭曲，带来了下面的山脉、山谷和洞穴，整个地球上到处都是洪水受害者的化石。

神学的难题是如何调和大量看似古老的地球特征与《圣经》中详述的更短的地球时间线。对于当时的神学家来说，这是他们的广义相对论与量子力学之争的版本，而伯内特想出了一个可行的弦理论，将这一切统一在一个屋檐下。

这不仅仅是伯内特的问题。有足够多的理论在协调地质学与《圣经》经文之间的关系，以至于今天需要一个15000字的“洪水地质学”维基百科页面。

大约在同一时间，另一群思想家开始研究地质学难题：科学家。

对神学家来说，游戏的起始规则是：“事实：地球始于6000年前，曾经发生过一场席卷地球的洪水”，他们的谜题严格地在这个背景下进行。但是科学家们在开始游戏时根本就没有任何规则。这个谜题是一块白板，欢迎任何他们发现的观察和测量。

在接下来的300年里，科学家们建立了一个又一个理论，随着新技术带来新的测量类型，旧的理论被推翻，并被新的更新版本所取代。随着地球的明显年龄越来越长，科学界不断给自己带来惊喜。1907年，有一个巨大的突破，美国科学家贝特拉姆-博尔特伍德开创了通过放射性测定法破译岩石年龄的技术，该技术在岩石中找到具有已知放射性衰变率的元素，并测量这些元素中哪些部分保持完整，哪些部分已经转化为衰变物质。

放射性测年法将地球的历史倒退到几十亿年前，这为科学界带来了新的突破，如大陆漂移理论，这反过来又导致了板块构造学说。科学家们大展拳脚。

与此同时，洪水地质学家们却不以为然。对他们来说，科学界的任何结论都是没有意义的，因为他们一开始就在破坏游戏规则。地球的正式年龄不到6000年，所以如果放射性测年显示出其他情况，那就是一种有缺陷的技术，就这样。

但是，科学证据越来越有说服力，随着时间的推移，越来越多的洪灾地质学家接受了科学家的观点—也许他们的游戏规则就是错误的。

无论信仰在精神领域扮演什么角色，当我们寻求关于地球年龄、我们物种的历史、闪电的原因或宇宙中任何其他物理现象的答案时，大多数人都同意数据和逻辑是远比信仰和经文更有效的工具。

然而当涉及到我们思考的大部分方式、我们做决定的方式以及我们生活的方式时，我们更像神学家而不是科学家。

人们如何推理

在数学中，我们把公设称为“公理”，而公理是100%真实的。因此，当我们从公理中建立结论时，我们称它们为“证明”，它们也是100%真实的。

而在物理学上是没有公理的，这是有原因的：

我们可以把牛顿的万有引力定律称为公理—在很长一段时间内，它确实看起来像一个公理，但是当爱因斯坦出现并表明牛顿实际上在极端条件下是不成立的，而广义相对论无论如何都能工作。因此，你会称广义相对论为公理。但是，当量子力学出现并表明广义相对论在极小的范围内无法适用，需要一套新的定律来解释这些情况时，又会发生什么？

一个基本的推理看起来像这样

因为 A = B
且 B = C + D
所以 A = C + D

而在科学上它是这样的

因为(根据现有事实，可能是这样) A = B
且(根据现有事实，可能是这样) B = C + D
所以 (根据我所知的，它看起来是这样) A = C + D

假设是为了被测试而建立的。测试一个假设可以推翻它或加强它，如果它通过了足够的测试，它就可以升级为理论。

现如今我们看到洪水地质学时会觉得这种理论很愚蠢，但在当时的时代背景下这并不是愚蠢和不科学的。他们中的许多人在自己的领域中与科学地质学家同事一样有成就。那么为什么他们会得出一个错误的结论？原因就在于他们是宗教教条的受害者，他们被告知应不带质疑地相信这些教条。

洪水地质学家的推理方式是

因为 (根据教条) A = B
且 (根据教条) B = C + D
所以 (不容置疑的) A = C + D

甚至比起成为任何教条的受害者，洪水地质学家更是他们自己对教条的确定性的受害者。没有确定性，教条就没有力量。而当需要数据才能相信某些东西时，虚假的教条就没有了立足之地。阻碍洪水地质学家的不是教会的教条，而是教会基于信仰的确定性心态。

如霍金所说：“知识最大的敌人不是无知，而是知识的幻觉”。科学地质学家和洪水地质学家都不是一开始就有知识。但是，让科学地质学家有力量去寻找真相的是知道他缺乏知识。科学地质学家认同实验室的心态，即从“我什么都不知道”开始，然后再向上努力。

大多数人的思考方式

被称为预先看到未来到来的人，实际上并不是因为他们能超脱现实，而是因为科学的思考方式以及孜孜不倦的学习，让他们更能看清现实。而主流的被大多数人所认可的“现实”，则是落后于这个时代的。

每个人的成长方式不同，但对我认识的大多数人来说，情况是这样的：我们的父母和老师教给我们各种各样的东西—什么是正确和错误，什么是安全和危险，你应该和不应该成为什么样的人。但我们的想法是。我是一个成年人，所以我比你知道得更多，这是不容争论的，不要争论，只要服从。

孩子的本能不只是知道该做什么和不该做什么，她想了解她所处环境的规则。而要理解一个东西，你必须对这个东西的建造过程有一个认识。当父母和老师告诉孩子要做XYZ并简单服从时，这就像在孩子的脑子里安装了一个已经设计好的软件。当孩子们问“为什么”，然后问“为什么”，然后问“为什么”的时候，他们正试图解构这个软件，看看它是如何建成的—深入到下面的第一原理，这样他们就可以衡量自己究竟应该在多大程度上关心成人似乎如此坚持的东西。

孩子头几次玩“为什么 ”的游戏时，家长认为很可爱。但是，许多家长和大多数老师很快就想出了一个办法，把这个游戏切断。

“因为我是这么说的。”

“因为我是这么说的”给孩子的解构工作插入了一个具体的底线，低于这个底线就不能再提“为什么”。它说：“你想要第一原理？就在这里。这就是你的底线。没有必要再有‘为什么’。现在他妈的把你的靴子穿上，因为我说了，我们走吧。”

平心而论，父母的生活很糟糕。他们必须做所有过去必须做的事情，只是现在还有这些好奇的小孩需要他们来照顾，他们认为父母的存在是为了服务他们。在一个繁忙的日子里，刨根问底的“为什么”游戏是一场噩梦。

但这可能是一个值得忍受的噩梦。一条命令、一个教训或一句智慧的话语，如果没有洞察到它所建立的逻辑步骤，就是填鸭，而不是教他们讲道理。当我们被这样教育的时候，我们最终得到的是一桶鱼，而没有鱼竿—一个我们已经学会如何使用的安装好的软件，但没有能力自己编写任何东西。

学校让事情变得更糟。我最喜欢的思想家之一，作家Seth Godin，在TED演讲中解释说，目前的教育系统是工业时代的产物，那是一个生产力和生活水平飞速提高的时代。但伴随着更多的工厂，需要更多的工厂工人，所以我们的教育系统是围绕这个目标重新设计的。他解释说：

普及公共教育的唯一目的不是为了培养明天的学者—我们有很多学者。它是为了培养人们愿意在工厂工作。它是为了训练人们的行为，遵守规定，适应环境。“我们对你进行一整年的处理。如果你有缺陷，我们就把你留下来，再次处理你。我们让你们坐成一排，就像他们在工厂里组织东西一样。我们建立了一个关于可互换人员的系统，因为工厂是基于可互换的部件。”

这一概念可以与我的另一位喜爱的作家詹姆斯-克里尔最近在他的博客上解释的内容结合起来：

在20世纪60年代，一位名叫乔治-兰德的创造性表现研究者对1600名5岁儿童进行了研究，98%的儿童得分在“高度创造性 ”范围内。兰德博士以五年为单位对每个受试者进行了重新测试。当这些孩子10岁的时候，只有30%的人得分在高度创造性的范围内。这个数字在15岁时下降到12%，到25岁时只有2%。当孩子们成长为成年人时，他们的创造力实际上已经被训练出来了。用兰德博士的话说，“非创造性的行为是后天习得的”。

这很有道理，对吗？创造性思维是第一原理推理的一个近亲。在这两种情况下，思考者都需要发明自己的思维途径。人们认为创造力是一种天生的才能，但它实际上更像是一种思维方式—它是在空白画布上绘画的思维版本。但要做到这一点，需要大脑软件在想出新东西方面的熟练和实践，而学校训练我们的概念恰恰相反—跟着领导走，单线作战，并在考试中获得真正的优势。学校交给孩子们的不是一张空白的画布，而是一本涂色书，并告诉他们要保持在线内。

现在的教育方式很多时候是

因为 (老师/课本/家长说过): A = B
且 (老师/课本/家长说过): B = C + D
从而 (可以肯定): A = C + D

以这种思考方式生活，人们最终得到的是一套不一定基于他们自己深入思考的价值观，一套不一定基于他们所生活的世界的现实的关于世界的信念，以及一堆他们可能很难用诚实的心去捍卫的观点。

新部落主义

新部落主义：群体中虽然每个人都是独立的，但群体有时有它自己的价值观和观点，定义了每个人应该怎么思考和是非对错。这里的部落指的是一个个群体，比如某个党派、某个教会、某种兴趣小组。

部落主义的好坏取决于部落成员和他们与部落的关系。

当部落和部落成员都有一个独立的身份，而且他们碰巧是相同的时候，部落主义是好的。部落成员选择成为部落的一部分，因为这恰好符合他的真实身份。如果部落或成员的身份演变到两者不再匹配的地步，这个人就会离开部落。让我们把这称为有意识的部落主义。

当部落和部落成员的身份是同一的时候，部落主义是不好的。部落成员的身份是由部落的教条碰巧所说的任何东西决定的。如果部落的身份改变了，部落成员的身份也会随之改变，步调一致。部落成员的身份不能独立于部落的身份而改变，因为成员没有独立的身份。让我们把这称为盲目的部落主义。

人类想要内部的稳定安全，对于一个在成长过程中对自己的独特性格感到动摇的人来说，部落和它的指导性教条是一个重要的生命线—一个提供全套人类意见和价值观的一站式商店。

人类也渴望确定性的舒适和安全，而在盲目的部落主义的群体思维中，最能体现信念的地方莫过于此。科学家以数据为基础的意见只有在她所拥有的证据中才是强有力的，而且本质上会发生变化，而部落教条主义则是一种信仰的练习，由于没有数据的约束，盲目的部落成员确信地相信他们所相信的。

我们讨论了为什么数学有证明，科学有理论。在生活中，我们也许应该限制自己的假设。但盲目的部落主义却有数学家的自信：

因为（部落这样说）： A = B
且（部落这样说）: B = C + D
从而，可以肯定：A = C + D

试一试吧。下次你和你所在群体的成员在一起时，表达你在某个话题上的心态变化。如果你是一个虔诚的基督徒，在教堂里告诉人们你不再确信有上帝的存在。如果你是博尔德的一名艺术家，在下一个晚餐聚会上解释你认为全球变暖实际上可能是一个自由主义的骗局。如果你是一个伊拉克人，告诉你的家人，你最近觉得自己很支持以色列。如果你和你的丈夫是坚定的共和党人，告诉他你对奥巴马医改的态度有所转变。如果你来自波士顿，告诉你的朋友你今年会支持洋基队，因为你喜欢他们现在的球员群。

如果你在一个具有完全确定的盲目心态的部落里，你可能会看到一个惊恐的表情。这不仅看起来是错误的，而且似乎是异端邪说。他们可能会生气，他们可能会热情地试图说服你，他们可能会切断对话—但不会有开放性的对话。而且由于身份与盲目部落主义的信仰如此交织在一起，这个人实际上可能会在事后感到与你不那么亲近。因为对于僵化的部落主义的人来说，共同的教条在他们的亲密关系中发挥着比他们可能认识到的更重要的作用。

我们世界上的大多数主要分歧都来自盲目的部落主义，而在光谱的极端—人们是受控的绵羊—盲目的部落主义可能导致可怕的事情。就像历史上的那些时代，几个有魅力的坏人仅仅通过展示力量和激情就能建立一支由忠诚的步兵组成的庞大军队。盲目的部落主义是我们最大规模的暴行的真正幕后黑手。

我们中的大多数人可能不会加入纳粹党，因为在“盲目 <-> 理性”的光谱上我们中的大多数人并不处于极端盲目的那一端。但我认为我们中的许多人也不在另一端。相反，我们通常处于朦胧的中间地带。

解决方案

为了成为一个独立思考者，我们需要吸收三点认知：

1. 你什么也不知道

科学地质学家和洪水地质学家都不是一开始就有知识。但是，让科学地质学家有力量去寻找真相的是「他知道他缺乏知识」。科学地质学家认同实验室的心态，即从“我什么都不知道”开始，然后再以此往上努力。

如果你想看实践中的实验室心态，只要搜索一下任何著名科学家的名言，你就会看到他们每个人都在表达他们什么都不知道的事实。

艾萨克-牛顿：“对我自己来说，我只是一个在沙滩上玩耍的孩子，而真理的浩瀚海洋在我面前还没有被发现”
理查德-费曼：“我生来就不知道，只有一点时间来改变这里和那里。”
尼尔斯-玻尔：“我说的每一句话都必须被理解为不是一种肯定，而是一个问题。”

这些聪明得令人发指的人之所以对自己的知识如此谦虚，是因为作为科学家，他们知道不合理的确定性是理解的祸根，是有效推理的死亡。他们坚信，各种推理都应该在实验室里进行，而不是在教堂里进行。

如果你和一辆汽车单独呆在一个房间里，想弄清楚它是如何工作的，你可能会从拆开它开始，检查各个部件以及它们是如何结合在一起的。为了对我们的思维做同样的事情，我们需要回到四岁的自我，通过重新玩“为什么”的游戏，开始解构我们的思考。现在是时候卷起袖子，打开引擎盖，用我们的双手去解决一些并不有趣的问题，比如我们真正想要什么，什么是真正可能的，以及我们的生活方式是否符合这些东西的逻辑。

对于每个问题，我们面临的挑战是不断地问为什么，直到你触及最底层—这个最底层会告诉你，你是在教堂还是在实验室。如果你碰到的地板是一个或多个第一性原理，代表了事实或你的内在自我，并且逻辑准确，你就在实验室里。如果一个“为什么”的路径碰到了一个叫做“因为「权威」这么说”的楼层—如果你一直往下走，并在底部意识到整个事情只是因为你接受了你父母、朋友、宗教或社会的说法，那么你就在教堂里。如果那个教会的信条不能真正与你产生共鸣或反映当前世界的现实—如果事实证明你一直在用错误的配方工作—那么无论在它上面建立了什么结论，都将是同样错误。正如洪水地质学家所证明的那样，一个推理链只有在其最薄弱的环节才会强大。

你真正要仔细观察的是毫无道理的确定性。在生活中，你对某件事情的感觉是如此正确，以至于它没有资格成为一个假设，甚至是一个理论，但它感觉像是一个公理？当有公理级别的确定性时，这意味着要么有一些严肃的具体和经过验证的数据在下面，要么就是基于信仰的教条。也许你确信辞职会是一场灾难，或者确信没有上帝，或者确信上大学很重要，或者确信你在假期中总是过得很愉快，或者确信当你在小组聚会中拿出吉他时大家都喜欢它—但如果它没有来自事实的支持，它最多是一个假设，且有可能是一个完全错误的教条。

谦逊顾名思义就是一个起点—它让你从这里开始踏上旅程。确定性的傲慢既是一个起点也是一个终点—不需要旅程。这就是为什么我们以“我什么都不知道 ”开始是如此重要。那是我们知道我们在实验室里的时候。

2. 其他人也什么都不知道

当你长大后，你往往会被告知世界是这样的，你的生活就是在这个世界里过日子。尽量不要过多地敲打墙壁。试着有一个美好的家庭生活，有乐趣，存一点钱。那是一个非常有限的生活。一旦你发现一个简单的事实，生活可以更宽广。而这就是。你周围所有你称之为生活的东西都是由那些并不比你聪明的人编造出来的。而你可以改变它，你可以影响它，你可以建立你自己的东西，让其他人可以使用。一旦你学会了这一点，你就不会再像以前那样了。 —— 乔布斯

这是乔布斯的说法，“你可能什么都不知道。但没有人知道狗屎。如果皇帝在你眼里是裸体的，而其他人都说他有衣服，那就相信你的眼睛，因为其他人不知道你不知道的事情。”。

这是一个容易理解的信息，一个更难相信的信息，一个更难行动的信息。

不尊重社会与我们长大后所受的教育完全背道而驰—但如果你只看你的眼睛和经验所告诉你的，它就非常合理。

周围有很多线索告诉我们，传统智慧什么都不知道。传统智慧崇拜现状，总是假设一切都有很好的理由，而历史就是一个长长的记录，每当有人来改变事物时，现状的教条就会一次次被证明是错误的。

如果你睁开眼睛，在你自己的生活中还有其他的线索，你所生活的社会是没有什么好怕的。所有你了解到一个公司内部的真实情况，并发现它是完全无组织和糟糕的运作。所有身居高位的人似乎都不能把他们的个人生活安排好。

第一条认知是关于粉碎傲慢的保护壳，以奠定谦卑的起点。第二条是关于自信—通过一条建立在第一原则上而不是类比上的途径从这种谦卑中走出来的自信。这是一种自信，它说：“我可能知道的不多，但其他人也不知道，所以我不妨成为地球上最有知识的人。”

3. 你的人生是一场游戏

科学的方法是通过测试假设来学习，而假设的建立是为了被推翻，这意味着科学家通过失败学习。失败是他们过程中的一个关键部分。

许多最有影响力的人似乎把世界当作实验室，把他们的生活当作实验课—这是成功的最佳途径。

但对我们大多数人来说，我们就是做不到。是什么阻止了我们？我认为主要有两点错误认知

错误认知 1: 错位的恐惧

人类被设定为非常认真地对待恐惧，而进化论认为让我们评估和重新评估我们内心的每个恐惧是没有效率的。它转而采用了“安全比遗憾好”的哲学—即如果某种恐惧有可能是基于真正的危险，就把它作为真正的恐惧，即使你的恐惧没有根据，也要把它留在身边，以防万一。安全总比遗憾好。

所有这些恐惧的目的是为了让我们保护自己免受危险。我们的问题是，就进化论而言，危险=损害你的基因继续发展的机会的东西，即危险=不交配或死亡或你的孩子死亡，仅此而已。

因此，我们对各种形状和大小的恐惧的痴迷可能在5万年前的埃塞俄比亚为我们提供了很好的服务，但它毁了我们今天的生活。

因为它不仅将我们的恐惧普遍提高到“该死的，我们打猎失败了，现在孩子们这个冬天都要饿死了”的水平，尽管我们生活在一个“哦，不，我被解雇了，现在我必须在20度的理想温度下，用一个羽毛枕头在我父母家睡两个月”的世界，而且它还使我们对错误的事情感到害怕。我们更害怕公开演讲而不是在高速公路上发短信，更害怕在酒吧里接近一个有吸引力的陌生人而不是嫁给一个错误的人，更害怕无法负担和我们的朋友一样的生活方式而不是在毫无意义的事业中度过50年。

错误认知 2: 错位的自我定位

在社会上，当你在价值观方面、时尚方面、宗教方面、事业方面做出一些尝试时，你就给自己打上了烙印。由于人们喜欢把人简化，以便在他们自己的头脑中理解事物，你周围的群体通过把你放在一个明确标记的、过度简化的盒子里来标识你。

这让改变变得非常痛苦。改变令人厌恶，如果身份需要随之变化。而其他人也不会让事情变得简单。盲目的群体成员不喜欢其他成员的改变—这使他们感到困惑，迫使他们重新调整头脑中的信息，并威胁到群体的简单确定性。因此，进化的尝试往往会遭到反对、嘲弄或愤怒。

当你很难改变的时候，你就会依恋你现在的身份和你现在做的事情—依恋到模糊了科学家和实验之间的区别，你忘记了它们是两种不同的东西。

我们谈到了为什么科学家欢迎关于他们实验的负面反馈。但是，当你是实验本身的时候，负面反馈并不是一个新的、有帮助的信息，而是一种侮辱。而且它很伤人。它让你生气。而且，由于改变感觉是不可能的，无论如何，反馈也没有什么好处—这就像给父母就他们一个月大的孩子的名字提供负面反馈。

我们讨论了为什么科学家期望他们的大量实验会失败。但是，当你和实验是一体的时候，承担一个新的目标不仅是身份的改变，而且是将你的身份置于危险之中。如果实验失败了，你就失败了。你是一个永远的失败者。

我和马斯克谈到了美国，以及先辈们在建立这个国家时按照第一原则进行推理的方式。他说，他认为他们之所以能这样做，是因为他们有一块新的石板可以使用。那个时代的欧洲国家要想做这样的事情会困难得多—因为，正如他告诉我的，他们“被困在自己的历史中”。

我听到马斯克用这句话来描述今天的大型汽车和航空航天公司。他认为特斯拉和 SpaceX s就像18世纪末的美国—新鲜的新实验室，准备进行实验—但当他看向他们行业的其他公司时，他看到的是无法从一种干净的心态来推动他们的战略。马斯克在提到航空航天业时说：“有一种反对承担风险的巨大偏见。每个人都在努力优化而减少自己的风险”。

困在你的历史中意味着你不知道如何改变，你已经忘记了如何创新，你被困在世界给你的身份框中。

正是因为这个原因，史蒂夫-乔布斯回顾了他在1986年被苹果公司解雇的情况，认为这是一种变相的祝福。他说：“被苹果公司解雇是发生在我身上最好的事情。成功的沉重感被重新成为初学者的轻松感所取代。它使我得以进入我生命中最有创造力的时期之一。” 被解雇使乔布斯从他自己的历史枷锁中“解放”出来。

这些都是我认为世界上许多最能干的人被困在生活中的原因。

这最后一个顿悟的挑战是以某种方式找出一种方法来失去对你自己恐惧的尊重。这种尊重存在于我们的基因中，而削弱这种尊重的唯一方法是藐视它，并在最终没有坏事发生时看到“你所感受到的大部分恐惧只是烟雾弹“。在你的舒适区之外做一些事，如果结果并没有想象中那么可怕，那这会是一个令人难以置信得强大的经验，一个改变你的经验—每次你有这样的经验，它就会削去你对你的大脑根深蒂固的、非理性的恐惧的尊重。

因为最具创造性的人物和其他人最主要的认知差异在于前者知道：现实生活和《侠盗猎车手》实际上并没有什么不同。《侠盗猎车手》是一个有趣的视频游戏，因为它是一个虚假的世界，在那里你可以毫无顾忌地做一些事情。在高速公路上以200英里/小时的速度行驶。闯入一栋大楼。用你的车轧死一个人。在《GTA》中一切都没有限制。

与GTA不同，在现实生活中，有法律，有监狱。但这就是最大的差异。如果有人给你一个完美的模拟当今世界的游戏，并告诉你这一切都是假的，没有实际的后果—唯一的规则是你不能违反法律或伤害任何人，而且你仍然必须确保支持你和你的家人的基本需求—你会怎么做？我的猜测是，大多数人会做各种他们在现实生活中很想做但不敢尝试的事情，他们最终会很快在模拟中获得一个比他们目前的现实生活更成功、更真实的生活。消除恐惧和对身份或他人意见的担忧，就会把这个人推入实际上并不危险的实验室，让他们在舒适区之外的所有令人振奋的地方蹦蹦跳跳，他们的生活就会腾飞。这就是非理性的恐惧阻碍我们的生活。

当我看到我们这个时代令人惊叹的人物时，很清楚的是，他们或多或少地把现实生活当成了《侠盗猎车手》。而这样做给了他们超能力。这就是我认为史蒂夫-乔布斯所说的“Stay hungry. Stay foolish”。

而这正是第三个顿悟的内容：无畏。

译：本地优先软件 Local-first software

Sat, 20 Aug 2022 22:00:02 GMT

You own your data, in spite of the cloud.

本文译自 Ink&Switch 发表于 2019 年 4 月的《Local-first software》
This article is the translation of Local-first software written by Ink&Switch in April 2019
原文作者
Martin Kleppmann
Adam Wiggins
Peter van Hardenberg
Mark McGranaghan

Google Docs 和 Trello 这样的云应用很受欢迎，因为它们能够实现与同事的实时协作，而且它们使我们能够轻松地从所有的设备上访问我们的工作。然而，因为数据集中在服务器上存储，云应用也从用户手中夺走了所有权和代理权。如果一个服务关闭了，软件就会停止运作，用该软件创建的数据也会丢失。

在这篇文章中，我们提出了 “本地优先软件” : 它是一套兼顾了协作和用户对数据的所有权的软件原则。本地优先的愿景包括离线可用和多端协作的能力，同时也改善数据的安全性、隐私性、长期可用性和用户对数据的控制能力。

我们调查了现有的数据存储和共享方法，从电子邮件附件到 Web Apps，再到由 Firebase 驱动的移动应用。我们分析了他们各自的特性。我们研究了无冲突复制数据类型（CRDTs）：这种数据结构从本质上就支持多用户，同时也是本地化的和保证私密性的。CRDTs 有可能成为实现本地优先的软件的基础技术。

本文分享了几年来我们在 Ink & Switch 开发本地优先软件原型的一些发现。这些实验检验了 CRDTs 在实践中的可行性，并探讨了这种新数据模型的 UI 上的挑战。最后，我们分别针对研究员、应用开发者和创业者提出了向本地优先软件发展的行动建议。

这篇文章还以 PDF 格式发表在 Onward! 2019 年会议。请用以下方式引用

Martin Kleppmann, Adam Wiggins, Peter van Hardenberg, and Mark McGranaghan. Local-first software: you own your data, in spite of the cloud. 2019 ACM SIGPLAN International Symposium on New Ideas, New Paradigms, and Reflections on Programming and Software (Onward!), October 2019, pages 154–178. doi:10.1145/3359591.3359737

动机：协作和所属权
本地优先软件的七个愿景
现有的数据存储和共享模式
- 应用程序架构如何影响用户体验
- 构建 Apps 的开发者基础设施
迈向更美好的未来
- 以 CRDTs 为基础性技术
Ink \& Switch 原型
你可以如何提供帮助
总结
致谢

动机：协作和所属权

如今我们可以极为轻松地进行在线协作。我们使用 Google Docs 来协作处理文档、电子表格和演示文稿；在 Figma 中，我们可以多人进行用户界面设计；我们使用 Slack 与同事沟通；我们在 Trello 中跟踪任务。我们依赖这些在线服务来完成笔记、计划项目、保存联系人，以及各类商业用途。

我们将这些服务称为 “云应用(cloud apps)”，但你也可以称它们为 “SaaS” 或 “基于网络的应用程序”。它们的共同点是，我们通常通过网络浏览器或移动应用程序访问它们，并且它们将数据存储在服务器上。

与前几代软件相比，今天的云应用提供了很大的好处：无缝协作，并能从任何设备上访问数据。随着我们的生活和工作越来越多地通过这些云应用运行，它们对我们变得越来越重要。我们在使用这些应用程序中投入的时间越多，其中的数据对我们来说就越有价值。

然而通过与很多从事创造性工作的专业人士进行了交流，我们也了解到了云应用的缺点。

当你在制作某样东西时投入了大量的创造性精力和努力，你往往会对它有很深的情感依恋。如果你从事创造性工作，这体会或许不陌生。(当我们说“创造性工作”时，我们指的不仅仅是视觉艺术、音乐、或诗歌—许多其他活动也都是创造性的，如：解释某种技术、实现复杂的算法、设计用户界面、或思考如何带领团队实现目标）。

在进行创造性工作的过程中，你通常会产生文件和数据：文档、演示文稿、电子表格、代码、笔记、图纸等等。你会希望保留这些数据：供将来参考和激发灵感，将其纳入作品集，或者仅仅是存档，因为你为它感到骄傲。这种「拥有」的感受是很重要的，因为创造性的表达是非常个人化的东西。

不幸的是，云应用在这方面是有问题的。虽然他们让你在任何地方访问你的数据，但所有的数据访问都必须通过服务器，而且你只能做服务器让你做的事情。从某种意义上说，你对这些数据没有完全的所有权—而云供应商拥有。所谓云，只是别人的电脑。

There is no cloud, it’s just someone else’s computer.

我们使用的 “所有权”一词不是指知识产权法和版权，而是指创造者对其数据的感知关系。我们在后面的章节中讨论这个概念。

当数据被存储在 “别人的电脑”上时，它就对该数据有一定的控制能力。云应用是作为一种服务提供的；如果服务不可用，你就不能使用该软件，你也不能再访问你用该软件创建的数据。如果服务关闭，即使你可能能够导出你的数据，但如果没有服务器，你通常没有办法继续运行这个软件。因此，你只能任由提供服务的公司摆布。

在网络应用出现之前，我们有一些我们可以称之为 “老式”的应用：在你的本地计算机上运行的程序，在本地磁盘上读写文件。今天我们仍然在使用这种类型的应用程序：文本编辑器和集成开发环境、Git 和其他版本控制系统，以及许多专业软件，如图形应用程序或 CAD 软件都属于这种类型。

我们在本文中谈论的软件是用于创建文档或文件（如文本、图形、电子表格、CAD 图纸或音乐），或个人数据存储库（如笔记、日历、待办事项列表或密码管理器）的应用程序。我们不是在谈论实施像银行服务、电子商务、社交网络、共享汽车或类似的服务，这些都是集中式系统能很好提供的。

在老式的应用程序中，数据存放在你的本地磁盘上的文件中，所以你对这些数据有完全的代理权和所有权：你可以做任何你喜欢的事情，包括长期存档，做备份，使用其他程序操作文件，或在你不再需要它们时删除文件。你不需要任何人的许可来访问你的文件，因为它们是你的。你不必依赖由另一家公司运营的服务器。

总而言之：云计算给了我们协作，但老式的应用程序给了我们所有权。难道我们不能同时拥有这两个世界的优点吗？

我们既希望有云应用提供的方便的跨设备访问和实时协作，也希望有 “老式”软件体现的对你自己数据的拥有权。

本地优先软件的七个愿景

我们相信，数据所有权和实时协作并不相悖。我们有可能创建具有云应用所有优点的软件，同时也允许你保留对你创建的数据、文档和文件的完全所有权。

我们把这种类型的软件称为本地优先软件，因为它优先使用本地存储（你的电脑中内置的磁盘）和本地网络（如你的家庭 WiFi）而不是远程数据中心的服务器。

在云计算应用程序中，服务器上的数据被视为数据的主要的、权威的副本；如果客户端有一份数据的副本，它只是一个从属于服务器的缓冲区。任何数据修改都必须发送到服务器上，否则就 “没有发生”。在本地优先的应用程序中，我们交换了这些角色：我们把你本地设备上的数据副本—你的笔记本电脑、平板电脑或手机—视为主要副本。服务器仍然存在，但它们持有你的数据的次要副本，以协助从多个设备访问。正如我们将看到的，这种观点的变化具有深远的影响。

以下是我们希望在本地优先的软件中实现的七个愿景。

1. 即刻加载：数据触手可及

今天的许多软件感觉比前几代软件慢。尽管 CPU 的速度越来越快，但在用户的一些输入（如点击一个按钮，或按下一个键）和相应的结果出现在显示屏上之间，往往有可察觉的延迟。在此前的工作中，我们测量了现代软件的性能并分析了这些延迟发生的原因。

全球不同地点的 AWS 数据中心之间的服务器到服务器的往返时间。数据来源: Peter Bailis, Aaron Davidson, Alan Fekete, et al.: “Highly Available Transactions: Virtues and Limitations,” VLDB 2014.

对于云计算应用程序，由于数据的主要副本在服务器上，所有的数据修改和许多数据查询都需要往返于服务器。服务器很可能与你的居住地不在同一片大陆上，所以光速对软件的速度有限制。

用户界面可能试图通过将操作显示为已经完成来隐藏这一延迟，即使请求仍在进行中—这种模式被称为乐观的 UI (Optimistic UI) —但在请求完成之前，总是有可能会失败（例如，由于不稳定的互联网连接）。因此，乐观的 UI 有时仍然会在错误发生时暴露出网络往返的延迟。

本地优先的软件则不同：因为它把数据的主要副本保存在本地设备上，所以用户永远不需要等待对服务器的请求完成。所有的操作都可以通过读写本地磁盘上的文件来处理，与其他设备的数据同步在后台悄然发生。

虽然这本身并不能保证软件的速度，但我们期望本地优先的软件有可能对用户的输入做出近乎即时的反应，在你等待的时候永远不需要向你展示一个“加载中”的状态，让你的数据触手可及。

2. 多端同步

如今用户常常使用多种电子设备来完成他们的工作，而现代应用程序必须支持这种工作流程。例如，用户可能会在旅途中使用智能手机捕捉想法，在平板电脑上组织和思考这些想法，然后在笔记本电脑上把结果打成文档。

这意味着，虽然本地优先的应用程序将其数据保存在每个设备的本地存储中，但这些数据也有必要在用户进行工作的所有设备上进行同步。目前存在多种数据同步技术，我们在后面的章节中详细讨论。

大多数跨设备同步服务也在服务器上存储数据的副本，这为数据提供了一个方便的异地备份。只要每个文件一次只被一个人编辑，这些解决方案的效果就很好。如果几个人同时编辑同一个文件，可能会产生冲突，这一点我们将在协作部分讨论。

3. 网络只是一种可选项

个人移动设备所处的网络环境经常发生变化：不可靠的咖啡馆 WiFi，在飞机上或火车上穿过隧道时，在电梯或停车场。在发展中国家或农村地区，互联网接入的基础设施有时是分布不均的。在国际旅行时，由于漫游的费用，许多移动用户禁用手机数据。总的来说，有很多对离线应用程序的需求，例如或需要在野外创作的研究人员或者记者。

“老式的”应用程序在没有互联网连接的情况下可以正常工作，但云应用通常在离线时无法工作。几年来，“离线优先”运动一直在鼓励网络和移动应用的开发者改善对离线的支持，但在实践中，很难对云应用的离线支持进行改造，因为为以服务器为中心的模式设计的工具和库不容易适应用户在离线时进行编辑的情况。

尽管有可能使 Web App 在离线状态下工作，但用户可能很难知道是否 App 所有必要的代码和数据已经下载好了

由于本地优先的应用程序将其数据的主要副本存储在每个设备的本地文件系统中，用户即使是在离线时也可以随时读取和写入这些数据。当网络连接可用时，它再与其他设备同步。数据同步不一定要通过互联网：本地优先的应用程序也可以使用蓝牙或本地 WiFi 将数据同步到附近的设备。

此外，为了提供良好的离线支持，软件最好以本地安装的可执行文件的形式在设备上运行，而不是网络浏览器中的一个标签。对于移动应用程序来说，在使用前下载并安装整个应用程序已经是一种标准。

4. 无缝协作

协作通常要求多人修改同一份文件或或文档。然而，在老式的软件中，几个人同时在同一份文件上工作常常产生冲突。在代码等文本文件中，解决冲突是枯燥且恼人的，而对于电子表格或图形文件等复杂的文件格式，这项任务很快就变得非常困难甚至不可能完成。因此，协作者可能要事先约定谁来编辑份文件，而且每次只有一个人可以进行修改。

Dropbox 上的冲突编辑，用户需要自行手动合并冲突

Evernote 中，如果笔记被同时修改，那么它就会被移动到冲突修改的笔记中，并且没有支持用户解决冲突的工具

在 Git 和其他版本控制系统上，多个人在不通过 commit 上并行修改同一份文件。合并这些改动常常导致“合并冲突”，需要通过专门的工具来解决。这些工具主要是为面向行的文本文件提供的，例如源代码。对于其他类型的文件格式的支持很弱

另一方面，Google Docs 等云计算应用大大简化了协作，允许多个用户同时编辑一份文件，而不必通过电子邮件来回发送文件，也不必担心冲突。用户已开始期待更多应用支持无缝实时协作。

在本地优先的应用程序中，我们的理想是支持与当今最好的云应用一样的实时协作，甚至更好。实现这一目标是实现本地优先软件的最大挑战之一，但我们相信这是可能的：在后面的章节中，我们将讨论在本地优先环境下实现实时协作的技术。

此外，我们期望本地优先的应用程序可以支持各种协作的工作流程。除了让几个人实时协作编辑，有时提供修改建议的模式也是很有价值的。这种模式中由一个人提出修改建议，让其他人审查并有选择性地应用修改。Google Docs 的建议模式和 GitHub 的 Pull Request 就支持这种工作流。

在 Google Docs 中，协作者可以通过直接编辑文档或者他们也可以提供修改建议，之后可以由文档拥有者来决定是否采用这些建议

GitHub 上的协作工作流程是基于 Pull Request 的。一个用户可以在多个 Commits 中修改多个源文件，并将其作为 Pull Request 提交给一个项目。其他用户可以审查和修改这个 Pull Request

5. 长期可用

数据所有权的一个重要方面是，你可以在未来很长一段时间内继续访问这些数据。当你用本地优先的软件做一些工作时，你的工作应该可以继续无限期地被访问，甚至在生产该软件的公司消失之后。

泥板上的楔形文字，约公元前 3000 年。图片来自 Wikimedia Commons

“老式”的应用程序是永久可用的，只要你有对应数据和一些运行软件的方法，即使软件作者破产了，你也可以继续运行该软件。即使操作系统和它所运行的计算机已经过时，你仍然可以在虚拟机或模拟器中运行该软件。存储介质迭代更新了，你也可以把你的文件复制到新的存储介质上，继续访问它们。

互联网档案馆收集了一些历史软件，可以在现代网络浏览器中使用模拟器运行；英国 Amiga 委员会的爱好者们分享了运行历史软件的技巧。

另一方面，云应用依赖于服务的可用性：如果服务不可用，你就不能使用该软件，你也不能再访问你用该软件创建的数据。这意味着你在打赌「软件的创建者将长期维护它」—至少在你关心数据的时候。

虽然谷歌似乎没有很快关闭谷歌文档的巨大危险，但受欢迎的产品有时确实会被关闭或丢失数据，所以我们知道要小心。而且，即使是寿命长的软件，也存在价格或功能以你不喜欢的方式改变的风险，而对于云应用，继续使用旧版本不是一种选择—无论你是否喜欢，你都会被升级。

我们不可思议的旅程是一个博客，它记录了创业公司产品在被收购后被关闭的情况。

本地优先软件有更长的寿命，因为你的数据以及读取和修改你的数据所需的软件，都是在你的电脑上本地存储的。这一点很重要，不仅是为了你自己，也是为了未来的历史学家，他们会想要阅读我们今天创造的文件。如果我们的数据不能长期保存，我们就有可能创造出文特-瑟夫所说的 “数字黑暗时代”。

我们以前写过关于网页的长期存档的文章。关于长期数据保存的有趣讨论，请看 Long Tien Nguyen 和 Alan Kay 在 Onward！2015 上发表的论文《2015 年的楔形文字》

一些文件格式（如纯文本、JPEG 和 PDF）是如此的普遍，以至于它们可能在未来几个世纪内都可以被阅读。美国国会图书馆也推荐 XML、JSON 或 SQLite 作为数据集的存档格式。然而，为了读取不太常见的文件格式并保留交互，你需要能够运行原始软件（如果有必要，在虚拟机或模拟器中）。本地优先软件可以实现这一点。

6. 安全性和隐私性

云应用架构的一个问题是，它们将所有用户的所有数据存储在一个集中的数据库中。这种大量的数据收集对攻击者来说是充满吸引力的目标：一个流氓雇员，或一个获得公司服务器访问权的黑客，可以阅读和篡改你的所有数据。令人恐惧的是这样的安全漏洞很常见。我们不幸地任由云应用供应商的摆布。

虽然谷歌有世界级的安全团队，但可悲的现实是，大多数公司都没有。虽然谷歌善于保护你的数据免受外部攻击，但公司内部却可以自由地以各种方式使用你的数据，例如将你的数据输入其机器学习系统。

引用 Google Drive 服务条款的内容。“我们的自动化系统分析你的内容，为你提供个人相关的产品功能，如定制的搜索结果，以及垃圾邮件和恶意软件检测。”

也许你觉得你的数据不会引起任何攻击者的兴趣。然而，对于许多职业来说，处理敏感数据是他们工作的重要部分。例如，医疗专业人士处理敏感的病人数据，调查记者处理消息来源的机密信息，政府和外交代表进行敏感的谈判，等等。由于法规遵从和保密义务，这些专业人士中的许多人不能使用云应用。

另一方面，本地优先的应用程序，在核心部分内置了更好的隐私和安全。你的本地设备只存储你自己的数据，避免了集中式的云数据库保存着所有人的数据。本地优先的应用程序可以使用端对端加密，这样，任何存储你的文件副本的服务器都只持有他们无法读取的加密数据。

像 iMessage、WhatsApp 和 Signal 这样的现代信息应用已经使用了端对端加密，Keybase 提供了加密的文件共享和信息传递，Tarsnap 也采取了这种方法进行备份。我们希望看到这种趋势也能扩展到其他类型的软件。

7. 你保留最终的所有权和控制权

对于云应用，服务提供商有权力限制用户的访问：在 2017 年 10 月，几个谷歌文档的用户被锁定在他们的文件之外，因为某个自动系统错误地将这些文件标记为违规。在本地优先的应用程序中，数据的所有权归属于用户。

在本文中提及的“所有权”并不是指知识产权的法律意义上的所有权。例如，文字处理工具无法知晓谁拥有所编辑文本的版权。而我们指的是对数据的控制的意义上的所有权：你应该能够以任何方式复制和修改数据，写下任何想法，没有公司应该限制你的行为。

根据《欧洲人权公约》，你的思想和意见自由是无条件的—国家永远不得干涉，因为它只属于你自己—而言论自由（包括言论自由）则可以在某些方面受到限制，因为它影响到其他人。像社交网络这样的通信服务传达的是表达，但创作人的原始笔记和未发表的作品是发展思想和意见的一种方式，因此值得无条件地保护。

在云应用中，访问和修改你自己的数据的方式受到服务提供商的 API、用户界面和服务条款的限制。在本地优先的软件中，构成你的数据的所有字节都存储在你自己的设备上，所以你可以自由地以任意的方式处理这些数据。

伴随数据所有权而来的是相对应的责任：采用备份或者其他防止数据丢失的措施，防止勒索软件，以及组织和管理文件。对专业用户来说，我们认为用更多的责任来换取更多的所有权是可取的(如本文开头中所介绍的)。例如重要的个人创作，如博士论文或电影的原始镜头。对于这些数据，你可能愿意承担存储和备份的责任，以确保你的数据是安全的，完全在你的控制之下。

在我们看来，保持对数据的控制和所有权并不意味着软件必须是开放源代码的。尽管修改软件的自由有价值，但只要不人为地限制用户对其文件的操作，商业和闭源软件是可以满足本地优先的理想的。这种人为限制的例子有：禁用打印等操作的 PDF 文件，干扰复制粘贴的电子书阅读器，以及媒体文件的 DRM。

现有的数据存储和共享模式

我们相信专业和创造性的用户应该得到能够实现本地优先目标的软件，帮助他们进行无缝协作，同时也允许他们保留对工作成果的完全所有权。如果我们能在用户用来做最重要工作的软件中提供这些品质，我们就能帮助他们更好地完成工作，并有可能为许多人的职业生活带来重大改变。

然而，虽然本地优先软件的理想可能会引起你的共鸣，但你可能仍想知道它们的可行性。它们是否只是乌托邦式的幻想？

在下文中，我们将讨论在实践中实现本地优先的软件意味着什么。我们考察了大量的现有技术，并对它们满足本地优先理想的程度进行了分解。在下面的表格中，✓ 表示技术符合理想，-表示部分符合理想，而 ✗ 表示不符合理想。

正如我们将看到的，许多技术满足了部分目标，但没有一项技术能够满足所有目标。最后，我们将研究一种来自计算机科学研究前沿的技术，它可能是未来实现本地优先软件的重要基础设施。

应用程序架构如何影响用户体验

让我们先从最终用户的角度来审视软件，并分解不同的软件架构在多大程度上满足了本地优先软件的七个目标。在下一节中，我们将比较软件工程师用来构建应用程序的存储技术和 API。

文件和邮件附件

	1. 快	2. 多设备	3. 离线	4. 协作	5. 长期可用性	6. 隐私	7. 控制权
文件和邮件附件	✓	-	✓	✗	✓	-	✓

从我们的七个目标来看，传统的文件有许多理想的特性：它们可以被离线查看和编辑，它们给了用户完全的控制权，它们可以随时被备份和长期保存。依靠本地文件的软件也有可能变得非常快。

然而，从多个设备访问文件是比较棘手的。有多种方式在设备间传输文件：

通过电子邮件来回发送
来回传递 U 盘
通过分布式文件系统，如 NAS 服务器、NFS、FTP 或 rsync
使用云文件存储服务，如 Dropbox、Google Drive 或 OneDrive（见后面章节）
使用版本控制系统，如 Git（见后面的章节）

其中，电子邮件附件可能是最常见的共享机制，特别是在那些不是技术专家的用户中。附件很容易理解和信任。一旦你有了一份文件的副本，除非用户主动修改，否则它就不会变：如果你在六个月后查看一封电子邮件，附件仍然以其原始形式存在。与网络应用不同，附件不需要任何额外的登录过程就可以打开。

电子邮件附件最薄弱的地方是协作。一般来说，一次只能有一个人对文件进行修改，否则就需要进行困难的手动合并。文件的版本很快就会变得混乱，往返发送的协作文件常导致文件名变成奇怪的样子： 预算草案（小明版）绝对最终版（2）.xls。

尽管如此，对于那些想要融入本地优先理念的应用程序来说，一个好的起点是提供导出功能，生成被广泛支持的文件格式（如纯文本、PDF、PNG 或 JPEG），并允许它被分享，例如通过电子邮件附件、Slack 或 WhatsApp。

网页应用：Google Docs, Trello, Figma, Pinterest, etc.

	1. 快	2. 多设备	3. 离线	4. 协作	5. 长期可用性	6. 隐私	7. 控制权
Google Docs	-	✓	-	✓	-	✗	-
Trello	-	✓	-	✓	-	✗	✗
Pinterest	✗	✓	✗	✓	✗	✗	✗

在光谱的另一端是纯 Web App，此时用户的本地软件（浏览器或移动应用）是瘦客户端，数据存储在服务器上。服务器通常使用一个大规模的数据库，其中数百万用户的数据都混合在一个巨大的集合中。

Web 应用程序已经设定了实时协作的标准。作为用户，你可以相信，当你在任何设备上打开文件时，你看到的是最新的内容，用的是最新的版本。这对团队工作来说是非常有用的，以至于这些应用程序已经成为主导。甚至像微软 Office 这样传统的纯本地软件也在向云服务过渡，截至 2017 年，Office 365 已经让本地安装的 Office 黯然失色。

随着远程工作和分布式团队的兴起，实时协作的生产力工具正变得更加重要。团队视频通话中的十个用户可以调出同一个 Trello 板，每个人在自己的电脑上进行编辑，同时看到其他用户正在做什么。

这样做的负面是所有权和控制权的完全丧失：服务器上的数据才是最重要的，而你的客户端设备上的任何数据都是不重要的，它只是缓存。大多数网络应用程序对离线支持很差或者根本不支持：如果你的网络出现哪怕是片刻的故障，你的工作就会被锁定。

如果 Google Docs 检测到它是离线的，它就禁止文档编辑

一些最好的网络应用程序使用 JavaScript 隐藏了服务器通信的延迟，并试图提供有限的离线支持（例如，Google Docs 的离线插件）。然而，这些努力似乎都是为了适应从根本上以与服务器同步互动为中心的应用架构。用户在尝试离线工作时报告了不同的结果。

Google Docs 离线插件的负面评价

一些网络应用，例如 Milanote 和 Figma，提供了可安装的桌面客户端，基本上是重新包装的网络浏览器。如果你试图使用这些客户端访问你的工作，而你的网络是断断续续的，当供应商的服务器遇到故障时，或者在供应商被收购并关闭后，很明显，你的工作从来就不是真正属于你的。

Figma 桌面端离线时

网盘：Dropbox, Google Drive, Box, OneDrive, etc.

	1. 快	2. 多设备	3. 离线	4. 协作	5. 长期可用性	6. 隐私	7. 控制权
Dropbox	✓	-	-	✗	✓	-	✓

基于云的文件同步产品，如 Dropbox、Google Drive、Box 或 OneDrive，使文件在多个设备上可用。在桌面操作系统（Windows、Linux、Mac OS）上，这些工具通过观察本地文件系统上的指定文件夹来工作。你的电脑上的任何软件都可以读写这个文件夹中的文件，每当一台电脑上的文件被改变，它就会自动复制到你所有的其他电脑上。

由于这些工具使用本地文件系统，它们有许多吸引人的特性：对本地文件的访问是快速的，离线工作也没有问题（离线编辑的文件在下次有互联网连接的时候会被同步）。如果同步服务被关闭，你的文件仍然会在你的本地磁盘上保持无损，而且很容易切换到另一个同步服务。如果你的电脑硬盘出现故障，你只需安装应用程序并等待它同步，就可以恢复你的工作。这提供了良好的长期可用性和对数据的控制能力。

然而，在移动平台（iOS 和安卓）上，Dropbox 及其表亲使用了完全不同的模式。移动应用程序不同步整个文件夹—相反，它们是瘦客户端，每次从服务器上获取你的数据一个文件，而且默认情况下，它们不能脱机工作。有个 “离线可用”的选项，但你需要记住在离线之前调用它，它是笨拙的，而且只有在应用程序打开时才有效。Dropbox 的 API 也是非常以服务器为中心的。

Dropbox 移动端的用户的很多时间花在“加载中”的页面上，和桌面端即刻加载的体验大相径庭

文件同步产品的最弱点是缺乏实时协作：如果同一个文件在两个不同的设备上被编辑，其结果是需要手动合并的冲突，如前所述。这些工具可以同步任何格式的文件，这既是一个优点（与任何应用程序兼容），也是一个缺点（无法进行特定格式的合并）。

Git 和 GitHub

	1. 快	2. 多设备	3. 离线	4. 协作	5. 长期可用性	6. 隐私	7. 控制权
Git+GitHub	✓	-	✓	-	✓	-	✓

Git 和 GitHub 主要被软件工程师用来进行源代码的协作。它们也许是我们最接近真正的本地优先的软件包：与以服务器为中心的版本控制系统（如 [Subversion](https://subversion.apache.org/）相比，Git 可以完全脱机工作，它速度快，可以给用户完全的控制权，而且适合长期保存数据。之所以如此，是因为本地文件系统上的 Git 仓库是数据的主要副本，不从属于任何服务器。

我们在此着重介绍 Git/GitHub，作为最成功的例子，但这些经验也适用于其他分布式版本控制器，如 Mercurial 或 Darcs，以及其他仓库托管服务，如 GitLab 或 Bitbucket。原则上，没有仓库服务也可以进行协作，例如通过电子邮件发送补丁文件，但大多数 Git 用户都依赖 GitHub。

像 GitHub 这样的仓库托管服务可以实现围绕 Git 仓库的协作，从多个设备上访问数据，并提供一个备份和存档位置。目前对移动设备的支持还很薄弱，尽管 Working Copy 是一个很有前途的 iOS 版 Git 客户端。GitHub 存储的仓库是不加密的；如果需要更强的隐私保护，你可以运行自己的仓库服务器。

我们认为 Git 的模式为本地优先的软件指明了方向。然而，就目前而言，Git 有两个主要的弱点。

Git 在异步协作方面非常出色，尤其是使用 Pull Requests，它可以获取一组粗略的修改，并在合并到共享的主干分支之前对其进行讨论和修改。但 Git 并不具备实时、细粒度协作的能力，比如 Google Docs、Trello 和 Figma 等工具中出现的自动、即时合并。
Git 对代码和类似的基于行的文本文件进行了高度优化；其他文件格式则被视为二进制文件，无法进行有意义的编辑或合并。尽管 GitHub 努力显示和比较图像、散文和 CAD 文件，但非文本文件格式在 Git 中仍然是次要的。

有趣的是，大多数软件工程师都不愿意接受云版本的编辑器、IDE、运行时环境和构建工具。从理论上讲，我们一般会预期这个用户群体比其他类型的用户更早地接受新技术。但是，如果你问工程师为什么不使用 Cloud9 或 Repl.it 这样的云端编辑器，或 Colaboratory 这样的运行环境，答案通常包括“它太慢了”或“我不信任它”或“我希望我的代码在我的本地系统”。这些情绪似乎反映了一些与本地优先的软件相同的动机。如果我们作为开发者为自己和我们的工作想要这些东西，也许我们可以想象，其他类型的创造性的专业人士也会为他们自己的工作想要这些相同的特性。

构建 Apps 的开发者基础设施

现在我们已经通过本地优先的理念考察了一系列应用程序的用户体验，让我们把思维转换到应用程序开发者的角度。如果你正在创建应用程序，并希望为用户提供部分或全部本地优先的体验，你在数据存储和同步基础设施方面有哪些选择？

Web app (瘦客户端)

	1. 快	2. 多设备	3. 离线	4. 协作	5. 长期可用性	6. 隐私	7. 控制权
Web apps	✗	✓	✗	✓	✗	✗	✗

最纯粹的网络应用通常是在服务器上运行的 Rails、Django、PHP 或 Node.js 程序，将其数据存储在 SQL 或 NoSQL 数据库中，并通过 HTTPS 提供网页。所有的数据都在服务器上，而用户的网络浏览器只是一个瘦客户端。

这种架构有很多好处：零安装（只需访问一个 URL），用户无需管理，因为所有数据都由部署应用程序的工程和 DevOps 专业人员存储和管理在同一个地方。用户可以从他们所有的设备上访问该应用程序，同事们可以通过登录同一个应用程序轻松地进行合作。

Meteor 和 ShareDB 等 JavaScript 框架，以及 Pusher 和 Ably 等服务，使得在 WebSocket 等低级协议的基础上，更容易向 Web 应用添加实时协作功能。

另一方面，一个网络应用如果需要为每个用户的行动向服务器执行请求，那么速度就会很慢。在某些情况下，可以通过使用客户端的 JavaScript 来隐藏通讯时间，但如果用户的互联网连接不稳定，这些方法很快就会失效。

尽管有许多努力使网络浏览器对离线更友好（minifests、localStorage、service workers 和 Progressive Web Apps 等），但网络应用程序的架构从根本上说仍然是以服务器为中心的。离线支持在大多数网络应用中都是后续增加的能力，因而往往很脆弱。在许多网络浏览器中，如果用户清除了他们的 cookies，本地存储中的所有数据也会被删除；虽然这对缓存来说不是一个问题，但它使得浏览器的本地存储不适合存储任何长期的重要数据。

新闻网站《卫报》记录了他们如何使用 Service Worker 为用户建立离线体验。

依靠第三方网络应用在长期可用性、隐私和用户控制方面的得分也很低。如果网络应用是开源的，并且用户愿意自我托管他们自己的服务器实例，就有可能改善这些属性。然而，我们认为对于绝大多数用户来说自我托管并不是一个可行的选择；此外，大多数网络应用是闭源的，完全排除了这种选择。

总而言之，我们推测，由于平台的瘦客户端性质，网络应用将永远无法提供我们所寻找的所有本地优先的属性。选择建立一个 Web App，你就选择了属于你和你的公司，而不是属于你的用户的数据之路。

带本地存储的移动端应用（胖客户端）

	1. 快	2. 多设备	3. 离线	4. 协作	5. 长期可用性	6. 隐私	7. 控制权
Thick client	✓	-	✓	✗	-	✗	✗

iOS 和安卓的应用程序是本地安装的软件，在运行应用程序之前下载并安装整个应用程序二进制。然而，许多应用程序是瘦客户端，类似于 Web 应用程序，需要服务器才能运行（例如，Twitter、Yelp 或 Facebook）。如果没有可靠的互联网连接，这些应用程序会给你带来“加载中”、“出错了”和意外行为。

然而，还有一类移动应用程序更符合本地优先的理想。这些应用首先在本地设备上存储数据，使用 SQLite、Core Data 等持久层，或者只是普通文件。其中一些（如 Clue 或 Things）开始时是一个没有任何服务器的单用户应用程序，后来增加了云后端，作为一种在设备间同步或与其他用户共享数据的方式。

这些胖客户端应用程序的优点是快速和离线工作，因为服务器同步发生在后台。如果服务器被关闭，它们通常会继续工作。它们提供隐私和用户对数据控制的程度取决于相关的应用程序。

如果数据可能在多个设备上被修改或被多个协作用户修改，事情就会变得更加困难。移动应用的开发者通常是终端用户应用开发方面的专家，而不是分布式系统方面的专家。我们已经看到多个应用开发团队在编写他们自己的临时差异、合并和冲突解决算法，而由此产生的数据同步解决方案往往是不可靠的和脆弱的。下一节中讨论的更专业的存储后端可以提供帮助。

后端即服务 BaaS: Firebase, CloudKit, Realm

	1. 快	2. 多设备	3. 离线	4. 协作	5. 长期可用性	6. 隐私	7. 控制权
Firebase, CloudKit, Realm	-	✓	✓	-	✗	✗	✗

Firebase 是最成功的移动后盾即服务选项。它本质上是一个本地设备上的数据库与云数据库服务和两者之间的数据同步相结合。Firebase 允许在多个设备上共享数据，并支持离线使用。然而，作为一个专有的托管服务，我们在隐私和长期可用性上给它打了低分。

另一个受欢迎的后台即服务是 Parse，但它在 2017 年被 Facebook 收购，然后被关闭。依赖于它的应用程序被迫转移到其他后台服务，这强调了长期可用性的重要性。

Firebase 开发者提供了很好的体验：你可以在 Firebase 控制台以自由的方式查看、编辑和删除数据。但是，用户却没有类似的方式来访问、操作和管理他们的数据，使得用户几乎没有所有权和控制权。

Firebase 控制台: 对开发者非常友好，终端用户则无法使用

苹果的 CloudKit 为愿意将自己限制在 iOS 和 Mac 平台上的应用提供了类似 Firebase 的体验。它是一个具有同步功能的键值存储，具有良好的离线能力，而且它还有一个额外的好处，那就是内置于平台中（从而避免了用户必须创建一个账户并登录的笨拙）。对于独立的 iOS 开发者来说，这是一个很好的选择，像 Ulysses、Bear、Overcast 等工具都使用了它，效果不错。

通过一个复选框，Ulysses在用户的所有连接设备上同步工作，这得益于它对CloudKit的使用

这方面的另一个项目是 Realm。与 Core Data 相比，这个用于 iOS 的持久化库因其更简洁的 API 而获得欢迎。用于本地持久化的客户端库被称为 Realm 数据库，而相关的类似 Firebase 的后端服务被称为 Realm 对象服务器。值得注意的是，对象服务器是开源的，可自行托管，这减少了被锁定在一个可能有一天会消失的服务上的风险。

移动应用程序将设备上的数据作为主要副本（或至少比一次性缓存多），并使用 Firebase 或 iCloud 等同步服务，使我们在实现本地优先软件上有了很大的进展。

CouchDB

	1. 快	2. 多设备	3. 离线	4. 协作	5. 长期可用性	6. 隐私	7. 控制权
CouchDB	-	-	✓	✗	-	-	-

CouchDB 是一个数据库，因开创了多主机复制而备受关注：每台机器都有一个成熟的数据库副本，每个副本都可以独立地对数据进行修改，任何一对副本都可以相互同步，以交换最新的修改。CouchDB 是为在服务器上使用而设计的；Cloudant 提供了一个托管版本；PouchDB 和 Hoodie 是兄弟项目，使用相同的同步协议，但被设计为在终端用户设备上运行。

从哲学上讲，CouchDB 与本地优先原则密切相关，这一点在 CouchDB 的书中尤其明显，该书对分布式一致性、复制、变更通知和多版本并发控制等相关主题做了很好的介绍。

虽然 CouchDB/PouchDB 允许多个设备同时对数据库进行修改，但这些修改会导致冲突，需要由应用程序代码显式解决。这种冲突解决代码很难正确编写，这使得 CouchDB 对于具有非常精细的协作的应用来说是不切实际的，比如在 Google Docs 中，每个按键都有可能是一个单独的修改。

在实践中，CouchDB 模型还没有被广泛采用。这其中有各种原因：当每个用户需要一个单独的数据库时，存在可扩展性问题；在 iOS 和 Android 的本地应用程序中嵌入 JavaScript 客户端存在困难；冲突解决的问题；使用不常见的 MapReduce 模型来查询，等等。总而言之，虽然我们同意 CouchDB 背后的大部分理念，但我们认为在实践中，其实现并没有能够实现本地优先的愿景。

迈向更美好的未来

正如我们所表明的，现有的用于应用开发的数据层都不能完全满足本地优先的理想。因此，三年前，我们的实验室着手寻找一个能给出七个绿色复选标记的解决方案。

	1. 快	2. 多设备	3. 离线	4. 协作	5. 长期可用性	6. 隐私	7. 控制权
???	✓	✓	✓	✓	✓	✓	✓

我们已经发现了一些有前景的能满足本地优先理念的基础技术。最值得注意的是被称为无冲突复制数据类型（CRDTs）的分布式系统算法系列。

以 CRDTs 为基础性技术

CRDTs 是在 2011 年从学术计算机科学研究中出现的。它们是通用的数据结构，就像哈希图和列表一样，但它们的特殊之处在于，它们从一开始就支持多用户。

每个应用程序都需要一些数据结构来存储其文档状态。例如，如果你的应用程序是文本编辑器，其核心数据结构是构成文档的字符数组。如果你的应用程序是电子表格，数据结构是一个包含文本、数字或引用其他单元格的公式的单元格矩阵。如果它是矢量图形应用程序，数据结构是一个图形对象的树，如文本对象、矩形、线和其他形状。

如果你正在建立单用户应用程序，你将使用模型对象、哈希图、列表、记录/结构等在内存中维护这些数据结构。如果你正在建立协作的多用户应用程序，你可以把这些数据结构换成 CRDTs。

两个设备最初拥有相同的待办事项列表。在设备1上，使用 .push() 方法将一个新的项目添加到列表中，该方法将新的项目附加到列表的末尾。同时，第一个项目在设备2上被标记为完成。在两个设备进行通信后，CRDT自动合并状态，使两个变化都生效。

上图显示了一个由具有 JSON 数据模型的 CRDT 支持的待办事项列表应用程序的例子。即使是在离线状态下用户也可以在他们的本地设备上查看和修改应用程序的状态。CRDT 会跟踪所做的任何修改，并在有网络连接时在后台与其他设备同步这些修改。

如果状态在不同的设备上被同时修改，CRDT 会合并这些变更。例如，如果用户在不同的设备上同时向待办事项列表添加新的项目，合并后的状态会以一致的顺序包含所有添加的项目。对不同对象的并发变化也很容易被合并。CRDT 不能自动解决的唯一变化类型是当多个用户同时更新同一对象的同一属性时；在这种情况下，CRDT 会跟踪冲突的值，并让它由应用程序或用户来解决。

因此，CRDTs 与 Git 这样的版本控制系统有一些相似之处，只是它们操作的数据类型比文本更丰富。CRDTs 可以通过任何通信渠道（例如，通过服务器，通过点对点连接，通过本地设备之间的蓝牙，甚至在 U 盘上）同步其状态。CRDT 可以追踪每一次按键，从而实现 Google Docs 式的实时协作。你也可以汇集更多改动，并把它们作为一个批次发送给合作者，这就像是 Git 中的 Pull Request。因为数据结构是通用的，所以我们可以开发通用的工具来存储、通信和管理 CRDTs，使我们不必在每个应用中重新实现这些东西。

对于 CRDTs 的更多技术介绍，我们建议以下内容：

Alexei Baboulevitch’s Data Laced with History
Martin Kleppmann’s Convergence vs Consensus (slides)
Shapiro et al.’s comprehensive survey
Attiya et al.’s formal specification of collaborative text editing
Gomes et al.’s formal verification of CRDTs

Ink & Switch 已经开发了一个开源的 JavaScript CRDT 实现，名为 Automerge。它是基于我们早期对 JSON CRDTs 的研究。然后，我们将 Automerge 与 Dat 网络栈相结合，形成了 Hypermerge。我们并不声称这些库完全实现了本地优先的理想—仍然需要更多的工作。

然而，基于我们对它们的经验，我们相信 CRDTs 有可能成为新一代软件的基础。就像分组交换是互联网和网络的促成技术，或者电容式触摸屏是智能手机的促成技术一样，我们认为 CRDTs 可能是本地优先软件的基础技术。

Ink & Switch 原型

虽然学术研究在设计 CRDT 的算法和验证其理论正确性方面取得了很好的进展，但到目前为止，这些技术的工业应用相对较少。此外，大多数工业 CRDT 的使用都是在以服务器为中心的计算中，但我们相信这项技术在客户端的创造性工作的应用中有着巨大的潜力。

使用 CRDTs 的以服务器为中心的系统包括 Azure Cosmos DB、Redis、Riak、Weave Mesh、SoundCloud 的 Roshi 和 Facebook 的 OpenR。然而，我们对 CRDTs 在终端用户设备上的使用最感兴趣。

这也是我们的实验室开始进行一系列实验原型的动机，这些实验原型是建立在 CRDTs 上的具有协作性的本地优先应用。每个原型都以现有的创造性工作的应用程序（如 Trello、Figma 或 Milanote）为模型，提供终端用户体验。

这些实验探索了三个方面的问题。

技术的可行性。CRDTs 在多大程度上可以用于工作软件？我们需要什么来进行网络通信，或安装软件的开始？
用户体验。本地优先的软件使用起来感觉如何？我们能否在没有权威的集中式服务器的情况下获得类似 Google Docs 的无缝实时协作体验？对于源代码以外的数据类型，类似 Git 的、离线的、异步的协作体验如何？一般来说，没有集中式服务器，用户界面会有什么不同？
开发者体验。对于一个应用程序的开发者来说，使用基于 CRDT 的数据层与现有的存储层（如 SQL 数据库、文件系统或 Core Data）相比如何？分布式系统是否更难编写软件？我们是否需要模式和类型检查？开发人员将用什么来调试和反省他们应用程序的数据层？

我们使用 Electron、JavaScript 和 React 建立了三个原型。这给了我们快速开发能力，同时也给了我们的用户一个可以下载和安装的软件，我们发现这是本地优先的一个重要部分。

看板

Trellis 是一个以流行的 Trello 项目管理软件为模型的看板。

Trellis 提供了一个类似于 Trello 的本地优先软件的体验。右边的修改历史反映了所有在该文件中活跃的用户所做的修改

在这个项目中，我们尝试使用 WebRTC 作为网络通信层。

在用户体验方面，我们设计了一个初级的 “变更历史”，其灵感来自于 Git 和 Google Docs 的“查看新的变更”，允许用户查看他们看板上的操作。这包括回溯时间，查看文件的早期状态。

通过演示视频观看 Trellis 的操作，或者下载亲自尝试。

协作绘画

PixelPusher 是一个协作绘图程序，为 Javier Valencia 的 Pixel Art to CSS 带来类似 Figma 的实时体验。

多人实时同步地绘制。顶部的 URL 提供了与其他用户分享该文件的快速方法。右边的 “版本”面板显示了当前文档的所有分支。箭头按钮提供了分支之间的即时合并

在这个项目中，我们通过 Dat 项目的点对点库进行了网络通信的实验。

用户体验实验包括用于文档共享的 URL，受 Git 启发的可视化分支/合并工具，用红色突出冲突像素的冲突解决机制，以及通过用户绘制的头像的基本用户身份。

阅读完整的项目报告或下载亲自尝试。

多媒体画布

PushPin 是一个类似于 Miro 或 Milanote 的混合媒体画布工作空间。作为我们在 Automerge 上建立的第三个项目，它是这三个项目中实现得最充分的一个。我们的团队和外部测试用户的实际使用对底层数据层造成了更大的压力。

PushPin的画布混合了文本、图像、讨论线程和网络链接。用户通过工具栏上的头像看到对方，并使用URL栏在他们自己的文件之间导航

PushPin 探索了嵌套和连接的共享文档、CRDT 文档的各种渲染器、更先进的身份系统（包括用于共享的 “发件箱”模型），以及对共享短暂数据的支持，如选择高亮。

观看 PushPin 的演示视频或下载亲自尝试。

发现

我们开发 Trellis、PixelPusher 和 PushPin 三个原型的目的是为了评估技术可行性、用户体验以及本地优先软件和 CRDTs 的开发者经验。我们通过在开发团队（由五名成员组成）中定期使用这些原型，对我们开发软件的经验进行批判性的反思，以及对大约十名外部用户进行单独的可用性测试来测试这些原型。外部用户包括专业设计师、产品经理和软件工程师。我们没有遵正式的评估方法，而是采取了一种探索性的方法来发现我们原型的优点和缺点。

在这一节中，我们概述了我们从建立和使用这些原型中得到的教训。虽然这些发现有些主观，但我们相信它们包含了有价值的见解，因为我们比其他项目在基于 CRDT 的本地优先的成熟产品道路上走得更远。

CRDT 技术管用

从一开始，我们就对 Automerge 的可靠性感到惊喜。我们团队中的应用程序开发人员能够相对容易地整合该库，而且数据的自动合并几乎总是直接和无缝的。

离线工作的用户体验非常出色

下线，继续工作，然后重新连接，与同事同步，这一切都运行良好。当系统上的其他应用程序抛出错误（“离线！警告！“）并阻止用户工作时，本地优先的原型仍正常工作，不受网络状态的影响。与基于浏览器的系统不同，它永远不需要对应用程序是否能工作或数据是否在那里感到焦虑。这让用户对他们的工具和他们的工作有一种「拥有」的感受，正如我们所希望的那样。

结合 CRDT 与 Functional Reactive Programming (FRP) 后的开发体验不错

React 的 FRP 模型与 CRDTs 很适合。基于 CRDTs 的数据层意味着用户的文档同时获得来自本地用户的更新（例如，当他们在文本文档中输入时），但也来自网络（当其他用户和其他设备对文档进行更改时）。

因为 FRP 模型能可靠地同步「应用程序的可见状态」与「共享文档的底层状态」，开发者可以从同步视图状态和文档状态的繁琐工作中解脱出来。另外，通过确保对底层状态的所有改变都是通过一个单一的函数（一个 “reducer”）进行的，很容易确保所有相关的本地改变都被发送给其他用户。

这使应用开发者毫不费力地让所有原型都实现了实时协作和离线使用能力。这是显著的优势，因为它使应用程序开发人员能够专注于他们的应用程序，而不是解决数据分发的挑战。

冲突并不像我们担心的那样是一个重大问题

我们经常被问及自动合并的有效性，许多人认为需要特定的应用冲突解决机制。然而我们出乎意料地发现用户在与他人协作时，很少遇到编辑冲突，而通用的冲突解决机制则运作良好。这方面的原因是：

Automerge 在一个细粒度的层面上跟踪变化，并考虑到数据类型语义。例如，如果两个用户同时在一个数组的相同位置插入项目，Automerge 将这些变化结合起来，以确定的顺序定位这两个新项目。相比之下，像 Git 这样的文本版本控制系统会将这种情况视为需要手动解决的冲突。
用户对人类的协作有一种直观的感觉，并避免与他们的合作者产生冲突。例如，当用户合作编辑一篇文章时，他们可能会事先约定在一段时间内由谁来处理哪个部分，并避免同时修改同一个部分。
当不同的用户同时修改文档状态的不同部分时，Automerge 会干净利落地合并这些修改，没有任何困难。以看板应用为例，一个用户可以在一张卡片上发表评论，另一个用户可以将其移动到另一列，合并后的结果将反映这两个变化。只有当用户同时修改同一对象的相同属性时才会产生冲突：例如，如果两个用户同时改变画布上同一图像对象的位置。在这种情况下，如何解决它们往往是任意的，无论哪种方式都令人满意。

Automerge 的数据结构带有针对并发变化的默认解决策略。原则上，人们可能期望不同的应用需要不同的合并语义。然而，在我们开发的所有原型中，我们发现默认的合并语义已经足够了，而且到目前为止我们还没有发现任何需要定制语义的情况。我们假设情况普遍如此，我们希望未来的研究能够进一步检验这一假设。

将文件历史可视化是很重要的

在分布式协作系统中，另一个用户可以在任何时候向你传递任何数量的变化。与集中式系统不同的是，服务器对变化进行调解，本地优先的应用程序需要为这些问题找到自己的解决方案。如果没有合适的工具，就很难了解一个文件是如何形成的，文件有哪些版本，或者各部分都是由谁编写的。

在 Trellis 项目中，我们尝试使用了一个 “时间旅行”的界面，允许用户回到过去，查看合并后文件的早期状态，并在收到其他用户的修改时自动突出最近的修改内容。以线性方式穿越潜在的复杂的合并文件历史的能力有助于提供上下文，并可能成为理解协作的通用工具。

URL 是很好的分享机制

我们试验了许多与其他用户共享文件的机制，发现受网络启发的 URL 模型对用户和开发者来说最有意义。URL 可以被复制和粘贴，并通过电子邮件或聊天等交流渠道进行分享。秘密 URL 之外的文件的访问权限仍然是开放的研究问题。

Peer-to-peer 系统从未完全 “在线” 或 “离线”，并且很难推测数据如何流动

传统的集中式系统中通常有「在线」或「离线」的状态，这些状态由每个客户端根据与服务器保持稳定网络连接的能力来定义。服务器决定了真实数据是什么。

在去中心化的系统中，我们的数据可以有万花筒般的复杂性。任何用户都可能对他们所拥有、选择分享或接受的数据有不同的看法。例如，用户对一份文件的编辑可能在飞机上的笔记本电脑上；当飞机降落，电脑重新连接时，这些修改就会分发给其他用户。其他用户可能会选择接受所有、部分或不接受这些对他们版本的文件的修改。

文件的不同版本会导致混乱。就像 Git 仓库一样，特定的用户在 “主”分支中看到的东西是他们最后一次与其他用户交流时的功能。新来的修改可能会意外地修改你正在工作的文档的一部分，但手动合并每个用户的每一个修改是很乏味的。去中心化的文档使用户能够控制他们自己的数据，但需要进一步研究以了解它对实际应用中 UI 的影响。

CRDTs 积累了大量的变化历史，产生了性能问题

我们的团队将 PushPin 用于类似 Sprint 计划的真实文档中。性能和内存/磁盘的使用很快就成了问题，因为 CRDTs 存储了所有的历史，包括逐个字符的文本编辑。这些数据会堆积起来，不能轻易地被截断，因为不可能知道什么时候有人会在离开 6 个月后重新连接到你的共享文档，并需要从那一刻开始合并修改。

注：与文章发表时相比 CRDT 的性能和内存/磁盘占用已经有了明显改善，详情可参考 CRDT benchmarks

网络通信仍然是未解决的问题

CRDT 算法只规定了数据的合并，但没有说不同用户的编辑如何到达同一台物理计算机上。

在这些实验中，我们尝试了通过 WebRTC 进行网络通信；用 Dropbox 和 USB 钥匙复制文件的 “sneakernet”实现；可能使用 IPFS 协议；并最终确定使用 Dat 的 Hypercore 点对点库。

CRDTs 不需要点对点网络层；使用服务器进行通信对 CRDTs 来说是很好的。然而，为了充分实现本地优先软件的长期有效的目标，我们希望应用程序的寿命超过其供应商管理的任何后端服务，所以去中心化的解决方案是合理的最终目标。

对于原型中使用的 P2P 技术我们发现：一方面，这些技术还远未达到可以投入生产的程度。特别是 NAT 穿透，是不可靠的，这取决于用户当前连接的特定路由器或网络拓扑结构。但在另一方面，P2P 协议和去中心化网络社区所带来的可能性是巨大的。在这个已经开始依赖中心化 API 的世界里，没有互联网接入的计算机之间的实时协作感觉就像魔术一样。

云服务器在发现、备份和突发计算方面仍有其地位

像 PushPin 这样的实时协作原型可以让用户在没有中间服务器的情况下与其他用户分享他们的文件。这对于隐私和所有权来说是非常好的，但是可能会出现这样的情况：一个用户分享了一个文件，然后在其他用户连接之前关闭了他们的笔记本盖子。如果用户没有同时在线，他们就不能互相连接。

因此，服务器在本地优先的世界中可以发挥作用—不是作为中央机构，而是作为 “cloud peer” 来支持客户端应用程序（它将不在关键路径上）。例如，一个存储文件副本的 cloud peer，在其他 peer 上线时将其转发给他们，可以解决上述封闭的笔记本电脑问题。

Hashbase 是 Cloud Peer 的例子，也是 Dat 和 Beaker 浏览器的桥梁。

同样地，Cloud Peer 可以是

存档/备份位置（特别是对于手机或其他存储空间有限的设备）
通往传统服务器 API 的桥梁（如天气预报或股票行情）
突发计算资源的提供者（如使用强大的 GPU 渲染视频）

传统系统和本地优先系统的关键区别不是没有服务器，而是服务器的职责发生了变化：它们属于支持性角色，而不是真理的来源。

你可以如何提供帮助

这些实验表明，本地优先的软件是可能的。协作和所有权并不相悖—我们可以得到两个世界的最好结果，用户也可以从中受益。

然而，基础技术仍在进行。它们对开发原型很有好处，我们希望它们在未来几年内能够发展和稳定下来，但从现实的角度来看，今天在生产环境中用 Automerge 这样的实验项目来取代 Firebase 这样的成熟产品还不可取。

如果你和我们一样相信本地优先的未来，你（和我们所有技术领域的人）可以做什么来推动我们走向这个未来？这里有一些建议。

对于分布式系统和编程语言研究者来说

本地优先的软件从最近对分布式系统的研究中受益匪浅，包括 CRDTs 和 P2P 技术。目前的研究界在提高 CRDTs 的性能和功率方面取得了卓越的进展，我们热切地等待着这项工作的进一步成果。尽管如此，仍有一些有趣的机会可以进一步开展工作。

大多数 CRDT 研究的运作模式是，所有合作者立即将他们的编辑应用于某个文件的单一版本。然而，实际的本地优先应用需要更多的灵活性：用户必须有拒绝其他合作者编辑的自由，或者对不与他人共享的文件版本进行私人修改。用户可能想决定应用哪些修改，或调整修改历史。这些概念在分布式源码控制领域被很好地理解为 “分支”、“分叉”、“重定位”等等。迄今为止，只有很少的算法和编程模型的工作来解决在多个文档版本和分支并存的情况下的问题。

还有围绕类型、模式迁移和兼容性的更深入的有意思的问题。不同的合作者可能使用不同版本的应用程序，可能具有不同的功能。由于没有中央数据库服务器，所以没有权威的“当前”数据 Schema。我们如何编写软件，使不同的应用程序版本能够安全地交互，即使是在数据格式变化的时候？这个问题在基于云的 API 设计中也有类似之处，但在本地优先中有额外的挑战。

对于人机交互（HCI）研究者来说

对于集中式系统，应用程序与服务器的“同步”状态很容易提供，也有大量案例可以参考。而在去中心化系统有很多新机会来探索 UI 上的挑战。

我们希望研究人员能够考虑如何提供在线和离线状态，或者在任何其他用户可能持有不同数据副本的系统中的可用和不可用状态。当每个人都是 peer 的时候，我们应该如何考虑网络连接的问题？当我们可以直接与其他节点同步而不需要访问互联网时，“在线”意味着什么？

“铁轨”模型。它在 GitX 中被用于可视化 Git 仓库中的源代码历史结构

当每个文件都能形成复杂的版本历史时，仅仅通过日常操作，就会出现一个尖锐的问题：我们如何将这个版本历史传达给用户？在没有中心化的真理源的情况下，用户应该如何思考版本问题，分享和接受修改，并理解他们的文档是如何变成某种样子的？今天，有两种主流的变更管理模式：一种是差异和补丁的源代码模式，另一种是建议和评论的 Google Docs 模式。这些就是我们能做的最好的了吗？我们如何将这些想法推广到非文本的数据格式？我们急切地想知道能发现什么。

虽然集中式系统在很大程度上依赖于访问控制和权限，但同样的概念并不直接适用于本地优先的环境。例如，不能阻止任何拥有某些数据副本的用户在本地修改这些数据；但是，其他用户可以选择是否订阅这些修改。用户应该如何看待共享、权限和反馈？如果我们不能从别人的电脑上删除文件，那么与人 “停止共享”是什么意思？

我们相信，集中化的假设在我们今天的用户体验中根深蒂固，而我们才开始发现改变这种假设的后果。我们希望这些开放性的问题能够激发研究人员去探索我们认为是一个未开发的领域。

对于从业者

如果你是一名软件工程师、设计师、产品经理或独立的应用程序开发人员，你能提供什么帮助？我们建议采取循序渐进的步骤来实现本地优先的未来。从给你的应用程序打分开始：

	1. 快	2. 多设备	3. 离线	4. 协作	5. 长期可用性	6. 隐私	7. 控制权
你的应用	?	?	?	?	?	?	?

这里是改善以上特性的一些策略：

快：激进的缓存和提前下载资源，可以防止用户在打开你的应用或之前打开的文档时看到”加载中”的状态。默认情况下信任本地缓存，而不是让用户等待网络获取。
多设备：像 Firebase 和 iCloud 这样的同步基础设施使多设备支持变得相对简单，尽管它们确实引入了长期可用性和隐私问题。像 Realm Object Server 这样的自我托管的基础设施提供了替代品。
离线：在网络世界中，Progressive Web Apps 提供的功能，如 Service Worker 和 App Manifests，可以提供帮助。在移动世界中，要注意 WebKit 框架和其他依赖网络的组件。通过关闭 WiFi 来测试你的应用程序，或使用 traffic shapers，如 Chrome Dev Tools 网络状况模拟器或 iOS 网络链接调节器。
协作：除了 CRDTs，更成熟的实时协作技术是 Operational Transformation（OT），例如在 ShareDB 中实现。
长期可用性：确保你的软件可以很容易地导出到扁平化的标准格式，如 JSON 或 PDF。例如：大量导出，如 Google Takeout；持续备份成稳定的文件格式，如 GoodNotes；以及 JSON 下载文件，如 Trello。
隐私：云计算应用程序从根本上说是非私有的，公司的员工和政府可以随时窥视用户数据。但对于移动或桌面应用，要尽量向用户说明数据何时只存储在他们的设备上，而不是传输到后端。
控制权：用户能否在你的应用程序中轻松地备份、复制或删除他们的部分或全部文件？这通常需要重新实现所有基本的文件系统操作，就像 Google Docs 对 Google Drive 所做的那样。

对初创企业的呼吁

如果你是一个对建立开发者基础设施感兴趣的企业家，上述所有情况表明了一个有趣的市场机会: “Firebase for CRDTs”。

这样的创业公司需要提供优异的开发者体验和在本地持久化的库（类似于 SQLite 或 Realm）。它需要适用于移动平台（iOS、Android）、本地桌面（Windows、Mac、Linux）和 Web（Electron、Progressive Web Apps）。

用户控制、隐私、多设备支持和协作都将被纳入其中。应用程序开发人员可以专注于构建他们的应用程序，因为他们知道最简单的实施路径也会给他们在本地优先的记分卡上打上最高分。作为检验你是否成功的试金石，我们建议：即使所有的服务器都关闭了，你的所有客户的应用程序是否能继续永久地工作？

我们相信，随着 CRDTs 时代的到来，“Firebase for CRDTs” 的机会将是巨大的。如果你正在做这方面的工作，我们想听听你的意见。

总结

计算机是人类有史以来最重要的创造性工具之一。软件已经成为我们完成工作的方式，也是工作的储存库。

为了追求更好的工具，我们将许多应用程序转移到云端。云计算软件在许多方面都优于“老式”软件：它提供了可协作的、永远最新的应用程序，可以从世界任何地方访问。我们不再担心我们正在运行的软件是什么版本，或某个文件在哪台机器上。

然而，在云中，数据的所有权属于服务器，而不是用户，因此我们成了自己数据的借用者。在云应用中创建的文件注定会在这些服务的创建者不再维护它们时消失。云服务是无法长期保存的。没有网站时光机可以恢复一个没落的网络应用。互联网档案馆不能保存你的谷歌文档。

在这篇文章中，我们为未来的软件探索了一条新的发展道路。我们展示了用户有可能保留对其数据的所有权和控制权，同时也受益于云相关的功能：无缝协作和从任何地方访问。鱼和熊掌可以兼得。

但还需要更多的工作才能将本地优先应用到实践中。应用程序开发人员可以采取渐进的步骤，例如改进离线支持和更好地利用设备上的存储。研究人员可以继续改进本地优先软件的算法、编程模型和用户界面。企业家们可以开发基础技术，如 CRDTs 和点对点网络，以驱动下一代应用。

今天，创建一个服务器掌控所有所有数据的网络应用是很容易的。但要建立尊重用户所有权和代理权的协作软件却太难了。为了改变这种平衡，我们需要改进开发本地优先软件的工具。我们希望你能加入我们。

我们欢迎你的想法，问题，或批评：@inkandswitch 或 hello@inkandswitch.com。

致谢

Martin Kleppmann 得到了波音公司的资助。感谢我们在 Ink & Switch 的合作者，他们参与了上面讨论的原型。Julia Roggatz, Orion Henry, Roshan Choxi, Jeff Peterson, Jim Pick, 和 Ignatius Gilfedder。也感谢 Heidi Howard、Roly Perera，以及 Onward！的匿名审稿人对本文草稿的反馈。

本翻译也被发表至知乎见相关讨论。

High-performance tidy trees visualization

Tue, 14 Jun 2022 23:00:32 GMT

NaiveTidy

This article introduces the algorithm to draw non-layered trees in linear time and re-layout partially when some nodes change in O(d) time, where d is the maximum depth of the changed node.

The source code is available at zxch3n/tidy. It only takes a few milliseconds to finish the layout of a tree with tens of thousands of nodes within the web browser.

Introduction
- Layered and non-layered
- Aesthetic rules
A naive non-layered tree visualization
Tidy tree visualization algorithm
Relayout partially
Benchmark
Future work
- Remaining aesthetic issue
- The Tidy Library
References

Introduction

Trees are ubiquitous data structures. Various visualizations of trees were proposed to help people understand different aspects of trees. This article focuses on the classical node-link diagrams.

A good tree drawing should be aesthetically pleasing while using as little space as possible. In 1979, Wetherell and Shannon [1] formalized aesthetic rules for tidy trees and presented the first O(n) algorithm to solve it. In 1981, Reingold and Tilford [2] extended the aesthetic rules to make the drawings more aesthetically pleasing and compact. However, both of them would violate the aesthetic rules when extended to m-ary trees. In 1990, Walker [3] solved this problem with O(n^2) time complexity. Buchheim [4] improved Walker’s work to run in O(n) in 2002. In 2014, Ploeg [5] presented the first O(n) algorithm to produce tidy non-layered drawings of trees.

This article introduces the layout algorithm of non-layered tidy trees [5] and presents a fast relayout algorithm. Engineers can use it to build fast tree editor tools like mindmaps.

Layered and non-layered

In tree visualization, each node may have variant width and height. For example, nodes may contain text content of different lengths. In this case, the tree can be drawn as layered, where nodes with the same depth are horizontally aligned, or non-layered, where there is a fixed vertical distance between parent and children.

Layered drawings make depth comparison easier, whereas non-layered ones generally use less space.

Non-Layered

Layered

The algorithm of non-layered drawing is harder than the layered one since the former can be easily extended to the latter. Ploeg [5] designed the first algorithm to finish the layout of non-layered tidy trees in linear time. The detail of the algorithm will be covered in the rest of this article. If you are interested in how layered drawing works, you can read the article by Bill Mill [6].

Aesthetic rules

A tidy drawing of a tree should obey the aesthetic rules while using as little space as possible. The aesthetic rules include:

No overlapped node
No crossed line
A node’s children should stay on the same line
Parents should be centered over their children
A subtree should be drawn the same way regardless of where it occurs in the tree
Nodes are ordered. Drawings of nodes should have the same order.
A tree and its mirror image should produce drawings that are reflections of one another, which implies
- Small, interior subtrees should be spaced out evenly among larger subtrees, where the larger subtrees are adjacent at one or more levels.
- Small subtrees at the far left or far right should be adjacent to larger subtrees.

A naive non-layered tree visualization

Most mind map applications use a naive version of the tidy layout, i.e., it obeys the aesthetic rules but does not care about compactness.

The naive tidy visualization algorithm treats each node and its offsprings as a bounding box, avoiding collision between the bounding boxes.

function naiveTidyLayout(root) {
  root.y = 0
  root.preOrderTraverse(node => {
    node.y = node.parent.y + node.parent.height + margin
  })
  root.postOrderTraverse(node => {
    if (node.children.length == 0) {
      node.bbox.width = node.width
      return
    }

    const childrenWidth = node.children.reduce(
      (acc, cur) => acc + cur.width + margin,
      -margin
    )
    node.bbox.width = max(node.width, childrenWidth)
    let relativeX = node.width / 2 - childrenWidth / 2
    for (const child of node.children) {
      child.relativeX = relativeX + child.bbox.width / 2 - child.width / 2
      relativeX += child.bbox.width + margin
    }
  })
  root.preOrderTraverse(node => {
    node.x = node.parent.x + node.relativeX
  })
}

It is easy to implement and has good performance. But its layout is not compact, as shown in the interactive example.

Tidy tree visualization algorithm

How to achieve compactness

Note that the aesthetic rules require that a subtree should be drawn the same way no matter where it appears in the tree. It means that if the layout of the subtree is done, inside it, all nodes’ relative positions to their parent are finalized. So we can use a post-order traversal to determine the relative positions. A high-level abstraction of the tree visualization algorithm is

function layout(root) {
  root.postOrderTraverse(node => {
    // determine each child subtree's relative position to the parent
    layoutSubtree(node, node.children)
  })

  root.preOrderTraverse(node => {
    finalizeAbsolutePosition(node)
  })
}

To arrange children compactly, during layoutSubtree, we need child subtrees to be as close to their siblings as possible. Therefore, we can abstract a tidy layout algorithm as below.

function layoutSubtree(node, children) {
  if (children.length == 0) {
    return
  }

  const prev = [children[0]]
  for (let i = 1; i < children.length; i++) {
    const cur = children[i]
    cur.relativeX = getMoveDistance(prev, cur)
    prev.push(cur)
  }

  positionRoot(node)
}

Suppose we are visualizing a complete k-ary tree, then we have $T(n) = kT(n/k) + f(n)$ , where $f(n)$ is the time complexity of the getMoveDistance function. Based on master theorem,

If $f(n) = O(n^{1-ϵ})$ , then $T(n) = Θ(n)$ .
If $f(n) = Θ(n)$ , then $T(n) = Θ(n * log n)$ .
If $f(n) = Ω(n^{1+ϵ})$ , then $T(n) = Θ(f(n))$ .
ϵ > 0 is a constant.

We only need a distance function with complexity of $O(n^{1-ϵ})$ to make the algorithm run in linear time. - Ploeg [5] proposed a algorithm with $f(n) = \log _kn =O(n^{1-ϵ})$ , so that $T(n) = Θ(n)$ . Ploeg [5] prooved its linear complexity for the cases other than complete k-ary tree.

Fix aesthetic rule 7

The above algorithm satisfies aesthetic rules 1-6, but not aesthetic rule 7: a tree and its mirror image should produce drawings that are reflections of one another, as shown in the image below.

Violet Aesthetic Rule 7

Obey Aesthetic Rule 7

It happens when large neighbors surround small subtrees. The algorithm will pile the small ones to the left.

A simple fix is to take the average positions of the original layout and the mirror of the mirrored layout. But it tends to cluster the small subtrees at the center.

Taking average positions

Walker [3] designed the first algorithm to address this issue, giving a more visually pleasing output. Its idea is that when moving a subtree to the right, the move distance should also be distributed to the smaller interior subtrees.

To make the overall algorithm run within linear time, we need an O(1) method to

Find the intermediate siblings
Distribute the distance evenly to the intermedia siblings

Now the code changes to

function layoutSubtree(node, children) {
  if (children.length == 0) {
    return
  }

  const prev = [children[0]]
  for (let i = 1; i < children.length; i++) {
    const cur = children[i]
    const collideIndex = getCollisionIndex(prev, cur)
    const distance = getMoveDistance(prev, cur)
    cur.relativeX = distance
    distributeDistanceToInteriorSubtrees(children, distance, collideIndex, i)
    prev.push(cur)
  }

  positionRoot(node)
}

The O(n) layout algorithm [5]

To make the overall algorithm run in O(n), we need the following methods done in $O(n^{1-ϵ})$

1.  getMoveDistance(leftSiblings, subtree)
2.  getCollisionIndex(leftSiblings, subtree)
3.  distributeDistanceToInteriorSubtrees(children, distance, collideIndex, currentIndex)

Determine move distance

getMoveDistance calculates how far a subtree needs to move to avoid colliding with the siblings on its left. For this purpose, it only needs to calculate the distance between the siblings’ right and the subtree’s left contour.

Note that aesthetic rule 5 requires: a subtree should be drawn the same way regardless of where it occurs in the tree. So a subtree’s left and right contour are not affected by other subtrees or their ancestors.

We introduce four new variables for this purpose.

threadLeft: points to the next left contour node
modifierThreadLeft: the next left contour node x position relative to this
threadRight: points to the next right contour node
modifierThreadRight: the next right contour node x position relative to this

The thread of the right contour is:

The first node of the thread is the rightmost subtree’s root.
If the current thread node has children, then the next node in the thread is its last-child
If the current thread node c has no child, the next node in the thread is c.threadRight.
c.modifierThreadRight is c.threadRight’s x position relative to c

The left contour thread follows the right contour’s mirrored rules.

When calculating the contour’s distance, only nodes with intersections on the y-axis need to be compared. And in both layered and non-layered cases, each node’s y positions can be precomputed.

We can express the extended behaviors in pseudocode.

function layoutSubtree(node, children) {
  if (children.length == 0) {
    return;
  }

  const prev = [children[0]];
  for (let i = 1; i < children.length; i++) {
    const cur = children[i];
    const collideIndex = getCollisionIndex(prev, cur);
    const distance = getMoveDistance(prev, cur);
    cur.relativeX = distance;
    distributeDistanceToInteriorSubtrees(children, distance, collideIndex, i);
+   mergeContour(prev, cur);
    prev.push(cur);
  }

  positionRoot(node);
}

+function getMoveDistance(prev, cur) {
+  const curLeftContour = cur;
+  const prevRightContour = prev[prev.length - 1];
+  let maxDistance = 0;
+  while (curLeftContour && prevRightContour) {
+    const xL = getRelativeX(curLeftContour)
+    const xR = getRelativeX(prevRightContour) + prevRightContour.width + margin;
+    maxDistance = max(maxDistance, xR - xL);
+    const yL = curLeftContour.y + curLeftContour.height;
+    const yR = prevRightContour.y + prevRightContour.height;
+    if (yL <= yR) {
+      curLeftContour = nextLeftContour(curLeftContour);
+    }
+    if (yL >= yR) {
+      prevRightContour = nextRightContour(prevRightContour);
+    }
+  }
+
+  return maxDistance;
+}
+
+function mergeContour(prev, cur) {
+  if (bottom(prev) > bottom(cur)) {
+    const extremeRight = getRightThreadLastNode(cur)
+    extremeRight.threadRight = getRightThreadNodeAtY(prev[prev.length - 1], extremeRight.y);
+    extremeRight.modifierThreadRight = ...;
+  } else if (bottom(prev) < bottom(cur)) {
+    const extremeLeft = getLeftThreadLastNode(prev[0])
+    extremeLeft.threadLeft = getLeftThreadNodeAtY(cur, extremeLeft.y);
+    extremeLeft.modifierThreadLeft = ...;
+  }
+}

Get collided subtree

During the post-order traversal, inside each iteration, we do layouts on subtrees that share the same parent. getCollisionIndex get which subtree the right contour node, which produces the maxDistance, belongs to.

The easiest way to implement is to follow the parent pointer of the node to find the subtree’s root. But in the worst case, it takes O(n^2).

Notice that each subtree can only take a continuous y-span in the right contour thread of a forest. And the y-span always starts with another subtree’s bottom or 0 and ends with the bottom of the subtree.

So we can tell which subtree the right contour node belongs to by the y position.

Ploeg [5] used a linked list to construct this data structure:

+class IYL {
+  constructor(
+    public bottom: number,
+    public index: number,
+    public next: IYL | null
+  ) {}
+
+  update(minY: number, index: number) {
+    let cur = this;
+    while (cur != null && minY >= cur.bottom) cur = cur.next;
+    return new IYL(minY, index, cur);
+  }
+}

function layoutSubtree(node, children) {
  if (children.length == 0) {
    return;
  }

  const prev = [children[0]];
+ let iyl = new IYL(getBottom(children[0]), 0, null);
  for (let i = 1; i < children.length; i++) {
    const cur = children[i];
+   const [distance, collideIndex] = getMoveDistance(prev, cur, iyl);
    cur.relativeX = distance;
    distributeDistanceToInteriorSubtrees(children, distance, collideIndex, i);
    mergeContour(prev, cur);
    prev.push(cur);
+   iyl = iyl.update(getBottom(cur), i);
  }

  positionRoot(node);
}

function getMoveDistance(prev, cur, iyl) {
  const curLeftContour = cur;
  const prevRightContour = prev[prev.length - 1];
  let maxDistance = 0;
  let collideIndex = 0;
  while (curLeftContour && prevRightContour) {
+   if (xR.y + xR.height > iyl.bottom) {
+     iyl = iyl.next;
+   }

    const xL = getRelativeX(curLeftContour)
    const xR = getRelativeX(prevRightContour) + prevRightContour.width + margin;
+   if (xR - xL > maxDistance) {
+     maxDistance = xR - xL;
+     collideIndex = iyl.index;
+   }

    const yL = curLeftContour.y + curLeftContour.height;
    const yR = prevRightContour.y + prevRightContour.height;
    if (yL <= yR) {
      curLeftContour = nextLeftContour(curLeftContour);
    }
    if (yL >= yR) {
      prevRightContour = nextRightContour(prevRightContour);
    }
  }

  return [maxDistance, collideIndex];
}

Distribute spacing

We can implement it in a bruit-force way as below. But in the worst case, it causes the overall complexity to be $O(n^2)$ .

function distributeDistanceToInteriorSubtrees(children, distance, from, to) {
  for (let i = from + 1; i < to; i++) {
    children[i].relativeX += (distance * (i - from)) / (to - from)
  }
}

[4] introduced a simple trick to make it O(1). Given that the distance distributed is always an arithmetic progression, we can cache the difference at the start node and clear the effect at the end node. We need two variables: shiftAcceleration and shiftChange. They are cached position changes that will apply to children[from+1..to] in finalizeAbsolutePosition.

function layout(root) {
  root.postOrderTraverse(node => {
    // determine each child subtree's relative position to the parent
    layoutSubtree(node, node.children);
  })

  root.preOrderTraverse(node => {
    finalizeAbsolutePosition(node);
  })
}

function finalizeAbsolutePosition(node) {
  addChildSpacing(node);
  ...
}

function addChildSpacing(node) {
  let speed = 0.;
  let delta = 0.;
  for (const child of node.children) {
    speed += child.shiftAcceleration;
    delta += speed + child.shiftChange;
    child.relativeX += delta;
  }
}

function distributeDistanceToInteriorSubtrees(children, distance, from, to) {
  if (to == from + 1){
    return;
  }

  children[from + 1].shiftAcceleration += distance/(to-from);
  children[to].shiftAcceleration -= distance/(to-from);
  children[to].shiftChange -= distance - distance/(to-from);
}

Final Code

You can find the final code of this article here. However, there are still a few trivial details missing in this abstraction. For details, please refer to the source code.

Interactive example

Layout Type:

Tidy

Nodes

In this example, you can try non-layered tidy layout, layered tidy layout, and naive layout.

Relayout partially

Node editing is a common scenario in applications like mind maps. If the relayout time is larger than 16ms, there will be obvious freezes, which is unacceptable. Therefore, a partial relayout is required for a smooth user experience on large editable tree visualization.

In this section, we exclude the finalizeAbsolutePosition and only talk about how to re-calculate each node’s relative position to their parent. Because changing one node’s size may cause the entire tree’s absolute positions to change, relative positions are much more stable as aesthetic rule 5 required. And in the real-world application, we only need the absolute positions of the nodes inside the screen. By detecting the collision between trees’ bounding boxes and the screen, we can filter out the offscreen content swiftly. Strictly speaking, the time complexity of partial relayout is O(d + m), where m is the in-screen nodes number, and d is the max depth of changed nodes.

Adding the partially relayout support to the naive version is relatively easy. Because the affected states are straightforward to reason about, i.e., only the bounding boxes of the edited nodes and their ancestors are changed.

For partial relayout, we need to determine which thread pointer caches are outdated. We say a subtree is changed if it or its offspring’s sizes change or an insertion or deletion happens inside this subtree. Note that

If all nodes inside a subtree are not changed, the thread pointers of its nodes that point to the node inside this subtree won’t change. This is because the layout of a tree is agnostic about nodes outside. And the thread pointers that point inside are only affected by the structure of the subtree itself.
In a subtree, only the deepest nodes, which have the greatest value of node.y + node.height, have thread pointers that point outside of the tree. This rule is obvious in the mergeContour implementation.
Based on 1 and 2, we can infer that we only need to update the thread pointers of its deepest nodes for an unchanged subtree.
From 3, we can infer that if a node and its parent are roots of unchanged subtrees, we only need to update the parent subtree’s deepest nodes’ threads.
Generalizing 4, for all unchanged subtrees, only those who are siblings of the changed subtrees need to update their deepest nodes’ thread pointers.

Based on the above observations, we only need to relayout the changed subtree and update its siblings’ thread pointers. Below is the code about partial relayout when there is a single changed node. We can easily extend it to multiple changed nodes.

function relayout(root, changedNode) {
  let node = changedNode
  while (node.parent) {
    for (const sibling of node.parent.children) {
      const r = getRightBottomNode(sibling)
      r.threadRight = null
      r.modifierThreadRight = 0
      const l = getLeftBottomtNode(sibling)
      l.threadRight = null
      l.modifierThreadRight = 0
    }

    layoutSubtree(node.parent, node.parent.children)
    node = node.parent
  }
}

Benchmark

The code is available at GitHub. The layout algorithms are written in Rust and compiled to WASM. The renderer is written in TypeScript.

Benchmarks were done on MacBook Pro (13-inch, M1, 2020). It only measures the layout algorithm without the allocation and deallocation time. Mysteriously, the WASM build is faster than the native build on large data. It is very interesting, but I have not found out why.

Future work

Remaining aesthetic issue

The current layout algorithm is still not ideal in some cases.

Current layout

Ideal layout

As the above example shows, the root’s children are not symmetric in the current layout though it obeys the aesthetic rules. It does not violate aesthetic rule 7, since the drawing of mirrored structure would give a mirrored layout.

To fix this issue, we need a new aesthetic rule to formalize the problem.

The Tidy Library

Though tidy tree visualization is useful in many fields, we haven’t seen many adoptions of this algorithm in the industry because it is error-prone and slower. I hope Tidy Lib can make the adoption simple and reliable.

The plan is to add full support for partial relayout, compress wasm size, and performance improvement. This lib mainly focuses on the layout algorithm. Building a full-fledged tree visualization tool or editor is not a priority of this lib.

This lib is published under MIT License. Don’t hesitate to contact me if you want to participate or have any suggestions.

References

[1]C. Wetherell and A. Shannon, “Tidy Drawings of Trees,” IEEE Transactions on Software Engineering, vol. SE-5, no. 5, pp. 514–520, Sep. 1979, doi: 10.1109/TSE.1979.234212.
[2] E. M. Reingold and J. S. Tilford, “Tidier Drawings of Trees,” IEEE Transactions on Software Engineering, vol. SE-7, no. 2, pp. 223–228, Mar. 1981, doi: 10.1109/TSE.1981.234519.
[3] J. Q. Walker II, “A node-positioning algorithm for general trees,” Software: Practice and Experience, vol. 20, no. 7, pp. 685–705, 1990, doi: 10.1002/spe.4380200705.
[4] C. Buchheim, M. Jünger, and S. Leipert, “Improving Walker’s Algorithm to Run in Linear Time,” in Graph Drawing, Berlin, Heidelberg, 2002, pp. 344–353. doi: 10.1007/3-540-36151-0_32.
[5] A. van der Ploeg, “Drawing non-layered tidy trees in linear time,” Software: Practice and Experience, vol. 44, no. 12, pp. 1467–1484, 2014, doi: 10.1002/spe.2213.
[6] Bill Mill, “Drawing Presentable Trees.” https://llimllib.github.io/pymag-trees/ 2008

如何设计 CRDT 算法

Thu, 23 Dec 2021 14:00:02 GMT

Marc Shapiro 在论文 Conflict-free replicated data types 中正式定义了两种 CRDT 方法，基于操作的(Operation-based) 和基于状态的(State-based)，以及他们的充分条件。从而依据充分条件就可以更轻松明确地设计出 CRDT 算法。下文将介绍这些充分条件

PS: 为了方便理解对原文进行了简化，严谨的推导和证明见 CRDT 原文。

术语 & 一些定义
两种 CRDT 类型
设计 CRDT

术语 & 一些定义

为了深入 CRDT 的设计原则，我们需要先清晰定义问题。

我们考虑这样一个异步网络系统：系统中有多个副本(replica)，每个副本代表一个进程/一个计算机，副本可能会崩溃，我们用正确的副本指未崩溃的副本。一个副本可能会崩溃之后永不恢复，或者保持内存完整性的情况下地恢复。副本之间可能会被分区。

最终一致性 - Eventual Consistency

最终一致性由三个属性构成

Eventual Delivery: 发布到一个正确的副本上的更新列表最终将被传达至所有正确的副本
收敛 Convergence: 收到了一样的更新列表的正确副本们最终状态将一致
终止 Termination: 所有执行的方法都会终止（即保证算法能在有限时间内完成计算，而不是要进行 $2^{128}$ 次计算来遍历整个状态空间的这种算法）

💪 强最终一致性 - Strong Eventual Consistency (SEC)

强最终一致性定义为：满足「最终一致性 Eventual Consistency」且具有「强收敛性 Strong Convergence」。

强收敛 Strong Convergence: 收到了一样的更新列表的正确副本们的状态一致

「强最终一致性 SEC」和「最终一致性 EC」的区别在于 EC 有可能要求用户解决冲突，而 SEC 是不会发生冲突的。

CRDT

CRDT 的定义为：满足「强最终一致性」的数据类型。

偏序集 - Partial Order

给定集合S，“≤”是S上的二元关系，若“≤”满足：

自反性：∀a∈S，有a≤a；
反对称性：∀a，b∈S，a≤b且b≤a，则a=b；
传递性：∀a，b，c∈S，a≤b且b≤c，则a≤c；

则称集合 S 为偏序集

例如下图是以包含关系定义的集合上的偏序，A -> B 的箭头表示 A ≤ B。而 {x} 和 {y} 二者之间是不可比较的。

半格 - Semilatice

半格是一个偏序集
每个非空集合都有上确界或者下确界
- 上确界被称为 Least upper bound (LUB)

两种 CRDT 类型

基于状态的 CRDT (State-based CRDT, CvRDT)

设计一个基于状态的 CRDT 中需要先定义一个 State-based Object。当它满足一定的性质时就能成为 State-based CRDT 👏。State-based Object 的定义包括：

State 副本的内部状态的类型
state_zero 内部状态的初始值
≤ 定义了 state 之间的顺序
update(s, u) 定义 state 的更新方式
merge(s, s') 函数可以用于合并两个状态得到新状态
副本之间通过传递自己的 state，并进行 merge 操作来达到一致性

单调半格对象 - Monotonic Semilattice Object

指一个 Stated-base Object，如果它满足以下性质就称其为单调半格

该对象集合是一个以 ≤ 为顺序的半格
合并「本地状态 s」和「远端状态 s’」的方式为计算二者的上确界（LUB），即 merge(s, s’) = $s \sqcup s'$
在所有的更新中，s 都是单调递增的，即 s ≤ update(s, u)

单调半格示意：从左到右单向递增，合并操作被定义为最小上确界(LUB)，所有改动都 deliver 之后状态一致

定理

定理：假设有 Eventual delivery 和 Termination 的属性，那么任意单调半格的 State-based 对象都是有强最终一致性（Strong Eventual Consistency）的。

直觉上我们应该如何理解这个定理呢？

观察到最小上确界操作 $\sqcup$ 符合以下性质：

结合律: $(a \sqcup b) \sqcup c$ = $a \sqcup (b \sqcup c)$
交换律: $a \sqcup b$ = $b \sqcup a$

从而收到同样的更新列表 u = $\{s_0, s_1,...,s_n\}$ ，但更新顺序不同的副本，他们的最终状态因为有交换律和结合律都等于 $s_0 \sqcup s_1 \sqcup s_2 ... \sqcup s_n$ ，所以此时所有副本的状态都一致，符合 SEC。详细的定理证明见原文。

如何设计 State-based CRDT

保证系统满足 Eventual delivery 和 Termination
state 在 ≤ 上满足偏序集的要求
对任意的 s, u 满足 s ≤ update(s, u)
merge(s, s') 得到的是两个状态的上确界

基于操作的 CRDT（Op-based CRDT, CmRDT）

同样的设计一个基于操作的 CRDT 中需要先定义一个 Op-based Object。当它满足一定的性质时就能成为 Op-based CRDT。Op-based Object 的定义包括：

state 是每个副本的内部状态
state_zero 内部状态的初始值
op 是每个原子操作的类型，副本直接通过传递 op 来达到同步
apply_op(state, op) 是在一个 state 上应用 op 的函数，返回新的状态；op 的交换律指的就是 apply_op(apply_op(state, opA), opB) == apply_op(apply_op(state, opB), opA)
check_state(state, op) 确认一个状态是否满足应用 op 的前置条件
- Op-based CRDT 的每一个操作 op 都有对应的前置状态检查函数 check_state，在应用 op 之前需要检查 check_state 函数是否满足，如果不满足就将阻塞延迟
- check_state 函数的目的是为了保证 op 所依赖的因果顺序成立，例如删除 x 节点的操作依赖于 x 节点被创建的操作，否则就无法应用该操作。这也意味着 Op-based CRDT 的使用者有责任证明每个操作的前置状态都是能够得到满足的
副本之间通过传递彼此缺失的 op，并进行 apply_op 来达到最终一致性

并行的操作 - Concurrent Operation

根据每个 op 在副本上的执行顺序我们可以定义 op 之间的偏序关系：

如果一个 op A 在某个副本上先于 op B 执行，那么 A < B
如果既没有 A < B 也没有 B < A，那么我们就称 A 和 B 是并行的操作

定理

构建一个 Op-based CRDT 的充分条件为:
假设所有操作都按照因果顺序 deliver，且所有更新函数都会终止（满足 Termination）。那么所有满足以下条件的 op-based object 就具有强最终一致性（SEC）
所有的并行的操作都满足交换律
每个操作的前置条件都能通过按因果顺序应用得到满足
假设所有操作都满足 Eventual Deliver (按照随机顺序 deliver)，且所有更新函数都会终止（满足 Termination）。那么所有满足以下条件的 op-based object 就具有强最终一致性（SEC）
所有的操作都满足交换律

如何直观理解该定理: 如果有可能冲突的 Op 都是可以交换的，那么它们在一个副本上的应用顺序就对 Object 的最终状态没有影响，那么任意两个应用了同样的 op 集合的 Op-based CRDT 就都具有一致的状态，从而满足 SEC。

详细的定理证明见原文。

如何设计 Op-based CRDT

保证系统满足 Eventual delivery 和 Termination
保证可能出现并行的 Operation 都满足交换律（不管先应用哪个 Op，最终状态都一致）
在应用 Op 时需要保证该 Op 所依赖的前置状态得到满足

CmRDT 和 CvRDT 是等价的

在形式上，Op-based CRDT 和 State-based 是可以互相转换的。思路为：

通过 Op-based CRDT 构建 State-based CRDT 的方式为:
- 将新的 State-based Object 的 state 定义为一个二元组(s, M)，s 和 Op-based CRDT 的内部状态一致，M 是 Op-based CRDT 的内部 Op 的集合。
- 将新的 State-based Object 的 merge 操作定义为 merge((s, M), (s', M')) = apply_ops(s, M' - M)
通过 State-based CRDT 构建 Op-based CRDT 的方式为：
- 将新的 Op-based object 的 Op 定义为 State-based CRDT 的 State
- 将 apply_op 的操作定义为 apply_op(state, op) = merge(state, op)，而 merge 是服从对称性的操作，从而我们能够满足 SEC 得到一个 Op-based CRDT

设计 CRDT

根据上文我们有两种设计 CRDT 的方法，汇总为

如何设计一个 State-based CRDT

需要定义的内容	描述
`State`	内部状态的类型是什么
`state_zero: State`	初始状态
`≤`	状态之间的偏序关系
`merge(s0: State, s1: State): State`	合并两个状态的方法，应得到 s 和 s’ 的最小上确界
`Update`	更新的类型
`update(s: State, u: Update): State`	定义状态的更新方式， $\forall s, u$ . s ≤ update(s, u)

同时我们要保证

Eventual Delivery
每个函数都会终止

如何设计一个 Op-based CRDT

假设 op 不一定按照因果顺序 deliver，那么设计的方式为

需要定义的内容	描述
`State`	内部状态的类型是什么
`state_zero: State`	初始状态
`Op`	操作的类型
`apply(state: State, op: Op): State`	应用一个操作的函数，需要满足交换律，即 $\forall o_a, o_b, s$ . apply(apply(s, $o_a$ ), $o_b$ ) = apply(apply(s, $o_b$ ), $o_a$ )
`check_state(s: State, op: Op): boolean`	确认一个 op 所依赖的前置条件是否被满足

同时我们要保证

所有的 Op 最终都会被发布到每一个副本上
每个函数都会终止
保证每个 op 的前置条件最终都能得到满足

设计一个可增加删除元素的 Set CRDT

基于上面的 CRDT 框架我们已经有很好的理论支持我们设计一个 Last-write-wins Set，即出现同时删除和添加同一个元素时后写入的操作将覆盖先写入的操作。

但是在设计之前需要先了解在分布式系统中我们该如何判断事件的“先后”。

Lamport Timestamp

在中心化的系统中我们可以通过事件到达中心服务器的时间作为时间发生的时间戳来判断先后。但是在分布式环境中这种方式就不能使用了。此时我们可以使用 Lamport Timestamp。

Lamport Timestamp 的算法很简单

每个进程维护一个 counter
本地每发生一个事件就将 counter + 1，并将事件的时间戳设置为 counter 值
每当进程发送一个消息，就将本地 counter + 1，并将最新的 counter 值附带在消息上
当进程收到消息后，让自己的 counter = max(counter, message.counter) + 1

从而每一个消息都有一个明确的时间戳，根据时间戳我们就能够得到消息间的全序关系。但为了能够处理消息的 counter 相同的情况，我们还需要在消息中带上进程自己的 id，从而能够将全序关系定义为:

a.counter == b.counter? 
  a.pid < b.pid : a.counter < b.counter

Lamport timestamp，每个进程都会维护自己的计数器

实现

以 Op-based CRDT 的思路设计 Last-write-wins Set(LWWSet):

通过 Lamport timestamp 定义 Op 之间的全序关系
存在共同修改同一个元素的操作时，让 timestamp 更大的 Op 获胜
- 如果 Timestamp 一致，则让 pid 更大的 Op 获胜

TypeScript 实现代码

interface Op {
  time: number;
  pid: number;
  type: "add" | "remove";
  value: string;
}

type State = Map<string, Op>;
type ProcessState = { counter: number; state: State };
const state_zero: State = new Map();
const process_state_zero: ProcessState = {counter: 0, state: state_zero};

function apply(state:ProcessState, op: Op): ProcessState {
  const new_state: ProcessState = {
    counter: Math.max(state.counter, op.time) + 1,
    state: new Map(state.state),
  };
  if (!new_state.state.has(op.value)) {
    new_state.state.set(op.value, op);
  } else {
    const old_op = state.state.get(op.value);
    if (
      old_op.time < op.time ||
      (old_op.time === op.time && old_op.pid < op.pid)
    ) {
      new_state.state.set(op.value, op);
    }
  }

  return new_state;
}

function check_state(state: State, op: Op) {
  return true;
}

// 判断 LWWSet 是否含有某个值
function has(state: State, v: string): boolean {
  return state.get(v)?.type === "add";
}

// 插入 v 到 LWWSet
function add(state: ProcessState, v: string): ProcessState {
  return apply(state, {
    time: state.counter,
    pid: getPid(),
    type: "add",
    value: v,
  });
}

// 删除 LWWSet 中的 v
function remove(state: ProcessState, v: string): ProcessState {
  return apply(state, {
    time: state.counter,
    pid: getPid(),
    type: "remove",
    value: v,
  });
}

Introduction to CRDTs

Tue, 21 Dec 2021 22:00:02 GMT

中文版本

CRDT (conflict-free replicated data type) is a data structure that can be replicated across multiple computers in a network, where replicas can be updated independently and in parallel, without the need for coordination between replicas, and with a guarantee that no conflicts will occur.

CRDT is often used in collaborative software, such as scenarios where multiple users need to work together to edit/read a shared document, database, or state. It can be used in database software, text editing software, chat software, etc.

What problems does CRDT solve?
Origins
A simple CRDT case
Introduction to the Principle
Comparison of CRDT and OT
Addressed and Unresolved Issues
Start Using CRDTs Today
Extended reading

What problems does CRDT solve?

For example, a scenario where multiple users edit the same document online at the same time

This scenario requires that each user sees the same content, even after concurrent edits by different users (e.g. two users changing the title at the same time), which is known as consistency. (To be precise, CRDT satisfies the eventual consistency, see below for more details)

Users can use CRDT even when they are offline. They can be back on sync with others the network is restored. It also supports collaboratively editing with other users via P2P. It is known as partitioning fault tolerance. This allows CRDT to support decentralized applications very well: synchronization can be done even without a centralized server.

Origins

The formal definition of CRDT first appears in Marc Shapiro’s 2011 paper Conflict-free replicated data types (but Woot in 2006 is probably the earliest study). The motivation for the proposal is that the conflict resolution design of Eventual Consistency is difficult, few articles give design guidance suggestions, and randomly designed solutions are error-prone. So this paper proposes a simple, theoretically proven way to achieve Eventual Consistency, i.e., CRDT.

(PS: Marc Shapiro actually wrote a paper Designing a commutative replicated data type in 2007. In 2011, he reworded commutative into conflict-free in 2011, expanding the definition of commutative to include state-based CRDT)

According to CAP theorem, it is impossible for a distributed computing system to perfectly satisfy the following three points at the same time.

Consistency: each read receives the result of the most recent write or reports an error; it behaves as if it is accessing the same piece of data
Availability: every request gets a non-error response - but there is no guarantee that the data fetched is up-to-date
Partition tolerance: the ability of a distributed system to continue functioning properly even when communication between its different components is lost or delayed, resulting in a partition or network failure.

If the system cannot achieve data consistency within the time limit, it means that partitioning has occurred and a choice must be made between C and A for the current operation, so “perfect consistency” is in conflict with “perfect availability”.

CRDTs do not provide “perfect consistency”, but Strong Eventual Consistency (SEC). This means that site A may not immediately reflect the state changes from site B, but when A and B synchronize their messages they both regain consistency and do not need to resolve potential conflicts (CRDT mathematically prevents conflicts from occurring). Strong Eventual Consistency does not conflict with Availability and Partition Tolerance. CRDTs provide a good CAP tradeoff.

CRDT satisfies A + P + Eventual Consistency; a good tradeoff under CAP

(PS: In 2012, Eric Brewer, author of the CAP theorem, wrote an article CAP Twelve Years Later: How the “Rules” Have Changed, explaining that the description of the “two out of three CAP features” is actually misleading, and that the CAP actually prohibits perfect availability and consistency in a very small part of the design space, i.e., in the presence of partitions; in fact, the design of the tradeoff between C and A is very flexible. A good example is CRDT.)

A simple CRDT case

We can use a few simple examples to get a general idea of how CRDTs achieve Strong Eventual Consistency.

Grow-only Counter

How can we count the number of times something happens in a distributed system without locking?

Let each copy increments only its own counter => no locking synchronization & no conflicts
Each copy keeps the count values of all other copies at the same time
Number of occurrences = sum of count values of all copies
Since each copy only updates its own count and does not conflict with other counters, this type satisfies consistency after message synchronization

Grow-only Set

The elements in a Grow-only Set can only be increased and not decreased
To merge two such states, you only need to do a merge set
This type satisfies consistency after message synchronization because there are no conflicting operations since the elements only grow and do not decrease.

Both of these methods are CRDTs, and they both satisfy the following properties

They can both be updated independently and concurrently, without coordination (locking) between replicas
There is no possibility of conflict between multiple updates
Final consistency can always be guaranteed

Introduction to the Principle

There are two types of CRDTs: Op-based CRDTs and State-based CRDTs. This article focuses on the concept of Op-based CRDTs.

Op-based CRDTs operate on the principle that if two users perform identical sequences of operations, the final state of the document should also be identical. To achieve this, each user saves all the operations performed on the data (Operations) and synchronizes these Operations with other users to ensure a consistent final state. A critical challenge in this approach is ensuring the order of Operations remains consistent, especially when parallel modification operations occur. To address this, Op-based CRDTs require that all possible parallel Operations be commutative, satisfying the final consistency requirement.

If you want to see how State-based CRDT works, and other more in-depth content welcome to read the next chapter of this series How to design CRDT.

Comparison of CRDT and OT

Both CRDT and Operation Transformation(OT) can be used in online collaborative applications, with the following differences

OT	CRDT
OT relies on a centralized server for collaboration; it is extremely difficult to make it work in a distributed environment	CRDT algorithm can be used to synchronize data through a P2P approach synchronization
The earliest paper on OT was presented in 1989	The earliest paper on CRDT appeared in 2006
The OT algorithm is designed with higher complexity to ensure consistency	The CRDT algorithm is designed to be simpler to ensure consistency
It is easier to design OT to preserve user intent	It is more difficult to design a CRDT algorithm that preserves user intent
OT does not affect document size	CRDT documents are larger than the original document data

More related discussions can be found in

Addressed and Unresolved Issues

This section was last updated in December 2021

Why do we still see OT algorithms rather than CRDTs in most collaborative software? First, because CRDT is a relatively young method compared to OT, and some of the difficulties have only been solved in recent years, e.g.

How to make the merge result of conflicting edits meet the user’s intents as much as possible (this problem is often easier in OT than in CRDT)
- Related paper Interleaving anomalies in collaborative text editors.
CRDT Move
- A highly-available move operation for replicated trees
- Moving Elements in List CRDTs
How to achieve high-performance CRDTs

There is still a lot of research to be done in the following areas

CRDTs often have tombstone data that is difficult to recycle, how can we do it better?
How to reduce the overhead of updating CRDT documents?

Start Using CRDTs Today

You don’t need to design and implement CRDT algorithms from scratch (CRDTs can be easily implemented poorly). Instead, you can build your application directly on top of open-source CRDT projects such as Automerge, Yjs, and the one I am currently developing, Loro. You can view their performance comparison here.

Extended reading

Marc Shapiro, Nuno Preguiça, Carlos Baquero and Marek Zawirski, Conflict-free replicated data types (2011 paper formally defining CRDTs)
Petru Nicolaescu, Kevin Jahns, Michael Derntl and Ralf Klamma, Near Real-Time Peer-to-Peer Shared Editing on Extensible Data Types (Yjs paper)
Martin Kleppmann, Alastair R. Beresford, A Conflict-Free Replicated JSON Datatype (Automerge)
Martin Kleppmann, CRDTs The Hard Parts
Seph, 5000x faster CRDTs: An Adventure in Optimization

Go to the next chapter: How to Design a CRDT Algorithm

CRDT 简介

Tue, 21 Dec 2021 22:00:02 GMT

English version

CRDT (conflict-free replicated data type) 无冲突复制数据类型，是一种可以在网络中的多台计算机上复制的数据结构，副本可以独立和并行地更新，不需要在副本之间进行协调，并保证不会有冲突发生。

CRDT 常被用在协作软件上，例如多个用户需要共同编辑/读取共享的文档、数据库或状态的场景。在数据库软件，文本编辑软件，聊天软件等都可以用到它。

CRDT 解决了什么问题
起源
简单的 CRDT 案例
原理简介
CRDT 和 OT 的对比
已解决的问题 \& 目前还存在的问题
现在开始使用 CRDT
扩展阅读

CRDT 解决了什么问题

例如多用户在线同时编辑同一篇文档的场景

这个场景要求每个用户看到的内容都是一样的，即使在用户出现冲突编辑后（例如两个用户同时修改标题，两个请求同时到达服务器）也不会产生两个版本，这被称为一致性。（准确地说 CRDT 满足的是最终一致性，见下文详述）

CRDT 让用户即使离线也可使用，并在恢复网络后能继续和所有人同步至一致的状态。也可以和其他用户通过 P2P 的方式一起协同编辑。这被称为分区容错性。这让 CRDT 可以很好地支持去中心化的应用：即使没有中心化服务器各端之间也能完成同步。

起源

CRDT 的正式定义出现在 Marc Shapiro 2011 年的论文 Conflict-free replicated data types 中(而2006 的Woot可能是最早的研究)。提出的动机是因为最终一致性(Eventual Consistency) 的冲突解决设计很困难，很少有文章给出设计指导建议，而随意的设计的方案容易出错。所以这篇文章提出了简单的、理论证明的方式来达到最终一致性，也就是 CRDT。

(PS: 其实 Marc Shapiro 在 2007 年就写了一篇 Designing a commutative replicated data type，2011 年将 commutative 变成了 conflict-free，在其定义上扩充了 State-based CRDT)

根据 CAP 定理，对于一个分布式计算系统来说，不可能同时完美地满足以下三点：

一致性（Consistency）: 每一次读都会收到最近的写的结果或报错；表现起来像是在访问同一份数据
可用性（Availability）: 每次请求都能获取到非错的响应——但是不保证获取的数据为最新数据
分区容错性（Partition tolerance）: 以实际效果而言，分区相当于对通信的时限要求

系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择，所以「完美的一致性」与「完美的可用性」是冲突的。

CRDT 不提供「完美的一致性」，它提供了强最终一致性 Strong Eventual Consistency (SEC) 。这代表进程 A 可能无法立即反映进程 B 上发生的状态改动，但是当 A B 同步消息之后它们二者就可以恢复一致性，并且不需要解决潜在冲突（CRDT 在数学上就不让冲突发生）。而「强最终一致性」是不与「可用性」和「分区容错性」冲突的，所以 CRDT 同时提供了这三者，提供了很好的 CAP 上的权衡。

CRDT 满足 A + P + Eventual Consistency；是 CAP 下很好的权衡

(PS: 在 2012 年，CAP 定理的作者 Eric Brewer 写了一篇文章CAP Twelve Years Later: How the “Rules” Have Changed，解释了“CAP 特性三选二” 的描述其实具有误导性，实际上 CAP 只禁止了设计空间的很小一部分即存在分区时的完美可用性和一致性；而实际上在 C 和 A 之间的权衡的设计非常灵活，CRDT 就是一个很好的例子。)

简单的 CRDT 案例

我们可以通过几个简单的例子来大致理解 CRDT 类算法达到 Strong Eventual Consistency 的思路。

Grow-only Counter

如何在分布式系统中不加锁地统计一件事情的发生次数呢？

让每个副本只能递增自己的计数器 => 不用加锁同步 & 不会发生冲突
每个副本上同时保存着所有其他副本的计数值
发生次数 = 所有副本计数值之和
因为每个副本都只会更新自己的计数值，不会与其他计数器产生冲突，所以该类型在消息同步后便满足一致性

Grow-only Set

Grow-only Set 当中的元素是只能增加不能减少的
将两个这样的状态合并就只需要做并集
因为元素只增不减，不存在冲突操作，所以该类型在消息同步后便满足一致性

上述两种方法都是 CRDT。他们都满足以下性质

他们都可以被独立并发地更新，而不需要副本之间进行协调（加锁）
多个更新之间不可能发生冲突
总是可以保证最终一致性

原理简介

CRDT 有两种类型：Op-based CRDT 和 State-based CRDT，此处仅介绍 Op-based 的思路。

Op-based CRDT 的思路为：如果两个用户的操作序列是完全一致的，那么最终文档的状态也一定是一致的。所以索性各个用户保存对数据的所有操作(Operations)，用户之间通过同步 Operations 来达到最终一致状态。但我们怎么保证 Op 的顺序是一致的呢，如果有并行的修改操作应该谁先谁后？所以 Op-based CRDT 要求可能并行的 Op 都是可交换的，由此就可以满足最终一致性的要求。

如果想看 State-based CRDT 的原理，以及其他更深入的内容欢迎阅读本系列下一章如何设计 CRDT。

CRDT 和 OT 的对比

CRDT 和 Operation Transformation(OT) 都可以被用于在线协作型的应用中，二者的差别如下

OT	CRDT
OT 依赖中心化服务器完成协作; 如果想要让它在分布式环境中工作就异常困难	CRDT 算法可以通过 P2P 的方式完成数据的同步
OT 最早的论文于 1989 年提出	CRDT 最早的论文出现于 2006 年
为保证一致性，OT 的算法设计时的复杂度更高	为保证一致性，CRDT 算法设计更简单
OT 的设计更容易保留用户意图	设计一个保留用户意图的 CRDT 算法更困难
OT 不影响文档体积	CRDT 文档比原文档数据更大

更多相关讨论可看

已解决的问题 & 目前还存在的问题

此部分内容最后更新时间为 2021 年 12 月

为什么目前在协作软件中大多数看到的还是应用 OT 算法而不是 CRDT 呢？首先因为 CRDT 这类方法相比 OT 还比较年轻，而且有些难点近几年才被比较好地解决，例如：

如何让存在冲突的编辑的合并结果尽量符合用户预期（这个问题上用 OT 设计往往比 CRDT 更容易，CRDT 本身只保证一致性，让合并的结果符合预期是需要专门设计的）
- 相关论文 Interleaving anomalies in collaborative text editors
CRDT Move
- A highly-available move operation for replicated trees
- Moving Elements in List CRDTs
如何实现高性能的 CRDT

而目前在以下方面的研究还有待展开

CRDT 中常常存在难以回收的墓碑数据，如何才能更好地回收 CRDT 的墓碑？
如何降低更新 CRDT 文档的开销？

现在开始使用 CRDT

你不用自己从头开始设计和实现 CRDTs 算法（CRDT 很容易被实现得很糟糕）。你可以直接基于开源 CRDTs 项目来搭建你的应用例如 Automerge, Yjs 以及我正在研发的 Loro。你可以在这里查看它们的性能对比。

扩展阅读

Marc Shapiro, Nuno Preguiça, Carlos Baquero and Marek Zawirski, Conflict-free replicated data types (2011 正式定义 CRDT 的论文)
Petru Nicolaescu, Kevin Jahns, Michael Derntl and Ralf Klamma, Near Real-Time Peer-to-Peer Shared Editing on Extensible Data Types ( Yjs 论文)
Martin Kleppmann, Alastair R. Beresford, A Conflict-Free Replicated JSON Datatype (Automerge)
Martin Kleppmann, CRDTs The Hard Parts
Seph, 5000x faster CRDTs: An Adventure in Optimization

前往下一章：如何设计 CRDT 算法

Throwable - 在 TypeScript 中类型安全地处理 Error

Sun, 22 Aug 2021 22:00:02 GMT

在 ts/js 中我们一般通过 throw, try..catch 来处理 error，但是这种方式无法保证类型安全: 一个 function 无法告诉使用者它可能出现的必须要被处理的问题。这很大程度限制了 lib 开发者的表达能力：因为没处理的 throw 可能会导致应用崩溃，所以在出现无法处理的情况时直接 return undefined 可能是更好的选择。

但是我们可以借鉴 Haskell 和 Rust 当中处理异常的方式。这两门语言都没有提供 try…catch 的方法，而是通过一种特殊的函数返回类型来表达异常。在 Haskell 中用了一种数据结构：Either，它在 Rust 中被称为 Result。例如下面除法的例子，函数的返回值是 Result 类型，而不直接是数字。

fn div(x: u32, y: u32) -> Result<u32, &str> { 
  if y == 0 {
    return Err("divZero");
  }

  return Ok(x / y);
}

Result 类型不像 throw 出的 Error 会自动向上冒泡，而是将这个冒泡的流程交给开发者进行。Rust 提供了很多 Utils 函数来方便上层的程序对其进行处理。

有的小伙伴可能会问，T | undefined 或者 T | Error 好像也能解决问题？确实能解决类型标注上的问题，但是这样使用起来笨拙很多，会有很多重复性的代码。

Throwable

我借鉴 Rust 和 Haskell 实现了 Throwable。在概念上 Throwable 和 Rust 的 Result 是一样的，改称为 Throwable 主要是考虑理解成本。

使用方式

import {Ok, Err, Throwable} from '@typ3/throwable'
// in deno
import {Ok, Err, Throwable} from 'https://deno.land/x/throwable@v0'

function parse(input: string): Throwable<string[], 'invalid'> {
  const ans = []
  if (!input.startsWith('{')) {
    // Rather than `throw new Error()`
    return Err('invalid');
  }

  ...

  return Ok(ans);
}

使用对比

对于 Throw 的方案来说它有什么更方便的地方呢？假设我们有以下需求

给一个 JSON 文件路径列表，读取解析并返回其中 name 字段的值
如果解析错误则跳过
如果文件不存在则尝试增加后缀 .bk
如果出现文件不存在 / 解析错误之外的错误，则需要将 Error 抛出

传统方式的实现

class NotExistsError extends Error{...}
class ParseError extends Error{...}

function readJsonFile<T = Object>(path: string): T{
  ...
}

async function readName(path: string, shouldRetry=true): string | undefined{
  try {
    return (await readJsonFile(path)).name;
  } catch (e) {
    if (e instanceof NotExistsError) {
      if (shouldRetry) {
        return readName(path + '.bk');
      }

      return;
    } else if (e instanceof ParseError) { 
      return;
    }

    throw e;
  }

  return;
}

function getValidNames(paths: string[]): Promise<string[]> {
  return Promise.all(paths.map(readName)).filter(x => x != null);
}

Throwable 的实现

type MThrowable = Throwable<T, 'notExists' | {type: 'parseError', msg: string} >;

function readJsonFile<T = Object>(path: string): Promise<MThrowable>{
  ...
}

async function readName(path: string): Promise<MThrowable>{
  let result = await readJsonFile(path);
  if (result.error === 'notExists') {
    result = await readJsonFile(path + '.bk');
  }

  return result.pipe(x => x.name);
}

function getValidNames(paths: string[]): Promise<string[]> {
  return Promise.all(paths.map(readName)).filter(x => x.isOk());
}

Throwable 项目地址

Comlink 源码解析

Thu, 20 May 2021 22:00:02 GMT

Web Workers 简介

Web Worker 为 Web 内容在新线程中运行脚本提供了一种简单的方法，线程可以与主进程并行而避免阻塞渲染和交互。对于计算量大，容易造成页面卡顿（耗时 > 16ms）的任务我们可以考虑将它们移至 Worker 进行计算。

根据 CanIUse Web Workers 的覆盖率已经到了 98%。有人会担心和 Worker 通信造成的卡顿，可参考该 Benchmark

通信内容	耗时 MacBook Pro (13-inch, M1, 2020) - Chrome	耗时 Huawei Mate 10 Pro - Chrome
10B 字符串	5us	5us
1MB 字符串	200us	3ms
10MB 字符串	2ms	35ms

简单通信就只需要 5 微秒左右，而大字符串的传输也接近内存拷贝速度（如果是结构化数据，在这个数据量上可能更多耗时会在 JSON 的解析上）。大家可以根据自己的通信频繁程度，通信内容大小判断是否适合通过 Web Workers 进行优化。

虽然 Web Worker 很好，在平常却常常容易因为在通信上处理上过于麻烦，打包不方便等原因不怎么使用它。

Comlink 解决了其中通信的问题，它通过 Proxy 让你几乎可以忽略其中的通信细节，极大降低了 Worker 的维护成本。

Comlink 介绍

使用案例 - 通过 Comlink 实现简单的插入和查询

假如有以下场景的需求

有几十万条数据，每条数据有大约一百个字符
数据会不停地发生变动，比如新增一条数据/删除一段数据
用户需要在这些数据中完成搜索

在前端中实现这项功能，如果不通过 Worker 就需要自己完成时间分片来避免阻塞 UI。并且如果主进程此时还有其他类似的繁忙任务在进行就很容易产生卡顿，就需要考虑引入 Scheduler 的模块进行优先级划分。通过 Worker 就可以避免这些麻烦，且有更高的搜索效率。

下面我们通过两种不同的方式，实现在 Worker 上的简单插入和查询。

直接通过 Web Worker API 的方式实现这个需求：

Main.js

// 通过原生 API 实现 Worker 上插入和查询
const worker = new Worker("./normal/worker.js");

let _id = 0;
// 需要通过 id 标识一个请求消息，从而能够知道 response 对应的请求
function getId() {
  return _id++;
}

// 通过 id 创建 response promise
function createPromise(id) {
  return new Promise((r) => {
    const listener = (e) => {
      if (e.data.id === id) {
        r(e.data.value);

        worker.removeEventListener("message", listener);
      }
    };
    worker.addEventListener("message", listener);
  });
}

export function insert(s) {
  const id = getId();
  const promise = createPromise(id);

  worker.postMessage({
    id,
    value: s,
    type: "insert",
  });
  return promise;
}

export function search(query) {
  const id = getId();
  const promise = createPromise(id);

  worker.postMessage({
    id,
    type: "search",
    value: query,
  });

  return promise;
}

Worker.js

/** @type {{id: string, str: string}[]} */
const arr = [];
onmessage = (e) => {
  if (e.data.type === "insert") {
    arr.push(e.data.value);
    self.postMessage({
      // 返回中带上请求的 id
      id: e.data.id,
    });
  } else if (e.data.type === "search") {
    /** @type {typeof arr} */
    const ans = [];
    const value = e.data.value;
    arr.forEach((x) => {
      if (x.str.includes(value)) {
        ans.push(x);
      }
    });
    self.postMessage({
      // 返回中带上请求的 id
      id: e.data.id,
      value: ans,
    });
  }
};

通过 Comlink 实现该需求：

main.js

// 通过 Comlink 实现 Worker 上插入和查询
import * as Comlink from "https://unpkg.com/comlink/dist/esm/comlink.mjs";

const DataProcessor = Comlink.wrap(new Worker("./comlink/worker.js"));
let processor = await new DataProcessor();

export async function insert(s) {
  await processor.insert(s);
}

export async function search(s) {
  return await processor.search(s);
}

worker.js

importScripts("https://unpkg.com/comlink/dist/umd/comlink.js");

class DataProcessor {
  arr = [];
  constructor() {}

  insert(...s) {
    this.arr.push(...s);
  }

  search(target) {
    const ans = [];
    for (const value of this.arr) {
      if (value.str.match(target)) {
        ans.push(value);
      }
    }

    return ans;
  }
}

Comlink.expose(DataProcessor);

对比二者我们可以发现：

通过 Comlink 实现的 Worker 的代码和普通代码几乎无差异，对通信过程无感知
直接通过 Web Worker 实现需要自己管理繁琐的通信过程。如果没有封装自己的 Worker 管理模块则 Worker 内的复杂度很难维护

除了上面的好处之外，通过 Comlink 我们甚至可以传递函数，例如

main.js

...

export async function map(callback) {
  return processor.map(Comlink.proxy(callback));
}

async function test() {
  await insert({id: '0', str: 'hello'})
  await insert({id: '1', str: 'value'})
  console.log(await map(x => x.str.toUpperCase())); 
  // OUTPUT: ['HELLO', 'VALUE']
}

worker.js

class DataProcessor {
  ...

  map(callback) {
    return Promise.all(this.arr.map(callback));
  }
}

为什么通过 Comlink 还能够在 Worker 和主进程间传递函数呢？这个函数甚至还能带有原进程的闭包，这是如何做到的呢？请看下一节详解

原理解析

前置知识 - Channel Messaging API ✉️

为了理解 Comlink 的基本原理我们首先要认识 Channel Messaging API。

Channel Messaging API 允许两个不同的脚本运行在同一个文档的不同浏览器上下文（Browsing Context, 比如两个 iframe，或者文档主体和一个 iframe，使用 SharedWorker 的两个文档，或者两个 worker）来直接通讯，在每端使用一个端口（port）通过双向频道（channel）向彼此传递消息。

new MessageChannel() 返回 port1 port2, 二者之间通过 postMessage / onmessage 可以进行通信。通过 postMessage 的方式我们能够将 port 转移到其他的 Browsing Context 上（转移之后它们就从原来的上下文中消失了）。

var channel = new MessageChannel();
var iframe = document.querySelector('iframe');

// Listen for messages on port1
channel.port1.onmessage = function onMessage(e) {
  console.log(e.data);
}

// Transfer port2 to the iframe
iframe.contentWindow.postMessage('Hello from the main page!', '*', [channel.port2]);

为什么要通过 Channel Messaging 进行通信，而不是直接使用 Worker 的 message event 和 postMessage 呢？

通过 Channel Messaging 我们能让 Worker 和 Worker 直接通信，而不需要经过主进程
新建 Channel 可以避免消息冲突。例如 Comlink 的实现中就会新建 port 来 expose 不同的对象

🕶 Comlink 是如何实现的

(本文的摘录的源码中过滤了不重要的细节，和真实源码略有出入)

下面将针对几个问题逐个剖析

如何通信
- 如何向”传递“一个函数？（Comlink.proxy 是如何实现的）
如何做到无感知的操作 worker 的对象的（只需要加 await 前缀 🧐）
- await workerObject.value 就能够拿到 worker 的 obj 的 value
- workerObject.value = 123 就能直接赋值给 worker 的 workerObject.value
- await new WorkerConstructor() 就创建一个对象

如何通信

在 Comlink 的实现中，主动发送消息时都通过 requestResponseMessage 函数发送，而回复消息时直接通过 ep.postMessage，为了表示回复的是哪一个消息所以需要带上额外的 id 标识。

function requestResponseMessage(
  ep: Endpoint,
  msg: Message,
  transfers?: Transferable[]
): Promise<WireValue> {
  return new Promise((resolve) => {
    // 随机生成一个 uuid， 回复消息时需要带上这个 id
    const id = generateUUID(); 
    ep.addEventListener("message", function l(ev: MessageEvent) {
      // 消息中的 id 不匹配代表回复的不是此次请求
      if (!ev.data || !ev.data.id || ev.data.id !== id) {
        return;
      }
      ep.removeEventListener("message", l as any);
      resolve(ev.data);
    } as any);
    if (ep.start) {
      ep.start();
    }
    ep.postMessage({ id, ...msg }, transfers);
  });
}

如何在进程间传递数据

在 Comlink.expose Comlink.createProxy 的代码中我们都会看到 fromWireValue toWireValue 两个函数的身影。例如

在 setter 中，就会将原始数据 toWireValue 封装之后再通过 postMessage 发送
接收方收到消息后，会将数据通过 fromWireValue 再转换为可操作的原始数据

为什么需要这样的操作呢？直接通过默认的通信方法把 value 塞过去不就好了吗？

这就涉及了 Comlink 的高级 feature：支持跨进程“传递”带原进程闭包的函数/带有这种函数的对象。例如上文的例子中我们可以 const processor = await new DataProcessor() 来创建一个来自于 Worker 的对象。其中 DataProcessor 是定义于 Worker 上的 constructor，processor 也是存在 Worker 进程上，而主进程拿到的只是操作 Worker 中的 processor 的本体的句柄：processor.search processor.insert 等操作都是在 worker 上运行的, 查询/插入的数据也都处于 Worker 进程上。

toWireValue & fromWireValue 是如何做成这样的事的呢？首先让我们来回顾以下几个要点：

首先我们定义好消息的传输终端 Endpoint 类型。它能够通过 postMessage 发送消息，包含了 Worker 和 Chanel Messaging API 中的 port

export interface Endpoint extends EventSource {
  postMessage(message: any, transfer?: Transferable[]): void;
  start?: () => void;
}

export interface EventSource {
  addEventListener(
    type: string,
    listener: EventListenerOrEventListenerObject,
    options?: {}
  ): void;

  removeEventListener(
    type: string,
    listener: EventListenerOrEventListenerObject,
    options?: {}
  ): void;
}

我们知道 Comlink 中有一个 expose 函数, 让一个 object 能够被 Endpoint 上收到的消息所控制

export function expose(obj: any, ep: Endpoint = self as any) {
  ep.addEventListener("message", function callback(ev: MessageEvent) {
    ...
  }
}

我们也知道 Comlink 中有一个 wrap 函数, 能够封装一个代理，读取/控制被 expose 暴露到 endpoint 的对象。

export function wrap<T>(ep: Endpoint, target?: any): Remote<T> {
  return createProxy<T>(ep, [], target) as any;
}

在 new MessageChannel() 后我们得到的两个 port，两个 port 之间是能够通过 postMessage, addEventListener('message', (ev) => {...}) 进行通信的。且在上文的 Channel Messaging API 的介绍中提到了，port 是能够被转移给另外一个进程的。

结合以上四点，如果我们在进程 A 中想把一个带闭包的函数 / 带这样的函数的对象 fn 传递给进程 B，只需要

在进程 A expose(fn, port1)
在进程 B const handler = wrap(port2)

从而在进程 B 中就能通过 handler 去做需要的处理了。例如

在 B 中直接调用这个函数 handler()
这个调用操作的行为就会被转发到 A 进程中
A 执行 fn()
返回值被异步返回给 B

这个设计很巧妙的一点就是能够递归地利用 wrap & expose 的能力。例如

在 B 进程中 handler.value = callback，其中 callback 是一个函数
这个 set 操作会被同步到进程 A，所以这个 callback 也需要被包装
这个 callback 会在进程 B 上被 expose(callback, port1)
port2 会被传递到进程 A，在进程 A 上被 wrap(port2)，得到进程 B 的 callback 的 handler

从而 toWireValue / fromWireValue 的实现就不难推测了：

对于基本类型（plain object，string，number），直接通过默认的 worker 方式传递即可
对于需要被代理的对象（例如带闭包的函数），就需要通过新建 MessageChannel 传递 port，进行 expose & wrap 的方式进行
- 在默认情况下不会代理函数，需要通过 Comlink.proxy(callback) 包装的函数才会被 expose & wrap 的方式传递到另外一个进程

/*
 * 在传递一个值时（setter, 函数参数传递, 传递函数返回值）
 * 会在原进程通过 toWireValue 封装, 
 * 接收消息的进程通过 fromWireValue 解析
 */

function toWireValue(value: any): [WireValue, Transferable[]] {
  for (const [name, handler] of transferHandlers) {
    if (handler.canHandle(value)) {
      const [serializedValue, transferables] = handler.serialize(value);
      return [
        {
          type: WireValueType.HANDLER,
          name,
          value: serializedValue,
        },
        transferables,
      ];
    }
  }
  return [
    {
      type: WireValueType.RAW,
      value,
    },
    transferCache.get(value) || [],
  ];
}

function fromWireValue(value: WireValue): any {
  switch (value.type) {
    case WireValueType.HANDLER:
      return transferHandlers.get(value.name)!.deserialize(value.value);
    case WireValueType.RAW:
      return value.value;
  }
}

export const transferHandlers = new Map<
  string,
  TransferHandler<unknown, unknown>
>([
  ["proxy", proxyTransferHandler],
  ...
]);

const proxyTransferHandler: TransferHandler<object, MessagePort> = {
  // 只有带了 proxyMarker 的 obj 才会用 proxy 的方式封装
  canHandle: (val): val is ProxyMarked =>
    isObject(val) && (val as ProxyMarked)[proxyMarker],
  serialize(obj) {
    /**
      * 新建 MessageChanel
      * 在原进程 expose(obj, port1)
      * 在接收消息的进程 wrap(port2)
      */ 
    const { port1, port2 } = new MessageChannel();
    expose(obj, port1);
    return [port2, [port2]];
  },
  deserialize(port) {
    port.start();
    return wrap(port);
  },
};

如何做到无感知地操作 Worker 的对象的

你可能已经猜到是通过 Proxy 实现的。如果你对 Proxy 不熟可以先看看 Proxy 的 MDN 文档。

但是它又是如何通过 Proxy 完成这样的代理的呢？

在 Worker 中我们通过 Comlink.expose(obj) 选择暴露一个对象，而在主进程中我们通过 Comlink.wrap(worker) 获取到这个对象。

所以可以推测出 wrap 操作返回了一个 Proxy 对象，将操作变为对 worker 的 postMessage，而 expose 则增加了 message 事件的 listener，将收到的消息转为操作。

我们可以通过不同的操作类型的实现具体展开

Getter 的实现

Comlink.wrap 的实现是直接基于 createProxy 的

export function wrap<T>(ep: Endpoint, target?: any): Remote<T> {
  return createProxy<T>(ep, [], target) as any;
}

createProxy 的实现则是封装了一个 Proxy

function createProxy<T>(
  ep: Endpoint,
  path: (string | number | symbol)[] = [],
  target: object = function () {}
): Remote<T> {
  let isProxyReleased = false;
  const proxy = new Proxy(target, {
    /**
      * proxy.a 会调用 get 函数, 此时的函数参数：
      * 
      * _target 等于 target
      * prop    等于 'a'
      */
    get(_target, prop) {
      // 当调用 await proxy 时，prop 等于 'then'
      if (prop === "then") {
        if (path.length === 0) {
          return { then: () => proxy };
        }
        const r = requestResponseMessage(ep, {
          type: MessageType.GET,
          path: path.map((p) => p.toString()),
        }).then(fromWireValue);
        return r.then.bind(r);
      }

      // 递归创建 Proxy，将 prop 推入 path 的末尾
      return createProxy(ep, [...path, prop]);
    },
    ...
  }

  return proxy as any;
}

此处比较神奇的是 if (prop === 'then') 条件语句下的处理，为什么这样的处理能够让 await proxy.value 就能够直接拿到 worker 当中的值呢？这就要从 await xxx 在 Proxy 当中的处理说起。

根据 ECMAScript® 2022 Language Specification 中 await 的描述:

await value 在内部实现中会变成 await Promise.resolve(value)
而 Promise.resolve 的处理中则会获取 value.then 的值，如果它是一个函数则会通过它创建一个 Promise Job。

所以下面这个例子中 ans 等于 100

const ans = await {
  then: (resolve, reject) => {
    resolve(100);
  }
}

// ans = 100

从而在 await proxy 时会触发 Proxy 的 getter，获取的属性等于 'then'。 await proxy.a 在 proxy 的 getter 中最终会走到下面这段代码

const r = requestResponseMessage(ep, {
  type: MessageType.GET,
  path: path.map((p) => p.toString()), // path = ['a']
}).then(fromWireValue); // 解析 Response 的返回值
return r.then.bind(r); // 该返回值会被用于创建 Promise Job

这个发送的消息被 Worker 收到后的处理被写在了 Comlink.expose 函数中:

export function expose(obj: any, ep: Endpoint = self as any) {
  ep.addEventListener("message", function callback(ev: MessageEvent) {
    const { id, type, path } = ev.data
    try {
      const rawValue = path.reduce((obj, prop) => obj[prop], obj);
      switch (type) {
        case MessageType.GET:
          {
            returnValue = rawValue;
          }
          break;
        ...
      }
    }
    const [wireValue, transferables] = toWireValue(returnValue);
    ep.postMessage({ ...wireValue, id }, transferables);
  }
}

Setter / Function Call / new 的实现

了解了 getter 的实现后，剩下的几种操作的实现就是类似的：

createProxy 中代理操作，将操作参数 toWireValue 后发送到 worker
worker 接收到操作，进行对应处理后返回所需要的值
原进程收到消息，将消息内容 fromWireValue 处理后返回给调用方（通过 Promise 封装）

function createProxy<T>(
  ep: Endpoint,
  path: (string | number | symbol)[] = [],
  target: object = function () {}
): Remote<T> {
  let isProxyReleased = false;
  const proxy = new Proxy(target, {
    ...
    set(_target, prop, rawValue) {
      const [value, transferables] = toWireValue(rawValue);
      return requestResponseMessage(
        ep,
        {
          type: MessageType.SET,
          path: [...path, prop].map((p) => p.toString()),
          value,
        },
        transferables
      ).then(fromWireValue) as any;
    },
    apply(_target, _thisArg, rawArgumentList) {
      // 多参数的 toWireValue
      const [argumentList, transferables] = processArguments(rawArgumentList);
      return requestResponseMessage(
        ep,
        {
          type: MessageType.APPLY,
          path: path.map((p) => p.toString()),
          argumentList,
        },
        transferables
      ).then(fromWireValue);
    },
    construct(_target, rawArgumentList) {
      // 多参数的 toWireValue
      const [argumentList, transferables] = processArguments(rawArgumentList);
      return requestResponseMessage(
        ep,
        {
          type: MessageType.CONSTRUCT,
          path: path.map((p) => p.toString()),
          argumentList,
        },
        transferables
      ).then(fromWireValue);
    },
    ...
  }

  return proxy as any;
}

Comlink.expose 中的相关实现

export function expose(obj: any, ep: Endpoint = self as any) {
  ep.addEventListener("message", function callback(ev: MessageEvent) {
    const { id, type, path } = ev.data
    try {
      const parent = path.slice(0, -1).reduce((obj, prop) => obj[prop], obj);
      const rawValue = path.reduce((obj, prop) => obj[prop], obj);
      switch (type) {
        case MessageType.SET:
          {
            // value 有可能是 port，需要通过 fromWireValue 处理
            // 详情见上文 「如何在进程间传递数据」
            parent[path.slice(-1)[0]] = fromWireValue(ev.data.value);
            returnValue = true;
          }
          break;
        case MessageType.APPLY:
          {
            returnValue = rawValue.apply(parent, argumentList);
          }
          break;
        case MessageType.CONSTRUCT:
          {
            const value = new rawValue(...argumentList);
            // 通过 proxy 标记这个 value 需要被 expose & wrap 封装
            // 详情见上文 「如何在进程间传递数据」
            returnValue = proxy(value);
          }
          break;
        ...
      }
    }
    const [wireValue, transferables] = toWireValue(returnValue);
    ep.postMessage({ ...wireValue, id }, transferables);
  }
}

Haskell 的无穷数组

Sat, 01 May 2021 22:40:32 GMT

Haskell是一种标准化的，通用的纯函数式编程语言，有惰性求值和强静态类型。因为有惰性求值，所以在 Haskell 中你可以创建一个无限数组。例如

[0..], 创建一个 0, 1, 2… 不断递增的数组
repeat 0, 创建一个全是 0 长度为正无穷的数组
let a = 1:2:a
- 创建一个数组 a，第一个元素是 1，第二个元素是2，剩下来的是 a （没错，可以递归定义）
- 得到一个 [1, 2, 1, 2, 1, 2…] 无限重复的数组

用无穷数组解序列问题

无穷数组对序列的描述能力很强。定义符号 ”++” 代表链接两个序列，那么

等差数列可以这样描述

f(a_0, b) = [a_0] ++ f(a_0 + b, b)

斐波那契数列的一般描述方式是

f(0) = 1 \newline f(1) = 1 f(n) = f(n -1) + f(n-2)

但通过递归的无穷数组的方式我们还可以这样表达

$f(a, b) = [a] ++ f(b, a +b)$
斐波那契数列 = $f(1, 1)$

对于下面这道题也可以用递归的方法描述

原题链接

先卖个关子，看看普通的解决思路是什么样的。

一般解法（TypeScript）

通过链表实现。

Haskell 解法

看起来简单很多有没有！

理解 Haskell 解法

为了方便理解，我们可以泛化序列 u 的定义到 f(n)

在这个定义下，我们需要的序列 u 就等于排序后的 f(1)。

可以注意到 f(n) 符合这样的性质：

f(n) = \{n\} \cup f(2n + 1) \cup f(3n+1)

Haskell 的解法可以理解为通过无穷数组去描述了这个递归的性质。

因为 Haskell 的语法比较与众不同，为了方便理解，下面是将它朴素地翻译成 JS 之后的样子

next 对应上文提到的 $f(n)$ 。next 中的递归是没有边界条件的，在没有惰性求值特性的 JS 当中就会死循环。而在 Haskell 中，一个数组被定义后其中的值是没有被求出来的，只有当其中的值被最外层的 IO 获取的时候才会去计算具体的值。

而在 JS 中我们是否有语言特性可以实现惰性求值呢？也有！那就是 Generator 。所以我们可以通过 Generator 构造一个类似的解

在 JS 中通过 Generator 模仿无穷数组

通过无穷数组我们就可以通过 f(n) 的性质 $f(n) = \{n\} \cup f(2n + 1) \cup f(3n+1)$ 实现：

性能对比

通过 Generator 的方式在性能上一定会有所损耗，以下是 index = 1e6 时的耗时对比。

性能还是比 Haskell 好的！

在 JavaScript 中实现一个惰性数组

Specification

刚刚的例子中我们仅通过 Generator 模仿了 Haskell 解法，那有没有可能在 JS 当中封装一个惰性数组呢？它需要符合以下规格

值的计算是 Lazy 的
已经被计算的值会被缓存
长度可以是无穷大的
数组内容不能被改变
可获取长度
可以连接几个惰性数组，产生一个新的惰性数组
可被遍历
可获取指定下标的元素
定义可以是递归的

从而我们可以这样使用它

v0. 递归 Generator

朴素的 LazyArray 实现（容易爆栈） LazyArray@v0

直接通过递归地调用 self generator 函数就可以完成~

但这个实现方式有一个问题：太容易爆栈了，例如下面的代码就会直接导致溢出。

因为在递归的方式中调用栈是这样的

而栈的深度有限，根据宿主环境不同在几千到几万不等。

v1. 防爆栈优化（存在 Bug）

那有什么方法可以解决这样的爆栈问题呢 —— 将递归转为迭代。

但 LazyArray 的定义是要支持递归的。有什么方法可以让一个递归的定义通过迭代的方式来表达呢？我们可以替换递归过程中使用的函数~

此时我们的调用过程如下图所示，调用栈始终只有一层。

这下怎么都不会溢出了~

emmmmmm，但是这个版本是有 Bug 的。因为这个优化假设了每个 self 函数中 yield 的值都是会被 yield 到最外层的。例如在进行了这一项优化后，下面的例子中的 map 就起不了作用了

因为我们将其中的 self(n) 的 Generator 屏蔽了，导致 map 拿到了空的序列。

所以在进行这项优化时我们还需要判断下一个 self 函数返回的 Generator 是不是直接被上一层的 self 函数的 Generator 消费的。只有这样我们才能进行优化。

v2. 符合条件才进行转递归为迭代

使用它重新解一遍 Twice Linear 也是可以的（😅 写起来的复杂度没啥变化）

import { LazyArray } from "https://raw.githubusercontent.com/zxch3n/lab/master/lazy-array/lazy-array.ts";

function* merge(a: Iterator<number>, b: Iterator<number>) {
  let va = a.next().value!;
  let vb = b.next().value!;
  while (true) {
    if (va < vb) {
      yield va;
      va = a.next().value;
    } else if (va > vb) {
      yield vb;
      vb = b.next().value;
    } else {
      yield vb;
      va = a.next().value;
      vb = b.next().value;
    }
  }
}

const f = LazyArray.createFactory<number, number>((n: number, self) => {
  return LazyArray.concat([n], merge(self(2 * n + 1), self(3 * n + 1)));
});

const ans = f(1);
export function solve(i: number) {
  return ans.get(i);
}

LazyArray 的实现：zxch3n/lab

TwiceLinear 相关代码：zxch3n/blog