程序开发中常见缩写：CAP、ACID和BASE释义

请知悉：本文最近一次更新为 3年前，文中内容可能已经过时。

讲道理，我其实对学术名词嗤之以鼻，很多技术，不创造几个名词就显得自己很不牛逼似的，实在没啥必要。
如果一个复杂的理论，无法拆解成多个简单理论来支撑，那说明这理论是“存在问题”的。把高端的技术用大白话讲明白，才是真的实力。

下面说说程序开发中常见缩写：

CAP
CAP，即一致性(Consistency)、可用性(Availability)和分区容错性(Partition Tolerance)。
常见于分布式架构设计，重点在于，只能三选二。通常常见的数据最终一致性，这个说法就是CAP的典型使用，为啥说是最终一致？因为设计的系统只能保证在每个时刻分区容错和高可用，而数据的一致性是通过最终一致（滞后）实现的。
ACID
ACID，一般作为数据库事务具有的4个属性：即原子性(Atomicity)，一致性(Consistency)，隔离性(Isolation)和持久性(Durable).
事务这玩意儿呢，本身考点甚多，但大多都是为了考而考的，没太多意义，一般研发碰到因为事务引起的问题较少。通常此类问题常见于各种复杂并发时的互锁、读写等场景。
实际应用起来，最基本的事务写失败roll back回滚就是ACID的使用实例。
BASE
BASE，全称：Basically Available(基本可用)，Soft state（软状态）,和 Eventually consistent（最终一致性）三个短语的缩写，来自 ebay 的架构师提出。
Base 理论是对 CAP 中一致性和可用性权衡的结果，其来源于对大型互联网分布式实践的总结，是基于 CAP 定理逐步演化而来的。其核心思想是：既是无法做到强一致性（Strong consistency），但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性（Eventual consistency）。
总的来说，BASE 理论面向的是大型高可用可扩展的分布式系统，和传统事务的 ACID 是相反的，它完全不同于 ACID 的强一致性模型，而是通过牺牲强一致性来获得可用性，并允许数据在一段时间是不一致的。