互联网抗量架构与CAP原理

互联网的架构，本质是权衡，CAP原理指出了哪些因素是不可兼得的。

CAP原理

C，A，P分别指的是互联网架构三个方面收益，CAP原理指的是鱼和熊掌不可兼得，我们没有办法同时得到CAP得所有好处，需要根据应用场景进行权衡取舍。

CAP指的是以下几个方面：

Consistency：数据一致性，每次请求都得到最新的正确数据或错误；

Availibility：可用性，每次请求都能得到响应，但不一定是最新的正确数据。实现方式一般为：系统发生故障的时候，故障切换要足够快，对于客户一直可用。(不存在百分之百可用的系统，这里的可用性，是切换足够快，快到用户基本感知不到发生故障切换)

疑惑点一：系统返回错误算可用吗？ 1.如果不算，那么目前实现可用性的方法之后分区+容灾切换，可用性就必然有分区容错性。AC架构不就是个伪命题？没有P分区损害后其实是不可用的。 2.如果算，那么可用性更多的是指可访问性，尽可能正确的概念，这条理解CAP整体理论才通。 PatitionTolerance：分区伸缩性和容错性。

疑问点二： 这个概念比较抽象，很容易和可用性混淆，分区容错不就可用了吗？分区容错确实是可用性的一种实现方式。参考疑问点一对照，可用性按照可访问性来理解(包含不正确数据，甚至错误响应)。 互联网做了读写分离架构后，分区容错性在读和写上有不同的表现形式： 1. 水平扩展：系统具有可以在流量增大时可以通过水平扩展加服务器来进行扩容，读流量可以相对容易的使用最终一致性来实现水平扩展，写流量在一些场景也可以做到，相对麻烦，并对场景要求更严格。 2. 分区容灾：系统在部分节点故障可以通过切换到其他节点来继续提供服务，保障系统的可用性。读写流量都可以，写流量容灾比较常见的数据库主从切换，Redis主从切换等，也可以是异构介质的切换，比如DB挂了，改用Redis抗量。读流量就更简单了，直接切到不同的数据副本就可以。 CAP的排列组合如下：

互联网的选择AP+(弱化的C)

面对这三个选择，互联网必须保证用户对系统的可用性(A必须要)，分区节点故障的容灾能力P也必须要，大部分场景只能选AP方案了,C进行弱化，只保证最终一致性。

「AP加最终一致性的C减理论」构成了互联网抗量架构的根基，而抗读抗写的具体架构都是「AP+C减」的实践。