这两天在阅读一篇关于微服务的文章时，作者提到了CAP的原则，作者没有做任何的解释，只是引用了这个原则，感觉应该是业界比较知名的理论，想当然的认为阅读者已经知晓了。

我的确是孤陋寡闻啊，竟然完全不知道CAP是什么东东，只好在网上补习了一下。记录于此，作为备忘吧。

CAP

CAP理论是用来描述分布式系统的一个准则：

  • C（一致性）：所有的节点上的数据时刻保持同步
  • A（可用性）：每个请求都能接受到一个响应，无论响应成功或失败
  • P（分区容错）：系统应该能持续提供服务，即使系统内部有消息丢失（分区）

围绕这三天引申出来的定理：任何分布式系统在可用性、一致性、分区容错性方面，不能兼得，最多只能得其二，因此，任何分布式系统的设计只是在三者中的不同取舍而已。

根据上述定理，具体的分布式系统衍生模式如下：

  • CA without P：如果不要求P（不允许分区），则C（强一致性）和A（可用性）是可以保证的。但其实分区不是你想不想的问题，而是始终会存在，因此CA的系统更多的是允许分区后各子系统依然保持CA。
  • CP without A：如果不要求A（可用），相当于每个请求都需要在Server之间强一致，而P（分区）会导致同步时间无限延长，如此CP也是可以保证的。很多传统的数据库分布式事务都属于这种模式。
  • AP wihtout C：要高可用并允许分区，则需放弃一致性。一旦分区发生，节点之间可能会失去联系，为了高可用，每个节点只能用本地数据提供服务，而这样会导致全局数据的不一致性。现在众多的NoSQL都属于此类。

不过值得注意的是，CAP并不是适应任何场景的定理，具体问题要具体分析。

这是一篇讲解CAP非常好的文章：CAP理论，以供按考。

ACID

ACID是数据库事务正常执行的四个原则，分别指原子性、一致性、独立性及持久性。

  • A: 事务的原子性(Atomicity)，是指一个事务要么全部执行，要么不执行。也就是说一个事务不可能只执行了一半就停止了。比如你从取款机取钱,这个事务可以分成两个步骤：1、划卡，2、出钱。不可能划了卡，而钱却没出来。这两步必须同时完成，要么就不完成。

  • C: 事务的一致性(Consistency)，是指事务的运行并不改变数据库中数据的一致性。例如，完整性约束了a+b=10，一个事务改变了a，那么b也应该随之改变。

  • I: 事务的独立性(Isolation），是指两个以上的事务不会出现交错执行的状态。因为这样可能会导致数据不一致。

  • D: 事务的持久性(Durability），是指事务执行成功以后，该事务所对数据库所作的更改便是持久的保存在数据库之中，不会无缘无故的回滚。

BASE

BASE模型跟ACID模型相对应，牺牲高一致性，获得可用性或可靠性：

  • BA：Basically Available基本可用。支持分区失败(e.g. sharding碎片划分数据库)

  • S: Soft state软状态，可以有一段时间不同步。

  • E: Eventually consistent最终一致，最终数据是一致的就可以了，而不是时时高一致。

BASE思想主要强调基本的可用性，如果你需要高可用性，也就是纯粹的高性能，那么就要以一致性或容错性为牺牲。

现在NoSQL运动丰富了拓展了BASE思想，可按照具体情况定制特别方案，比如忽视一致性，获得高可用性等等。