对CAP的初步解释

 CAP理论是Eric Brewer教授在20世纪初提出来的，后来，经Seth Gilbert 和 Nancy lynch两人证明是正确的。我们知道，CAP代表了Consistency一致性，Availability可用性，Tolerance of network Partition分区容忍性，其代表的含义并不复杂，就是说：一个分布式系统不可能同时满足一致性，可用性和分区容忍性这三个需求，最多只能同时满足两个。要注意的是，我们这里都是讲分布式系统的，也就是说，根据CAP理论，要拿NoSQL数据库与关系数据库比较，也只能是和TeraData，GreenPlum，Netezza等分布式系统相比才有意义。

  很显然，根据CAP理论，抛开技术细节，从宏观来讲，关系数据库的设计目标，就是因为必须要很好的满足一致性C与可用性A，因此，便不能很好的满足分区容忍性P。所带来的结果，直观来讲，就是影响了其良好的水平扩展能力。正如我们上一章所讲的那样，对那些采用Shared Nothing的、MPP架构的、适用于OLAP场景的关系数据库，虽然从物理架构角度来讲其水平扩展性已经是很好了，但由于从软件角度还必须同时保证C与A的要求，导致其水平扩展性能相对NoSQL来讲，毕竟是有限的。

  关于CAP理论，其实有很多资料都有描述，大体来讲，都是很容易理解的：对可用性Availability一般认为主要是指系统的可靠性，比如节点宕机后对系统读写的影响，我们可能会要求这时系统还能继续正常读写；但这里认为，CAP理论中的可用性，还应该包括了高性能，即读写效率，因为很明显，我们设计NoSQL数据库，在牺牲了某方面特征后，需要得到的不只是与分区容忍性有关的水平扩展性，更重要的还有很高的读写性能。分区容忍性Tolerance of Partition就不用说了，自然是指水平扩展方便（准确讲，实际上是指同一份数据的多副本分布可容忍度及关联数据的分布可容忍度，对无副本无关联的数据分布则根本不存在这个问题）。最重要的就是关于一致性consistancy，这里认为很多资料都没有讲清楚。现在大多NoSQL的技术资料，都会将一致性的相关示例集中在一种场景下解释：即当同一数据有多个备份时，读与写的一致性（读写一致性是指：当写操作确认完成时，相关的读操作能返回同样的结果；写操作要保证其关联操作都完成时，才能真正确认完成。当然，关于一致性，详细讨论，还有很多不同的细节级别情况，如强、弱一致性，Read Your Write，Session Consistancy, 单调读一致性，单调写一致性，因果一致性，以及最终一致性等，这里就不一一赘述），其实这样对一致性的理解是不全面的。我们知道在关系数据库事务操作ACID特性中的一致性C，主要是指一个事务中相关联的数据在事务操作结束后是一致的，例如银行一个存款交易事务，将导致交易流水表增加一条记录，同时，必须导致账户表余额发生变化，这两个操作必须是在一个事务中全部完成，以保证相关数据的一致性；当然，ACID中的C也也包括了对一个数据多个备份的读写一致性。我们说，CAP理论中的C与ACID中的C其实是一回事，只是因为大多数NoSQL数据库并不提供事务的功能，因此，关联数据一致性的问题，在NoSQL数据库的设计中并没有明显表现出来而已（如果基于NoSQL的应用，要实现这种特性，大多必须在应用中自行完成，或者借助其它工具完成，如HBase就借助zookeeper来实现锁功能），但并不是不存在这个问题，在NoSQL应用开发中你必须清楚：数据库本身除了对多备份数据一致性的支持外，在这方面不见得能支持你，当然还包括ACID机制中能保证的脏读，不可重复读，幻觉读等问题。所以，对一致性C全面的解释应该是包括以下两个方面：

   . 一个数据操作成功完成，必须保证该数据多个备份的读写一致性；

  . 一个数据操作成功完成，必须保证有关联关系的数据的读写一致性。

   现在，我们把按这样的要求实现的一致性称强一致性，因为在NoSQL数据库出现之前，我们谈一致性，都是缺省指强一致性。但现在，在NoSQL中，可能会通过牺牲一致性C，来得到可用性A与分区容忍性P，那么，NoSQL所谓牺牲一致性，其实是指不要求实现那么强的一致性，也就是弱一致性，或最终一致性。

   一致性C搞清楚后，我们再来看看可用性A的相关问题。我们说分区容忍性P保证后，C与A就变成冲突的了，为什么呢？很明显，如果保证C，要求一个写操作，要在多个备份上全部完成或相关操作全部完成后才确认，那么，在这个写操作完成之前的读操作，都是拿不到最新数据的。我们要么就是通过锁机制来防止读操作的进行，要么就是返回旧的数据（当然还要参考多版本并发控制MVCC机制），这样首先是对读写效率产生了影响；其次，一个写失败或读失败都会导致系统不可用的结果；而针对上面说的关联数据问题，如果在分布式系统中采用两段式提交很显然是使可用性A极大的降低，总之，可用性A是不高的；反之亦然。

   另外，我们还要清楚，如果抛开读与写的协调问题，单说读或者写的性能，先不要说读写操作不经过SQL解析本身就可以在很大程度上提供效率，NoSQL数据库也设计了很多其它措施来提高效率，而这些却是与CAP理论无关，这也就是我们说CAP与BASE理论其实并不能完整体系化的支撑NoSQL发展的原因。

   有了CAP理论，现在，再来看看NoSQL。如果我们说传统关系数据库的相关问题是因为保证了C与A，就不能保证P而引起的，那么通过NoSQL数据库来解决关系数据库瓶颈的方法，只能通过在C、A、P三个要素中选择其它两个来完成，因为我们不可能同时选三个。很简单，要么是选C与P，要么是选A与P，也就是说，你设计一个NoSQL数据库时，首先必须保证分区容忍性P，即要保证很好的水平可扩展性以达到对海量数据管理的要求（这几乎已经成为所有NoSQL数据库的共同特性了），然后，再根据需求选择C或者A，都是可以的，就如前面介绍的HBase就选择了C，而Cassandra则选择了A一样（需要说明下，HBase的强一致性实际是通过Memstore机制实现的，并且没有关联数据事务的功能，所以，严格来讲，所有的NoSQL数据库实际上都是优先保证A与P）。

   这里还有一点很有必要指出：我们说为了保证一致性C会导致分布式系统的分区可容忍性降低，其本质是什么呢？相信对很多读者来说，这一点还不是很清晰的推导过程。其实如果我们将上面所说一致性C两个要素中的数据多备份情况的本质也归纳为分布式系统中的数据关联问题，那么，就可以这样说：分布式系统中严格要求的数据关联操作会在很大程度上限制其水平扩展性能。这样一来，就很好理解了，正如Join这样的操作一直都是分布式数据库的难点一样，这应该是同样的道理：关联问题在很多情况下不是并行处理的优点所在！这在很大程度上与Amdahl定律相符合！