Kotlin Multiplatform 中的 CRDTs：干掉你的同步服务器

大多数团队都会构建一个中央服务器来处理数据冲突。服务器接收写入操作，选出一个“胜者”，然后祈祷一切顺利。这会造成单点故障，并带来复杂的维护代码。

无冲突复制数据类型 (CRDTs) 改变了这一点。无需中央控制，每个设备都能达到相同的状态。这是一种数学上的保证。

你可以用简单的 blob 存储来替换同步后端。你的服务器变成了一个持有数据 blob 的中继器。它不需要理解你的数据。

在你的移动应用中使用这些原语：

• LWW-Register：用于用户资料和设置。 • G-Counter：用于分析或浏览量统计。 • PN-Counter：用于库存或购物车总量。 • OR-Set：用于标签和收藏。

对于大多数移动应用，LWW-Registers 和 OR-Sets 几乎可以涵盖所有场景。

Implementation Tip: 在构建 LWW-Register 时，务必包含一个 nodeId。如果两次更新具有完全相同的时间戳，nodeId 将作为决胜因素。如果没有它，你的设备将无法同步到相同的状态。

State-based vs. Operation-based:

移动端请选择 State-based (CvRDT)。它在不可靠的网络环境下也能工作，因为合并过程是幂等的。如果同步中途失败，你只需重试即可。

早期阶段请避免使用 Operation-based (CmRDT)。它要求“精确一次” (exactly-once) 的交付。在移动网络上构建这种基础设施非常困难，并且会增加你想要避免的复杂性。

The Architecture:

  1. 在 Kotlin Multiplatform 项目的 commonMain 模块中构建你的 CRDT 逻辑。
  2. 使用 SQLDelight 在本地存储数据。
  3. 将数据 blob 同步到 S3 或 Cloud Storage 等服务。
  4. 你的后端将保持简单且廉价。

停止构建复杂的同步引擎吧。使用 CRDTs 将逻辑转移到客户端。这让你能够专注于构建功能，而不是管理服务器轮转。

Source: https://dev.to/software_mvp-factory/crdts-in-kotlin-multiplatform-kill-your-sync-server-28n8