2024年9月17日 (二) 13:16的版本

原文链接: https://www.bartoszsypytkowski.com/the-state-of-a-state-based-crdts/
作者: Bartosz Sypytkowski

（翻译）基于状态的CRDT简介

这是一个在以往的一些分享中已经谈论过的主题，但却从未写过。这里我想写一点关于CRDT（冲突无关复制数据类型）的内容：它要解决什么样的问题，并通过一些基本的代码实现（F#）来帮助你理解怎样去使用CRDT。

动机

CRDT是解决一个常见的分布式环境下数据同步问题的答案。尽管人们熟知分布式领域中的此类问题，在过去已经进行了许多尝试来解决，通常是去中心化的两阶段提交事物的变种。但他们无一例外有以下的问题：

我们的一个假设是，所有的参与者总是在事务发生期间是可用的，而经常这个假设恰恰是不成立的（比如在边缘计算和移动应用的场景中）
多阶段提交和使用议会制的方案需要在参与者之间进行多次往返通信。这附带带来延迟和吞吐量的开销。

而且，当机器增多或者通信距离增加时，这种方式有降低可扩展性的趋势。多数场景中，一旦跨越单个数据中心机房，使用分布式事务都是行不通的

这些方案通常确定一个单一的主节点来进行排他写操作，或者作为单一的数据源。

在某些情况下，比如上面提到的场景中，都是不可接受的。

@@ 第5行： / 第5行： @@
 </syntaxhighlight>
-= 基于状态的CRDT简介 =
+= （翻译）基于状态的CRDT简介 =
+<!--
+This is one of the topics I've already talked about on several presentations in the past, but never actually written about. Here I want to cover a topic of Conflict-free Replicated Data Types: what problems they aim to solve and provide some basic implementations (in F#) to help you understand how to build them.
+-->
+这是一个在以往的一些分享中已经谈论过的主题，但却从未写过。
+这里我想写一点关于CRDT（冲突无关复制数据类型）的内容：
+它要解决什么样的问题，并通过一些基本的代码实现（F#）来帮助你理解怎样去使用CRDT。
+==动机==
+<!--
+Conflict-free Replicated Data Types are answer for a common problem of synchronizing data in distributed environments. While issues on that field where well-known and there were numerous attempts to solve it in the past, usually they were a variants of decentralized 2-phase commit transactions. However they all suffer for similar problems:
+-->
+CRDT是解决一个常见的分布式环境下数据同步问题的答案。
+尽管人们熟知分布式领域中的此类问题，在过去已经进行了许多尝试来解决，
+通常是去中心化的两阶段提交事物的变种。
+但他们无一例外有以下的问题：
+<!--
+* We are assuming, that all participants are available for the time of the transaction, which often (i.e. in case of edge computing and mobile apps) is not true.
+* Multi-phase and quorum-based commits require numerous round trips between communicating parties. That comes with a cost in terms of latency and throughput. Moreover this approach has tendency to degrade at scale, when number of machines or distance between them increases. In many cases it's not feasible to use distributed transaction across boundaries of a single data center.
+* They often determine a single master node used for exclusive write access or as a single source of truth. In some cases - as the ones mentioned above - it's not a feasible solution.
+-->
+* 我们的一个假设是，所有的参与者总是在事务发生期间是可用的，而经常这个假设恰恰是不成立的（比如在[https://en.wikipedia.org/wiki/Edge_computing?ref=bartoszsypytkowski.com 边缘计算]和移动应用的场景中）
+* 多阶段提交和使用议会制的方案需要在参与者之间进行多次往返通信。这附带带来延迟和吞吐量的开销。
+而且，当机器增多或者通信距离增加时，这种方式有降低可扩展性的趋势。
+多数场景中，一旦跨越单个数据中心机房，使用分布式事务都是行不通的
+* 这些方案通常确定一个单一的主节点来进行排他写操作，或者作为单一的数据源。
+在某些情况下，比如上面提到的场景中，都是不可接受的。
+<!--
+This doesn't mean, that existing approaches are bad. However what we are striving for is to give a wider area of possible solutions, that may better fit the problem under certain conditions. One of the examples, that I like to use to visualize the problem is that:
+-->
 [[Category:CRDT]]