数据就像开着的水管，要怎么同步存储？

什么是 StateSynchronizer

（状态同步器）？

Pravega既可以被想象成是一组流存储相关的原语，因为它是实现数据持久化的一种方式，也可以被想象成是一个消息订阅 - 发布系统，因为通过使用reader，writer和ReaderGroup，它可以自适应地进行消息传递。（关于Pravega，读者可以从下方4篇文章中获取详细资料。）

↓↓↓

Pravega实现了各种不同的构建模块用以实现stream相关原语，StateSynchronizer就是其中之一，目的在于协调分布式的环境中的各个进程[2]。

从功能上看，StateSynchronizer为一组进程提供可靠的共享的状态存储服务：允许多个客户端同时读取和更新同一共享状态并保证一致性语义，同时提供数据的冗余和容错。从实现上看，StateSynchronizer使用一个stream为集群中运行的多个进程提供了共享状态的同步机制，这使得构建分布式应用变得更加简单。

StateSynchronizer的最大贡献在于它提供了一种stream原生的一致性存储方案。由于stream具有只允许追加（Append-Only）的特性，这使得大部分现有的存储服务都无法很好地应用于stream存储的场景。相比于传统的状态存储方案，stream原生的存储使得StateSynchronizer具有以下优点：

StateSynchronizer无意于也不可能在所有场景中替代传统的分布式键值存储组件，因为它的运行机制大量依赖stream的特性。但是，在具有stream原生存储和较强一致性需求的场景下，StateSynchronizer可能是一种比其它传统键值存储服务更为高效的选择。

开宗明义

“一致性”的不同语义

在不同的上下文环境中，“一致性”一词往往有着不同的语义。

在分布式存储和数据高可用（High Availability）相关的语境下，一致性通常指数据副本（Replica）的一致性：如何保证分布在不同机器上的数据副本内容不存在冲突，以及如何让客户端看起来就像在以原子的方式操作唯一的数据副本，即线性化（Linearizability）。常见的分布式存储组件往往依赖单一的Leader（主节点）确定出特定操作的全局顺序，例如：ZooKeeper和etcd都要求所有的写操作必须由Leader转发给其它数据副本。数据副本的一致性是分布式系统的难点，但却并不是一致性问题的全部。

脱离数据副本，在应用层的语境下，一致性通常指数据满足某种约束条件的不变性（Invariant），即：指的是从应用程序特定的视角出发，保证多个进程无论以怎样的顺序对共享状态进行修改，共享状态始终处于一种“正确的状态”，而这种正确性是由应用程序或业务自身定义的。

StateSynchronizer与

现有的一致性存储产品区别

目前常用的分布式键值存储服务，例如ZooKeeper和etcd，都可以看作是一种对共享状态进行存储和维护的组件，即所有键值所组成的集合构成了当前的共享状态。在数据副本层面，ZooKeeper和etcd都依赖共识（Consensus）算法提供一致性保证。ZooKeeper使用ZAB（ZooKeeper’s Atomic Broadcast）协议在各节点间对写操作的提交顺序达成共识。在广播阶段，ZAB协议的行为非常类似传统的两阶段提交协议。etcd则使用Raft协议在所有节点上确定出唯一的写操作序列。与ZAB协议不同，Raft协议每次可以确认出一段一致的提交序列，并且所有的提交动作都是隐式的。

在应用层数据层面，ZooKeeper和etcd都使用基于多版本控制机制的乐观并发控制提供最基础的一致性保证。一方面，虽然多版本控制机制提供了基本的CAS语义，但是在极端的高并发场景下仍因竞争而存在性能问题。另一方面，仅仅依靠多版本控制机制无法提供更加复杂的一致性语义，例如事务。

尽管在数据副本层面，ZooKeeper和etcd都提供很强的一致性语义，但对于应用层面的数据一致性却还有很大的提升空间：ZooKeeper无法以原子的方式执行一组相关操作，而etcd的事务仅支持有限的简单操作（简单逻辑判断，简单状态获取，但不允许对同一个键进行多次写操作）。

为应用层数据提供比现有的分布式存储组件更强的一致性语义（复杂事务）和更高的并发度是StateSynchronizer的主要目标，尤其是在stream原生场景下，因为传统的以随机访问为主的存储组件很难适配stream存储的顺序特性。得益于stream的自身特性，StateSynchronizer可以不依赖乐观并发控制和CAS语义，这意味着不会出现版本冲突也无需重试，从而更加适用于高并发的场景。在“无条件写”模式下，StateSynchronizer的理论更新提交速度等价于stream的写入速度。

与现有的绝大多数存储服务不同，StateSynchronizer反转了传统的数据存储模型：它并不存储共享状态本身，转而存储所有作用在共享状态上的更新操作。一方面，这一反转的数据模型直接抽象出了共享状态，使得共享状态不再局限于简单的键值存储，而可以推广到任意需要一致性语义的状态。另一方面，反转数据存储的同时还不可避免地反转了数据相关的操作，使得原本大量的服务端状态计算可以直接在客户端本地完成。这一特性不仅大大降低了服务端的资源消耗，同时也使得StateSynchronizer可以提供更灵活的更新操作和更强一致性语义：复杂事务。

在StateSynchronizer的框架中，客户端提交的所有更新操作都是以原子的方式顺序执行的，并且所有更新操作的执行都发生在本地。从逻辑上看，每一个更新操作都等价于一个本地事务操作。这也意味着客户端可以在更新操作中使用复杂的业务逻辑（几乎是不受限的操作，只要操作本身的作用是确定性的）而无需担心一致性问题。