当我第一次开始使用Apache Ignite时,我想弄明白Ignite是如何在支持ACID事务的同时提供了高可用性的分布式系统的。对于任何NoSQL数据库来说,支持ACID事务并同时提供高可用性是一个具有挑战性的特性。要横向扩展,就必须保证分区容忍性,这需要放弃一致性或者可用性。NoSQL系统通常通过松散关系可用性或事务语义来实现这一点。许多流行的NoSQL数据存储,如Cassandra和Riak,仍然没有事务支持,他们被归类为AP系统。AP一词来自于著名的CAP定理它意味着可用性和分区容忍性,这两个特性在NoSQL系统中通常被认为比一致性更重要。
在2000年的ACM研讨会上,Eric Brewer在他的主题演讲中说,没有任何系统可以保证分布式系统的一致性。这是他根据自己在分布式系统方面的经验做出的推测。这一猜想后来被Nancy
Lynch和Seth Gilbert在2002年正式证实。现在,几乎每个NoSQL数据库都可以通过CAP定理进行分类,如下图所示。
如你所见,一个分布式系统只能有以下三个属性中的两个:
- Partition tolerance,分区容忍性:意味着如果你切断了两个节点之间的连接,系统仍然可以工作。
2.Consistency,一致性:集群中的每个节点都有相同的数据。
3.Availability,可用性:如果可能的话,每次查询都可以得到响应。
因此,让我们看看选择三个选项中的两个会如何影响系统行为,如下所示。
CA系统
在这种模式中,为了获得一致性和可用性,你牺牲了分区容忍度。你的数据库系统提供事务,并且系统是高可用性的,大多数关系数据库被归类为CA系统,但是这个系统在可伸缩性方面存在严重的问题。
CP系统
这与CA系统相反,CP系统为了一致性和分区容错而牺牲了可用性,在节点失败的情况下,可能会丢失一些数据。
AP系统
该系统始终可用,并将数据分区存储。另外,通过向集群中添加节点,系统可以轻松进行横向扩展。
备注
现实中,系统很少能完全归入上述所有类别,因此将CAP看作一个连续体更有帮助。大多数系统将努力保持一致性、可用性和分区容忍度,许多系统可以根据最重要的因素进行调优。
现在,我们可以回到我们的问题,Apache Ignite在CAP定理中处于什么位置?乍一看,可以用CP对Ignite进行分类,因为Ignite是完全符合ACID的具有分区容忍度的分布式事务。然而,这只说对了一半,Apache Ignite也可以被认为是一个AP系统,因为Ignite没有任何单点故障,并且可以进行分区。但是为什么Ignite有两种不同的分类呢?因为,对于缓存操作,它有两种不同的事务模式:事务性和原子性。
在事务模式中,可以将多个DML操作分组在一个事务中,并将单个提交提交到缓存中。在这个场景中,Ignite将通过悲观锁锁定访问数据。我们将在第6章中详细讨论事务。
另一方面,Ignite支持在原子模式下顺序进行多个原子操作。在原子模式中,每个DML操作要么成功,要么失败,读或写操作根本不会锁定数据。此模式比事务模式具有更好的性能。当你在Ignite缓存中写入时,对于每个数据块,可能都有一个主拷贝和一个备份拷贝(如果定义了的话)。当你从Ignite网格读取数据时,你总是读取数据的主副本,除非存储主副本的节点关闭(但是,你可以通过API显式地读取备份副本),此时数据将从其他节点读取。从这个角度来看,你可以获得作为AP系统的系统级的可用性和分区容忍度。Apache Ignite在原子模式上非常接近Apache Cassandra。