初入 pingcap ，我这枚小菜鸟对分布式理论却一窍不通，表示很是捉急，借我司 CTO 为新员工科普分布式系统知识之际，自己也花点时间学习学习, 首先先从 CAP 定理入手...
ACID
传统数据库设计思想, 追求强一致性
- A: Atomicity (原子性)
事务里的操作要么全部执行要不全部不执行
- C: Consistency(一致性)
事务前后的数据都符合业务里的不变性约束
- I: isolation(隔离性)
表示并发事务之间读数据互相影响的程度
- D: durability(持久性)
事务提交后就进行了持久化, 不在丢失
BASE
大多数 nosql 数据库的设计思路, 追求高可用
- BA: Basically Available(基本可用)
基本可用是指分布式系统在出现故障的时候，允许损失部分可用性，即保证核心可用
- S: Soft Stat(软状态)
允许事务的一些状态暴露出来, 即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时
- E: Eventually consistent(最终一致性)
最终一致性是指系统中的所有数据副本经过一定时间后，最终能够达到一致的状态。弱一致性和强一致性相反，最终一致性是弱一致性的一种特殊情况
ACID和BASE代表了两种截然相反的设计哲学，分处一致性-可用性分布图谱的两极
CAP
柏克莱加州大学（University of California, Berkeley）的计算机科学家埃里克·布鲁尔在2000年的分布式计算原则研讨会（Symposium on Principles of Distributed Computing（PODC））上提出的这个猜想 在2002年，麻省理工学院（MIT）的赛斯·吉尔伯特和南希·林奇发表了布鲁尔猜想的证明，使之成为一个定理。
它指出对于一个分布式计算系统来说，不可能同时满足以下三点：
- 一致性(Consistency)
向分布式系统给发送请求,一定返回最新的数据
- 可用性(Availablity)
向分布式系统写、读等请求的时候，一定会得到合理的响应，这个响应不应该是错误也不应该是请求超时
- 网络分区容忍性(Partition tolerance)
分布式系统中，当部分节点无法互通出现网络分区现象，但是整个系统还是可以对外提供服务
由于当前的网络硬件肯定
会出现延迟丢包等问题，所以分区容忍性是我们必须需要实现的。
以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择
根据定理，分布式系统只能满足三项中的两项而不可能满足全部三项。理解CAP理论的最简单方式是想象两个节点分处分区两侧。允许至少一个节点更新状态会导致数据不一致，即丧失了C性质。如果为了保证数据一致性，将分区一侧的节点设置为不可用，那么又丧失了A性质。除非两个节点可以互相通信，才能既保证C又保证A，这又会导致丧失性质。(from Wikipedia)
具体选择AP,还是CP 都是由具体场景来做决择。
CP 栗子: 2PC(两阶段提交)
两阶段提交, ACID 思想在分布式系统中的延伸，保证数据的强一致性。
- 阶段一: 请求阶段
在请求阶段，协调者将通知事务参与者准备提交或取消事务，然后进入表决过程。在表决过程中，参与者将告知协调者自己的决策：同意（事务参与者本地作业执行成功）或取消（本地作业执行故障）。
- 阶段二: 提交阶段
在该阶段，协调者将基于第一个阶段的投票结果进行决策：提交或取消。当且仅当所有的参与者同意提交事务协调者才通知所有的参与者提交事务，否则协调者将通知所有的参与者取消事务。参与者在接收到协调者发来的消息后将执行响应的操作。
2PC协议存在许多明细的问题, 如参与者挂了，或是协调者挂了等,今晚好困, 2PC问题可待我仔细思考学习一下，还有我司 CTO 提到的拜占庭问题...
AP 栗子: BASE
BASE理论是对CAP理论的延伸，核心思想是即使无法做到强一致性，但应用可以采用适合的方式达到最终一致性,
BASE是指基本可用（Basically Available）、软状态（ Soft State）、最终一致性（ Eventual Consistency）。大多数的 nosql 数据库就是基于BASE设计的，如redis、mongodb等
Last But Not Least
CAP 定理告诉我们, "在分区存在的情况下, 呈现完美的数据一致性和可用性" 是不可能的, 分区在很多情况下并不是经常出现的, 在没有分区的情况下, 我们应该尽量保证CA，在发生分区的时候, 我们应该具体场景具体分析，选择CP or AP......