当我第一次开始使用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。
