CAP原则、网络分区

升级版点这里
CAP原则，也称为CAP定理，是在设计分布式系统时必须考虑的三个基本需求。

1.一致性（Consistency）:在分布式系统中的所有数据备份，在同一时刻是否为同样的值。【所有节点访问同一份最新的数据副本】

2.可用性（Availability）:保证每个请求不管成功或者失败都有响应。【即系统提供的方服务一致处于可用的状态，每次请求都能获得正确的响应】

3.分区容错性（Partition tolerance）：系统中任意信息的丢失或失败不会影响系统的继续运作。【即分布式系统在遇到任何网络分区故障的时候，仍然能够对外提供满足一致性和可用性的服务】

CAP原则，这三个要素最多只能同时实现两点，不可能三者兼顾。
在进行分布式架构设计时，必须做出取舍。
当前一般是通过分布式缓存中各节点的最终一致性来提高系统的性能，通过使用多节点之间的数据异步复制技术来实现集群化的数据一致性。

CAP原则的选择策略和应用场景：
1.一致性优先（CP）：这种策略考虑一致性和分区容错性。这种原则的数据库对分布式系统内的通信要求比较高，但通常性能不是特别高。
应用：火车票售票系统【保证数据的一致性】
注册中心选用：Zookeeper。
CP类型的数据库：Google的BigTable和HBase，MongoDB

2.可用性优先（AP）：这种策略考虑可用性和分区容错性。这种原则的数据库可用更快的响应外部访问数据。
缺点：数据的一致性可能得不到满足或者对一致性要求低一些，各节点之间的数据同步没有那么快，但能保证数据的最终一致性。
应用：博客系统。
注册中心选用：Eureka。
AP类型数据库：NoSQL(Riak,DynamoDB)，Cassandra和CouchDB

3.一致性和可用性同时满足（CA）：这种策略满足数据的一致性和高可用性，但没有扩展性，不考虑分区容忍性。
应用：超市收银系统、图书管理系统。
CA类型数据库：实际上在分布式环境中，由于网络分区是无法避免的，因此纯粹的CA类型的数据库几乎不存在。
大多数传统的关系型数据库（如MySQL、Oracle等）在单一节点上运行时，可以被视为CA系统。但是当他们扩展到分布式环境时，就必须处理网络分区的问题，因此不能同时保证一致性和可用性。

拓展：网路分区是什么
网络分区是在分布式系统中，由于网络故障导致节点之间的通信中断，使得集群中的节点形成不同的子集。在每个子集中，节点之间的网络是相通的，但是子集与子集之间的网络是不通的。
这种情况下，每个子集可能会独立的进行决策，比如选举新的领导者，这可能会导致数据的不一致性。因此，网络分区是分布式系统设计中需要考虑和处理的一个重要问题。

常见的处理网络分区的策略：
1.心跳检测：【节点定期发送心跳信息，如果一个节点在一定时间内没有收到另一个节点的心跳信息，那么它就会认为那个节点已经失效，从而触发相应的故障处理机制】
2.租约机制：【节点在一定时间内需要向其他节点发送租约续约请求，如果在租约时间内没有收到续约请求，就认为该节点已经失效。】
3.副本同步：【通过数据副本来提高系统的可用性和一致性。当网络分区发生时，可以通过读取数据副本来提供服务。】
4.最终一致性：【在网络分区恢复后，通过一些机制（如向量时钟、版本向量等）来确保所有的副本最终达到一致的状态。】
5.分区切换：【当检测到网络分区时，可以将流量切换到可用的分区，以保持系统的可用性。】

如何选择：

数据一致性需求：如果系统需要强一致性，可能需要选择心跳检测或租约机制来及时检测节点失效，并通过副本同步来保证数据一致性。

系统可用性需求：如果系统需要高可用性，可能需要选择最终一致性或分区切换策略，以确保在网络分区发生时，系统仍然可以提供服务。

系统复杂性：一些策略可能会增加系统的复杂性。例如，实现副本同步和最终一致性可能需要更复杂的算法和更多的系统资源。

网络环境：如果你的系统运行在网络环境不稳定的地方，可能需要选择更健壮的分区切换。

业务场景：不同的业务场景可能需要不同的策略。例如，银行系统可能需要强一致性，而社交网络可能更关注可用性。