大话分布式事务-概念篇 博客分类： 分布式事务 CAPBASE分布式事务

how to understand CAP

CAP不好理解， 常规解释

C： 一致性

A： 可用性

P：分区容忍性

虽然搞不清CAP的意思，可以知道他们之间是相互影响的。

try to understand CAP

OK 我们试着从CAP的出生理解，我觉得这样理解能更加的透彻。

CAP的出生在那？， sorry我没有看过原论文，只能靠想象。

CAP既然是分布式理论，那么肯定是在分布式的演变过程中产生，那么这个点就是：单机->分布式，那么 我们从CAP的父母 应该可以找到答案

 

那么CAP在是单机中是否存在，答案：是的 。只不过 CAP中的P特性被掩盖了。 来回忆一下单机程序设计时代。

在单机程序设计时代我们要考虑的是什么

首先是性能，然后是数据不出错，容灾，简单易用。

SO:

性能，容灾，简单易用-> 可用性，可认为是A

数据不出错->一致性 可认为是C

还有被忽略的数据是不是有分区呢

是有的， 只是 分布在同一个库的不同表中，可认为是P。

单机中的CAP是否互相影响呢？

单机中Ｃ使用DB事务解决，如果不使用事务，性能会提升但会产生数据一致性的问题。 单机中C与A是相互影响的。

P对C和A，是否有影响？

表面看不出来， 深入分析是有的。 单机中数据分区可以看成是 单表到多表的过程。 例如 原来 order表中的库存信息， 拆分成一个表。

原来一条SQL， 一个DAO方法就能解决的业务，现在 变成2条SQL， 2个DAO方法，还要加事务。这对性能（A）是不是有影响？

本来数据的一致性不加DB事务就能保证，现在还要加DB事务才能保证，是不是影响了数据一致性？

从上面分析来看 单机中也存在CAP 理论，为啥单机时代没有提出？

在单机时代 虽然 可用性 数据一致性 也相互影响，但是影响性不大，事务问题 也可以用简单的DB事务保证， 问题并不突出。

小结：单机时代可以找出CAP的影子，问题可以用简单的方案解决，矛盾并不突出。

 

OK，我们来看单机到分布式的过程中发生了什么

由于单机计算能力和存储能力的限制，只能将数据分布在不同的机器上，发生了数据分区， 数据分区后产生了数据空间上的分离，事务问题不能通过简单的方案解决，这中情况出现了一个挑战，怎么样在数据分区的条件下 保证系统的可用性（A）和一致性（C）？，SO 推断出P的含义：数据分区的情况下保证 系统的可用性（A）和一致性（C）的能力。

小结：从单机到分布式的演变过程可以帮助我们理解晦涩的CAP原理。

 

由于数据分区出现，C与A不能很好的协调，我们必须选择 AP或CP，再针对剩下的一项进行优化。

选择CA放弃分区是单机时代的设计，选择CP 一旦发生网络异常，可用性低的情况下，系统将难以保证提供服务， 业界普遍的方案 是 选择 AP 然后看看 C怎么来解决。

小结：CAP是相互影响的，在不能同时满足的情况下，通常选择 AP 然后看看 C怎么来解决

 

BASE理论

1. BASE是Basically Available（基本可用）
2. Soft state（软状态）
3. Eventually consistent（最终一致性）

小结：BASE是对一致性要求的强弱划分

 

CAP的重要含义是三个要素之间相互影响

从设计角度理解CAP

C： 一致性

A： 性能

P：扩展性

这个理解是我看过多篇文章以及我的经验总结， 在实际的架构设计 场景中 我们首先要考虑性能，

而性能是通过可扩展设计实现， 可扩展的设计做好了呢，通常又会出现数据一致性的问题。

从容灾的角度理解CAP

根据支付宝的诠释

C： 一致性

A： 持续服务的能力

P：数据分区发生异常导致不可用时， 满足 A，C的能力

这是从数据发生异常的角度理解

通俗的解释

一致性（C）：

一条数据分布在A，B中，A修改B也要修改

一个业务有 调用A，B两个服务，要么全成功 要么全失败。

A :持续提供服务

P：发生数据分区（由于网络原因，数据不能同步），系统的容忍性。

 

总结：

1. 单机时代可以找出CAP的影子，问题可以用简单的方案解决，矛盾并不突出。
2. 从单机到分布式的演变过程可以帮助我们理解晦涩的CAP原理。
3. CAP是相互影响的，在不能同时满足的情况下，通常选择 AP 然后看看 C怎么来解决
4. BASE是一致性强弱要求划分的理论。
5. CAP的重要含义是三个要素之间相互影响，可用从设计和容灾两个角度理解。