CAP 三角不可能等式

关于分布式系统CAP 特性，其实一直是属于一个模糊的状态。

主要是学了计算机，主观里更加看重实践和动手能力，总是觉得speak is cheap， show me your code 才是最酷的，

以至于连个CAP的概念的说不清楚。

千万个读者心里有千万个哈姆雷特，关于CAP网上也有一千万个解读，为了加深印象，我自己也试着用

自己项目中的经验去理解CAP。

首先来说，我们现在用到的典型的web应用架构是这样的，

一个load balance的服务器， 后面连接了多台 web server， 每台web server 连接不同的 数据库。

                           web-A            DB-A

Lobalance -->

                          web-B                DB-B

                          Web-C               DB-C

何为CAP呢，CAP就是你在构建这样的一个系统的时候给出的承诺。

打散来看：

C：一致性：

 也就是说你承诺， 任何用户访问我们的应用的时候，拿到的就是最新的数据。

为了实现这个承诺，当存在更新的时候，比如用户A写入到数据库A后，需要做 DB- A-B-C的数据同步，

以保证 三个DB的数据是一样的，也就是说要实现分布式事务。

这期间，如果用户要访问数据库中的数据，那么必须要等待事务的结束，有的时候，由于事务异常，用户就无法访问到数据，

系统给出一个异常。就是是关于C的承诺，要么给你一致的数据，要么系统异常。

由于有严格的数据一致性要求，这样的系统不允许脏读，比如金融行业，转账取钱等。

与C对立的则是 A 可用性：

也就是承诺，你请求的时候，总是可以获得相对新的数据，没有异常，但不保证数据最新。

例如当用户通过web-A 插入了数据到 DB-A之后，并不需要最新的数据都同步到 DB  -B-C，用户可以通过web-B访问到一份DB-B中的数据，但是不是最新的。

比如，我们看到12306， 你刷到票，然后可以下单，但是会告诉你没买上，这也是 A的表现，因为数据没有严格的做一致性要求。

而对于P 网络分区而言：

是承诺，在整个网络中，出现任何单个节点服务，网络的故障，应用都是可用的。

例如我们的loadbalance就是为了保障这样的承诺的，因为loadbalance 会有 health check 的机制， 而DB-A-B-C 通常也是会做成集群

web 和db 中的若干台宕机都不会影响服务。

综上，对于分布式系统而言， P是一定要的， 然后根据业务情况，选择 A或者C。