CAP 理论概述：一个分布式系统最多只能同时满足一致性( Consistency )、可用性( Availability )和分区容错性( Partition tolerance )这三项中的两项。
需要特别指出的 CAP 中的一致性是 all nodes see the same data at the same time ，也就是线性一致性。
一致性必须从两个维度看：
( 1 )从客户端角度，多进程并发访问时，非分布式数据库要求更新过的数据能被后续的访问都能看到，所有都是强一致的;
( 2 )从服务端角度，如何尽快将更新后的数据分布到整个系统，降低达到最终一致性的时间窗口，是提高系统的可用度和用户体验非常重要的方面。
参考以下公式：
N — 数据复制的份数
W — 更新数据时需要保证写完成的节点数
R — 读取数据的时候需要读取的节点数
(1) 如果 W+R>N ，写的节点和读的节点重叠，则是强一致性。例如对于典型的一主一备同步复制的关系型数据库， N=2,W=2,R=1 ，则不管读的是主库还是备库的数据，都是一致的。
(2) 如果 W+R<=N ，则是弱一致性。例如对于一主一备异步复制的关系型数据库， N=2,W=1,R=1 ，则如果读的是备库，就可能无法读取主库已经更新过的数据，所以是弱一致性。
对于一个分布式系统来说。P 是一个基本要求， CAP 三者中，只能在 CA 两者之间做权衡，并且要想尽办法提升 P 。
包含两种系统：CP without A**、 AP without C**
我们在上文所提到的 Hdfs 、 Ceph 、 Swift, 均是属于CP without A的这个大类，只是并不是完全没有 A ，为了实现一定的可用性，一般设置副本的个数为 N>=3 。不同的 N,W,R 组合，是在可用性和一致性之间取一个平衡，以适应不同的应用场景。
那么，实际生活中，也有一些是AP without C的案例，如 CAP 图中所示，大部分是 Nosql 、 CoachDB 、 Cassandra 数据库，那场景是哪些呢?
其实就是不要求正确性的场合，如某米的抢购手机场景或 12306 抢购火车票的场景，可能前几秒你浏览商品的时候页面提示是有库存的，当你选择完商品准备下单的时候，系统提示你下单失败，商品已售完。这其实就是先在 A(可用性)方面保证系统可以正常的服务，然后在数据的一致性方面做了些牺牲。
2 、数据分布
分布式系统区别于传统单机系统在于能够将数据分布到多个节点，并在多个节点之间实现负载均衡。数据分布的方式主要有两种，一种是哈希分布，如一致性哈希，代表系统为
Amazon 的 Dynamo 系统， Openstack 的 Swift 系统;另外一种方法是顺序分布，即每张表格上的数据按照主键整体有序，代表系统为 Google 的 Bigtable 系统。Bigtable 将一张大表根据主键切分为有序的范围，每个有序范围是一个子表。
A 、哈希分布( Swift )
哈希函数的散列特性很好，哈希方式可以将数据比较均匀地分布到集群中去。而且，哈希方式需要记录的元信息也非常简单，每个节点只需要知道哈希函数的计算方式以及模的服务器的个数就可以计算出处理的数据应该属于哪台机器。
然而，找出一个散列特性很好的哈希函数是很难的。这是因为，如果按照主键散列，那么同一个用户 id 下的数据可能被分散到多台服务器，这会使得一次操作同一个用户 id 下的多条记录变得困难;如果按照用户 id 散列，容易出现 “ 数据倾斜 ” ( data skew )问题，即某些大用户的数据量很大，无论集群的规模有多大，这些用户始终由一台服务器处理。
处理大用户问题一般有两种方式，一种方式是手动拆分，即线下标记系统中的大用户(例如运行一次 MapReduce 作业)，并根据这些大用户的数据量将其拆分到多台服务器上。这就相当于在哈希分布的基础上针对这些大用户特殊处理;
另一种方式是自动拆分，即数据分布算法能够动态调整，自动将大用户的数据拆分到多台服务器上。其中包含两种算法。
一种是传统的哈希算法，访问数据时，首先计算哈希值，再查询元数据服务器，获得该哈希值对应的服务器。在这种算法下，服务器的上线和下线将导致大量的数据迁移，不适合于生产。
另一致性哈希( Distributed Hash Table,DHT )算法。算法思想如下：给系统中每个节点分配一个随机 token ，这些 token 构成一个哈希环。执行数据存放操作时，先计算 Key (主键)的哈希值，然后存放到顺时针方向第一个大于或者等于该哈希值的 token 所在的节点。一致性哈希的优点在于节点加入 / 删除时只会影响到在哈希环中相邻的节点，而对其他节点没影响。