互联网抗量架构与CAP原理

199 阅读3分钟

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

CAP原理

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

CAP指的是以下几个方面:

Consistency:数据一致性,每次请求都得到最新的正确数据或错误;

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

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

PatitionTolerance:分区伸缩性和容错性。

疑问点二:
这个概念比较抽象,很容易和可用性混淆,分区容错不就可用了吗?分区容错确实是可用性的一种实现方式。参考疑问点一对照,可用性按照可访问性来理解(包含不正确数据,甚至错误响应)。

互联网做了读写分离架构后,分区容错性在读和写上有不同的表现形式:

  1. 水平扩展:系统具有可以在流量增大时可以通过水平扩展加服务器来进行扩容,读流量可以相对容易的使用最终一致性来实现水平扩展,写流量在一些场景也可以做到,相对麻烦,并对场景要求更严格。
  2. 分区容灾:系统在部分节点故障可以通过切换到其他节点来继续提供服务,保障系统的可用性。读写流量都可以,写流量容灾比较常见的数据库主从切换,Redis主从切换等,也可以是异构介质的切换,比如DB挂了,改用Redis抗量。读流量就更简单了,直接切到不同的数据副本就可以。 CAP的排列组合如下:

image.png

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

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

image.png

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