第六周作业 - 简述 CAP 原理

发布于: 2020 年 07 月 16 日
第六周作业-简述CAP原理

分布式存储系统,三者无法同时满足。

C,一致性:每次读取都是最近写入的数据,数据在读的时候要么返回,要么返回最新的数据。要么报错,要不返回,只要返回就一定是最新的。

未来等待最新的数据,可能造成不可用,因为要长时间等待同步后的结果,如果返回报错也是不可用的体现。

A,可用性:不管是读写,每次都响应,不管结果正确与否,必须有响应,不能超时,但是不保障数据是最新的。为了去报可用性,每次都快速的返回,前端访问和后端同步之间是各自独立的,所以无法确保每次访问都能访问到最新的数据。也就是无法满足一致性。

P,分区耐受性一定会发生,因为有网络延迟。

C、A这两者是冲突的。不能每次都有响应,而且每次响应都是正确的,因为你有网络故障,分区一定会失效。

比如主主复制时:

在同步过程中,要高可用,就会不一致(数据复制花时间)。如果一致性,那么两个数据库同时写,但是在写入完成之前,不能读取,就影响可用性了。有些东西是无法全部满足,在架构中无法同时满足的无处不在,要进行权衡。没有一个系统是严格一致的,可用性也是,就看偏向于哪一方面,是可用性高,还是一致性高。没有一个系统做到完全高可用,完全一致性,代价非常大。

分布式环境中数据存储一定有副本,否则丢失了就无法恢复了,那么副本合适写入呢,有两种解决方案。

只要出现了数据备份,就会存在可用性A和一致性C之间的冲突,如果追求A必然会带来C的下降(高可用+最终一致性,如果追求C(强一致性),而降低A(可用性),比如写入不立马返回,而是等数据同步完后,再返回。这样虽然一致性提高了,但是在数据同步时,系统的可用性降低了。所以需要平衡。

1.一种是类似于mysql,hbase只有一个写入点(服务器自己进行主从复制),这个写入点通过心跳或者ZK进行选举,在写入主节点成功后,同步到其他副本中,比如mysql的主从复制,主主复制,hbase借助hdfs的备份机制,数据备份(默认是三份)。

2.另一种是类似于cassandra的(应用程序自己写入多个节点)、ZK,同时写入三个节点,两个节点写入成功,就算成功,这样做的好处是,可以避免出现写入时单点故障,而带来的写不可用,因为在第一种方式下,写节点只有一个,一旦坏了,虽然可以恢复,但是中间会有延迟。

上述两种方式的本质区别是,基于CAP理论进行权衡,在可用性和一致性中进行权衡。前者更看中可用性,后者更看重一致性。

在SpringCloud体系中使用Eureka作为注册中心,他是AP模型,客户端会缓存注册中心中活动的地址清单,缓存就意味着可能存在一致性问题,虽然Eureka会同步更新各客户端,但是总会存在一定的延迟。Eureka在CAP模型中选择了AP,放弃了C,如果Eureka短时不可用,或者宕机了,也不会影响客户端负载均衡,这种特性是应用集群需要的。应用集群中一般都是可用性的优先级应该高于一致性。在Dubbo中使用ZK作为注册中心,而ZK是CP模型,如果出现ZK主节点选举,或者在ZK两阶段提交时,ZK可能存在不可用情况。

CAP中,分布式环境中,为了提高这个集群并发能力、吞吐量、存储量、可用性等质量属性,必然会存在副本,存在多节点复制。多节点要保持数据一致,就必须进行同步,因为网络传输客观存在的,谁也不能确保网络0延时,无法确保网络100%高可用,正因为有这种客观条件和限制,我们无法消灭掉P,那么就要接受P存在的情况下,如何尽可能的提高集群整体的可用性和一致性。数据的一致性和集群可用性是互斥的,这给了我们一种思路,一致性和可用性的互斥是机制上的问题,必须权衡和妥协,找到一个平衡点,不要试图用技术解决理论上行不通的问题。

用户头像

吴建中

关注

还未添加个人签名 2018.04.18 加入

还未添加个人简介

评论

发布
暂无评论
第六周作业-简述CAP原理