分布式事务(四)--CAP--BASE理论基础

目录

一、CAP

CAP是研究分布式的一个比较经典的理论。

CAP就是Consistency、Availability、Partition Tolerence的简称。
也就是一致性,可用性,分区容忍性。

1、一致性

分布式事务(四)--CAP--BASE理论基础

1.1、一致性分类:

1、强一致性:就是图中的那种。

2、弱一致性:节点数据如果同步了,你就能查到,没同步,就查不到,结果具有不确定性。

3、最终一致性:过一段时间,等节点之间数据同步之后,就可以查到。

2、可用性

客户端往分布式系统的各个节点发送请求,都是可以获取到响应的,写入、查询等操作都是成功的。

2.1、不可用:

客户端往分布式系统中的各个节点发送请求的时候,获取不到响应结果,那么系统就是不可用了。

2.2、可用性级别:

99%,一年中只能有80小时左右是可以允许访问失败的

99.9%,一年中大概有8小时左右是可以访问失败

99.99%,一年中有大概不到1小时是可以访问失败的

99.999%,一年中有大概不到5分钟是可以访问失败的

99.9999%,一年中只能有大概不到1分钟可以访问失败

很多行业大部分的系统,其实99%可用性都没到,每年总得故障几次。能做到99.9%的系统就算是比较牛的了,毕竟一年内就几个小时不可用。

3、分区容忍性

3.1、分区partition/network partition

网络分区 => 分布式系统之间的网络环境出了故障,分布式系统的各个节点之间现在已经无法进行通信了。

遇到网络分区故障,类似于脑裂,然后系统还是可以正常对外提供服务的。

3.2、不具备分区容忍性

一旦网络故障,整套系统崩溃,你哪怕给各个节点发送消息,全部失败,整套系统甚至会宕机。

4、CAP => CP or AP

一个分布式系统不可能同时兼备一致性、可用性、分区容忍性,要么是CP(一致性 + 分区容忍性),要么就是AP(可用性 + 分区容忍性)。

基于这套理论,redis、mongodb、hbase等分布式系统,都是参照着CAP理论来设计的,有些系统是CP,有些系统是AP。

5、保证CP

1、现在网络发生故障,client向节点A发送一个插入请求,节点A将数据插入。

2、节点A发现节点B之间网络不通了,无法进行数据同步。

3、client向节点B查询数据,由于当前节点之间网络不通,直接给client返回:当前系统处于不一致状态,不能查询。

这样就保证了一致性,不会让client看到不一致的状态,同时不能保证Available。

6、AP

同样的场景下,要保证两个节点都要可用的,所以client如果在节点A能够查询这条数据,但是如果请求到了节点B就查不到了。

6.1、场景:

电商、12306,这种业务类系统,一般都是AP。

查询的商品或者火车票库存可能都是旧数据,但是当你买的时候,肯定就是要查询库存,不影响使用。

二、BASE

Basicly Available、Soft State、Eventual Consistency,也就是基本可用、软状态、最终一致性。

1、基本可用:

  • 正常情况下查询,负载均衡到各个节点去查的,多节点抗高并发,如果发生网络故障,可以选择降级。
  • 如果流量太大了,直接返回一个空,让你稍后再来查询。

2、软状态:

多个节点都是可用的,但是可能一会能查到,一会就查不到了。

3、最终一致性:

一旦故障或者延迟解决了,数据过了一段时间最终一定是可以同步到其他节点的,数据最终一定是可以处于一致性的。

上一篇:ora-00031:session marked for kill处理oracle中杀不掉的锁


下一篇:SpringMVC-文件上传和下载