An introduction to state-based CRDTs：修订间差异

来自WHY42
←上一编辑下一编辑→
可视化wikitext
Riguz（留言 | 贡献）
行政员、​界面管理员、​管理员
1,295次编辑
Riguz（留言 | 贡献）
行政员、​界面管理员、​管理员
1,295次编辑
第13行： 第13行：
它要解决什么样的问题，并通过一些基本的代码实现（F#）来帮助你理解怎样去使用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是解决一个常见的分布式环境下数据同步问题的答案。
CRDT是解决一个常见的分布式环境下数据同步问题的答案。
尽管人们熟知分布式领域中的此类问题，在过去已经进行了许多尝试来解决，
尽管人们熟知分布式领域中的此类问题，在过去已经进行了许多尝试来解决，
第21行： 第18行：
但他们无一例外有以下的问题：
但他们无一例外有以下的问题：


<!--
* 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 边缘计算]和移动应用的场景中）
* 我们的一个假设是，所有的参与者总是在事务发生期间是可用的，而经常这个假设恰恰是不成立的（比如在[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:
-->
这并非是说先有的解决方案不好。
这并非是说先有的解决方案不好。
我们期望在一个更广阔的可能的解决方案的范围中，
我们期望在一个更广阔的可能的解决方案的范围中，
找到解决特定条件下的问题的更佳方式。
找到解决特定条件下的问题的更佳方式。
这其中我期望呈现的一个问题是：
这其中我期望呈现的一个问题是：
<!--
Imagine that you need to build a planet-scale video streaming service. Whenever a user uploads a video, we are replicating it across different data centers located on different continents to maintain good throughput and latency, and in result a better user experience. Additionally we want to show users a view count for that video.
-->


<q>
<q>
第50行： 第36行：
</q>
</q>


<!--
Video uploading is a good example of master-slave replication. However things may complicate for such a small feature as view count. With many concurrent users over the entire planet and write-heavy characteristics, using the same approach for counter increments is not a great idea, as this may end up with congestion for more popular videos. We don't need transactions, as the nature of the problem allows us to loose constrains of strong consistency in favor of higher availability of our application. However as described earlier most of the existing solutions are based on exclusive write access to a replicated resource. This is where CRDTs and multi-master scenarios come to play.
-->
视频上传是一个主-从复制的很好的例子。
视频上传是一个主-从复制的很好的例子。
但是仅仅当添加一个播放数量的小小功能时，事情却变得复杂起来。
但是仅仅当添加一个播放数量的小小功能时，事情却变得复杂起来。
第62行： 第45行：
正因如此，CRDT和多主场景有了发挥的空间。
正因如此，CRDT和多主场景有了发挥的空间。


== 使用场景和实现==
== 冲突无关意味着什么==
== CRDT的类型==
== 计数器==
== 寄存器 ==
== 集合 ==
== 接下来是什么？ ==


[[Category:CRDT]]
[[Category:CRDT]]

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

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

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

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

动机

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

  • 我们的一个假设是，所有的参与者总是在事务发生期间是可用的，而经常这个假设恰恰是不成立的（比如在边缘计算和移动应用的场景中）
  • 多阶段提交和使用议会制的方案需要在参与者之间进行多次往返通信。这附带带来延迟和吞吐量的开销。而且，当机器增多或者通信距离增加时，这种方式有降低可扩展性的趋势。多数场景中，一旦跨越单个数据中心机房，使用分布式事务都是行不通的
  • 这些方案通常确定一个单一的主节点来进行排他写操作，或者作为单一的数据源。在某些情况下，比如上面提到的场景中，都是不可接受的。

这并非是说先有的解决方案不好。 我们期望在一个更广阔的可能的解决方案的范围中， 找到解决特定条件下的问题的更佳方式。 这其中我期望呈现的一个问题是：

试想你需要建造一个全球范围的视频流服务。 每当用户上传一个视频文件的时候， 都需要复制到位于其他大陆的数据中心中，以便维持良好的延迟和吞吐量， 从而得到更好的用户体验。 不仅如此， 我们还希望把视频的播放次数展示给用户。

视频上传是一个主-从复制的很好的例子。 但是仅仅当添加一个播放数量的小小功能时，事情却变得复杂起来。 在整个地球许多并发用户、又是写操作多的特点下，使用诸如计数器的方式恐怕不是一个好主意， 因为对于热点视频可能会导致阻塞。 这个问题的本质允许我们降低强一致性来换取更高的可用性，因此并不需要事务。 但是如先前所述， 先有方案大多数在复制资源的写操作上又是采取排他的方式实现的。 正因如此，CRDT和多主场景有了发挥的空间。

使用场景和实现

冲突无关意味着什么

CRDT的类型

计数器

寄存器

集合

接下来是什么？

检索自“https://riguz.com/index.php?title=An_introduction_to_state-based_CRDTs&oldid=4505”