27. ClustrixDB 分布式架构/一致性、容错和可用性

一致性

许多分布式数据库都采用最终一致性而不是强一致性来实现可伸缩性。但是，最终的一致性会增加应用程序开发人员的复杂性，他们必须针对可能出现的数据不一致的异常进行开发。

ClustrixDB提供了一个一致性模型，可以使用智能数据分布、多版本并发控制(MVCC)和Paxos的组合进行伸缩。我们的方法使ClustrixDB能够扩展写操作、在有写工作负载的情况下扩展读操作，并提供强大的ACID语义。

有关ClustrixDB如何扩展读写的详细说明，请参阅并发控制。

ClustrixDB采用以下方法来保持一致性:

• 集群内的同步复制。参与写操作的所有节点必须在写操作完成之前提供确认。写操作是并行执行的。
• Paxos协议用于分布式事务解析。
• ClustrixDB支持读提交和可重复读(快照)隔离级别，但对Serializable支持有限。
• 多版本并发控制(MVCC允许)无锁读，并确保写不会阻塞读。

容错

ClustrixDB通过维护跨集群的多个数据副本来提供容错功能。默认情况下，ClustrixDB可以处理单个节点故障并自动恢复，而不会丢失数据。容错程度(n弹性)是可配置的，可以设置ClustrixDB来处理多个节点故障和区域故障。

有关如何在ClustrixDB中调整容错的更多信息，请参见了解容错、max_failure和zone。

可用性

为了了解ClustrixDB的可用性模式和故障情况，有必要了解我们的组成员协议。

组成员和Quorum

ClustrixDB使用分布式组成员协议。协议维护两个基本集:

1. 集群中所有已知节点的静态集合
2. 当前可以彼此通信的节点集。

除非静态成员中的半数以上节点能够彼此通信(quorum)，否则无法形成集群。

例如，如果一个六节点集群，只有两个三节点的集合经历了一个网络分区，ClustrixDB将无法形成一个集群。

但是，如果超过一半的节点能够通信，则ClustrixDB将形成一个集群。

出于性能原因，max_failure默认值为1，以提供一个节点或一个区域的丢失。

部分的可用性

在上面的例子中，ClustrixDB形成了一个集群，因为仍然保留了节点仲裁。但是，这样的集群只能提供部分可用性，因为集群可能无法访问完整的数据集。

在下面的示例中，ClustrixDB被配置为维护两个副本。但是，持有A的副本的两个节点无法参与集群(由于某些故障)。当事务试图访问片a上的数据时，数据库将生成一个错误，该错误将显示在应用程序中。

可用性需求

ClustrixDB甚至可以在出现故障时提供可用性。为了提供完全可用性，ClustrixDB要求:

• 大多数节点能够形成集群(即quorum requirement)。
• 可用节点为每个数据集至少保存一个副本。