在弄清楚这个问题之前，让我们先了解一下什么是分布式CAP定理。
根据百度百科的定义，CAP定理又称CAP原则，在一个分布式系统中，一致性、可用性(Availability )、分区遍历(Partition tolerance )最大，同时只有三个特性中的两个，三个
http://www.Sina.com /一致性：
allnodesseethesamedataatthesametime (更新操作成功返回客户端后，所有节点上的数据在同一时间完全匹配)。 这就是分布式一致性。 一致性问题在并发系统中是不可避免的。 对于客户端来说，一致性是指如何检索并行访问时更新的数据。 从服务方面看，更新复制如何分布在整个系统上，以确保数据最终是一致的。
可用性：
可用性是指“已完成和写入”。 也就是说，服务始终可用，正常响应时间。 高可用性主要是指系统可以为用户提供服务，用户体验不会失败，也不会出现访问超时等问题。
分区容错：
也就是说，即使一个节点或网络分区发生故障，分布式系统也可以向外部提供满足一致性或可用性的服务。
由于分区的可接受性要求，APP应用程序是分布式系统，但看起来像是一个正常工作的整体。 例如，在当前的分布式系统中，即使一个或多个机器瘫痪，剩馀的机器也可以正常运行以满足系统需求，对用户而言体验上的影响不大。
二、CAP定理的证明现在就证明吧。 为什么不能同时满足三个特性？
假设您有两台服务器，一台服务器上有APP a和数据库v，一台服务器上有APP b和数据库v。 他们之间的网络可以互操作。 也就是说，相当于分布式系统的两个部分。
满足一致性时，两台服务N1和N2最初两台服务的数据相同，DB0=DB0。 如果满足可用性，则用户在请求N1或N2时会立即响应。 如果满足分区容错要求，则N1或N2中的任何一个中断或网络中断都不会影响N1和N2之间的正常操作。
当用户通过N1中的a APP向服务器DB0请求数据更新时，此时N1中的服务器DB0为DB1，通过分布式系统的数据同步更新操作，N2服务器中的数据库V0也被更新为DB1。 此时，用户通过b向数据库发出请求而获得的数据成为立即更新的数据DB1。
上述情况正常运行，但在分布式系统中，最大的问题是网络传输问题。 假设在当前极端的情况下，N1和N2之间的网络断开。 但是，需要支持这种网络异常。 也就是说，必须满足分区容错要求。 那么，能否同时满足一致性和可用性？
假设在N1和N2之间的通信过程中网络突然出现故障，用户向N1发送了数据更新请求。 该N1的数据DB0被更新为DB1。 由于网络已断开，因此N2数据库仍为DB0。
此时，APP应用程序无法立即向用户返回最新的数据DB1，因为有用户向N2发送了数据读取请求，并且数据未同步。 我该怎么办？ 你有两个选择。 第一，以数据一致性为代价，响应旧数据DB0提供给用户。 第二，在以可用性为代价恢复网络连接并完成数据更新操作之后，阻塞等待用户响应最新的数据DB1。
虽然上述过程相对简单，但表明满足分区容错要求的分布式系统只能选择一致性或可用性。 也就是说，分布式系统不能同时满足三个特性。 这需要我们在建立系统时做出取舍。 那么，如何取舍是更好的战略呢？
三、取舍策略CAP的三个特性只能满足其中的两个。 那么，取舍选择的战略共有三种。
如果不要求一、CAP的定义(不允许分区)，则c )强一致性)和a )可用性)是可以保证的。 但是，放弃p的同时，也意味着放弃系统的可扩展性。 这意味着分布式节点受到限制，无法部署子节点，这违背了分布式系统设计的初衷。
如果不请求CA without P：(可用)，则每次请求都需要在服务器之间保持较强的一致性，而p )分区无限延长同步时间(即，在数据同步完成之前无法正常访问服务) 必须牺牲用户体验，等待所有数据匹配后才能访问系统。 设计为CP的系统其实不少。 最典型的是分布式数据库，如Redis、HBase等。 对这些分布式数据库来说，数据完整性是最基本的要求。 这是因为，如果不能满足这个标准，直接使用关系数据库就可以了，这样就不用浪费资源部署分布式数据库了。
CP without A：要在高可用性下允许分区，必须放弃一致性。 分区发生时，节点之间可能会失去连接。 为了高可用性，每个节点只能在本地数据上提供服务，这会导致全局数据不一致。 典型的APP应用就像一个美国手机抢购场景，几秒钟前浏览商品时的页面提示可能如下
有库存的，忧虑的果汁选择完商品准备下单的时候，系统提示你下单失败，商品已售完。这其实就是先在 A（可用性）方面保证系统可以正常的服务，然后在数据的一致性方面做了些牺牲，虽然多少会影响一些用户体验，但也不至于造成用户购物流程的严重阻塞。 三、总结现如今，对于多数大型互联网应用的场景，主机众多、部署分散，而且现在的集群规模越来越大，节点只会越来越多，所以节点故障、网络故障是常态，因此分区容错性也就成为了一个分布式系统必然要面对的问题。那么就只能在C和A之间进行取舍。但对于传统的项目就可能有所不同，拿银行的转账系统来说，涉及到金钱的对于数据一致性不能做出一丝的让步，C必须保证，出现网络故障的话，宁可停止服务，可以在A和P之间做取舍。
总而言之，没有最好的策略，好的系统应该是根据业务场景来进行架构设计的，只有适合的才是最好的。