系统与数据库2021martin.kleppmann.com编辑精选
Local-First Software：在云端时代依然拥有自己的数据（2019）
Local-First Software:You Own Your Data, in Spite of the Cloud (2019)
进阶 · 约 55 分钟读完前置知识：软件架构基础、分布式系统概念、CRDT/数据同步基础
导读
这是一篇（2019 年）关于「本地优先（local-first）软件」的立场论文：作者主张把用户设备上的数据副本当作主要、权威的那一份，云端服务器降为辅助，从而让应用在断网时仍可完整使用，并支持多设备协作与同步。论文讨论了实现这一目标所需的技术（如冲突消解、CRDT 一类的同步机制），并列举了本地优先在延迟、可靠性、隐私与数据所有权上的优势，以及与主流云应用架构的差距。
HN 关注点：是因为它系统论证了「为什么不该把本地数据只当缓存」，并触及离线可用性、数据所有权和现有 Web 应用架构的取舍。
后来怎么样
推广并普及了“本地优先软件”这一术语和理念，推动了 CRDT 同步工具与一批本地优先应用/框架的发展，成为该方向常被引用的纲领性文献。
HN 评论精选
这几条评论里：支持 1 补充 1 亲历 2
亲历本地优先在延迟和可靠性上常常是更优的技术选择，工业场景尤其不能依赖云端链路。
本地优先往往就是更好的技术方案。比如你在地图上标了一个停车位，想分享给就站在旁边的人，却因为连接 1000 公里外数据中心的网络不稳而失败，这就是糟糕的设计。想打印东西或让两台机器交互时也一样：任何被拉进来的远程第三方只会增加延迟、降低带宽、提高失败概率。我们在 actyx.com 做工厂车间软件时就采用本地优先，你肯定不希望工厂因为云端链路断了而停产。
rklaehn查看英文原文
Local first is often just plain the better technical solution. E.g. you put a pin on a map to mark the parking spot, and want to share it with somebody standing right next to you. But it does not work because the connection to some data center 1000 km away is flaky. This is just plain bad design. Or you want to print something or get two machines to interact. Any remote third party you bring into this interaction is going to increase latency, reduce bandwidth, increase the probability of failure, etc. That is why we use the local first approach for factory shop floor software at actyx.com . You don't want your factory to stop because the link to the cloud is down.
支持批评「离线支持」只是把本地当缓存，呼吁回归真正拥有数据的离线优先桌面应用，并指出创业公司偏爱 Web 的结构性原因。
第 2 节说：「在云应用中，服务器上的数据被视为主要、权威的副本；客户端即使有副本，也只是从属于服务器的缓存。」完全同意。那些号称支持离线的应用，其实只是把本地副本当缓存，应该叫「offline-also」而不是 offline-first。我怀念那种买下软件就真正拥有它的日子。离线优先应用也能协作，只是更难做。现在全是在线优先的 Web 应用，原因见 3.2.1 节；还有一个原因：创业公司验证想法时，做在线优先应用容易得多，只需要一个浏览器就能获客，等有起色后桌面应用又优先级很低。我想把离线优先的桌面应用带回来，已经做了 Brisqi 这个离线优先的个人看板应用，希望更多人采用这种思路。另外我觉得开发者社区需要做一个更好的、开源跨平台、许可宽松的框架来开发离线优先桌面应用。
ashdev查看英文原文
In section 2 it says - "In cloud apps, the data on the server is treated as the primary, authoritative copy of the data; if a client has a copy of the data, it is merely a cache that is subordinate to the server." Exactly! Local copy is just treated as cache in those apps which offer offline support. They are called "Offline-also" apps, not Offline-first apps. I miss those days when I could just buy the software and own it. Collaboration can happen in offline-first apps too, it's tricky but it can be done. Everything is online-first web apps these days because of the reasons listed in section 3.2.1. There is one more reason for popularity of online-only web apps: When startups are testing their idea, it's far easier to put together an online-first app than offline-first. It's easier to get traction comparatively because it just requires a browser. When they get some traction, then a desktop app is a low priority to them. I want to bring back offline-first desktop apps back. I've already started with Brisqi[1] an offline-first personal Kanban app. Hope more people take an offline-first approach. For similar reasons, I could write a whole essay on why we developers need to create a better open source cross-platform framework to develop offline-first desktop apps with permissive licensing. [1] https://brisqi.com
亲历一个真实产品案例：用本地 CouchDB + 可选双向同步实现本地优先，同时保留离线可用与备份能力。
我的 ezInvoice 最新版提供了本地优先选项，同时也是离线优先。用户要在自己电脑上装 CouchDB 才能用本地优先模式：只是换一个 html 文件去访问本地 CouchDB，而不是云端的 CouchDB。应用默认完全不用互联网，除非在偏好设置里打开「实时同步」，那时仍是本地优先，但会与我的云端 CouchDB 双向同步——云端有更新时会推送到桌面端（若离线则等联网后）。用户还可以在桌面 CouchDB 上做备份和快照。ezInvoice 是 2002 年发布的，这是我 Desde 那时就想做的事，现在终于能实现，感觉很好。
oblib查看英文原文
My latest version of my ezInvoice app has a local-first option. It's also offline first. The user has to install CouchDB on their desktop PC to use the local first option. Basically they just use a different html file to access the local CouchDB instead of the Cloud based CouchDB. The app is also offline first and doesn't use the internet at all unless you turn on the "Live Sync" function in the app's preferences. At that point it's still local first but it syncs with my Cloud based CouchDB and users can access that by using a different url. Since Live Sync works both ways whenever the Cloud CouchDB is updated those changes are pushed to the desktop PC if it's connected to the internet, or as soon as it is. Users can also make backups and snapshots of their DBs on their desktop CouchDB. I released ezInvoice back in 2002 and this is something I've wanted to do since then. Feels pretty good to have what's needed to get it working.
补充补充了更易阅读的 HTML 版链接。
这里是该文的 HTML 版本：https://www.inkandswitch.com/local-first.html
sjbrown查看英文原文
https://www.inkandswitch.com/local-first.html HTML version here
相关资源
从这篇论文所有 HN 讨论帖的全部评论里整理出来的链接。
历次讨论
- 2021Hacker News 讨论帖216 分 · 90 评
同领域还值得读
I/O 比 CPU 更快——让我们划分资源并消除操作系统抽象
I/O Is Faster Than CPU – Let’s Partition Resources and Eliminate OS Abstractions
指出在现代服务器硬件上 I/O 速度已接近甚至超过 CPU，传统操作系统抽象反而成为瓶颈。
系统与数据库2019 · 817 分 · 277 评进阶 · 约 30 分钟编辑精选使用 io_uring 的高效 I/O
Efficient IO with io_uring
由 Linux 内核开发者 Jens Axboe 撰写，介绍 Linux 新的异步 I/O 接口 io_uring。
系统与数据库2019 · 426 分 · 96 评进阶 · 约 45 分钟编辑精选线程对大多数用途而言是个坏主意（1995）
Threads Are a Bad Idea for Most Purposes (1995)
这篇 1995 年的文章由 John Ousterhout 撰写，讨论为什么线程对大多数用途而言是坏主意，并主张事件驱动编程通常更简单、更高效。
系统与数据库2017 · 423 分 · 382 评进阶 · 约 25 分钟编辑精选学习型索引结构之论证
The Case for Learned Index Structures
提出把索引看作一种"模型"：既然 B-tree 等结构本质上是在学习数据的分布，就可以用机器学习模型（如回归模型、神经网络）来近似键到位置的映射，从而替代 B-tree、哈希索引…
系统与数据库2017 · 398 分 · 66 评 · 引用 25进阶 · 约 60 分钟编辑精选FoundationDB：一个分布式、解耦的事务型键值存储
FoundationDB: A distributed, unbundled, transactional key value store
介绍 FoundationDB：一个分布式、解耦设计的事务性键值存储。
系统与数据库2021 · 283 分 · 99 评进阶 · 约 90 分钟编辑精选