关于分布式系统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。
网友评论