第六周作业

用户头像
changtai
关注
发布于: 2020 年 07 月 15 日

1. 请简述CAP原理

定义:

在一个分布式系统(指互相连接并共享数据的节点的集合)中,当涉及读写操作时,只能保证一致性(Consistence)、可用性(Availability)、分区容错性(Partition Tolerance)三者中的两个,另外一个必须被牺牲。

  • 一致性

一致性是说,每次读取的数据都应该是最近写入的数据或者返回错误,而不是过期数据,也就是说,数据是一致的。

  • 可用性

可用性是说,每次请求都应该得到一个响应,而不是返回一个错误或者失去响应,不过这个响应不需要保证数据是最近写入的,也就是说系统需要一直都是可以正常使用的,不会引起调用者的异常,但是并不保证数据是最新的。

  • 分区耐受性

分区耐受性说,即使因为网络原因,部分服务器节点之间消息丢失或者延迟了,系统依然应该是可以操作的。





在分布式环境下,必须选择 P(分区容忍)要素,因为网络本身无法做到 100% 可靠,有可能出故障,所以分区是一个必然的现象。



CA

相当于放弃使用分布式系统,是一个单点系统,比如关系型数据库 DBMS(比如 MySQL、Oracle)部署在单台机器上。



CP

如果一个分布式场景需要很强的数据一致性,或者该场景可以容忍系统长时间无响应的情况下,保 CP 弃 A 这个策略就比较适合。

一个保证 CP 而舍弃 A 的分布式系统,一旦发生网络分区会导致数据无法同步情况,就要牺牲系统的可用性,降低用户体验,直到节点数据达到一致后再响应用户。

典型的有 Redis、HBase、ZooKeeper





ZooKeeper 集群包含多个节点(Server),这些节点会通过分布式选举算法选出一个 Leader 节点。在 ZooKeeper 中选举 Leader 节点采用的是 ZAB 算法,Leader 节点之外的节点被称为 Follower 节点,Leader 节点会专门负责处理用户的写请求:

当用户向节点发送写请求时,如果请求的节点刚好是 Leader,那就直接处理该请求;

如果请求的是 Follower 节点,那该节点会将请求转给 Leader,然后 Leader 会先向所有的 Follower 发出一个 Proposal,等超过一半的节点同意后,Leader 才会提交这次写操作,从而保证了数据的强一致性。



当出现网络分区时,如果其中一个分区的节点数大于集群总节点数的一半,那么这个分区可以再选出一个 Leader,仍然对用户提供服务,但在选出 Leader 之前,不能正常为用户提供服务;如果形成的分区中,没有一个分区的节点数大于集群总节点数的一半,那么系统不能正常为用户提供服务,必须待网络恢复后,才能正常提供服务。这种设计方式保证了分区容错性,但牺牲了一定的系统可用性。



AP

如果一个分布式场景需要很高的可用性,或者说在网络状况不太好的情况下,该场景允许数据暂时不一致,那这种情况下就可以牺牲一定的一致性了。

网络分区出现后,各个节点之间数据无法马上同步,为了保证高可用,分布式系统需要即刻响应用户的请求。但,此时可能某些节点还没有拿到最新数据,只能将本地旧的数据返回给用户,从而导致数据不一致的情况。

典型的有 CoachDB、Eureka、Cassandra、DynamoDB 等。



Eureka各个节点都是平等的,几个节点挂掉不会影响正常节点的工作,剩余的节点依然可以提供注册和查询服务。而Eureka的客户端在向某个Eureka注册或时如果发现连接失败,则会自动切换至其它节点,只要有一台Eureka还在,就能保证注册服务可用(保证可用性),只不过查到的信息可能不是最新的(不保证强一致性),其中说明了,eureka是不满足强一致性,但还是会保证最终一致性



由于Zookeeper是更偏向于CP的,Eureka是偏向于AP,所以作为微服务的注册中心,更加推荐Eureka,提升注册中心的可用性。



2. 针对Doris案例,请用UML时序图描述Doris临时失效的处理过程(包括判断系统进入临时失效状态,临时失效中的读写过程,失效恢复过程)



参考:



用户头像

changtai

关注

还未添加个人签名 2018.04.30 加入

还未添加个人简介

评论

发布
暂无评论
第六周作业