标签：可用性 -- 分区 CAP BASE 容忍性 一致性 节点
目录一、CAP
CAP是研究分布式的一个比较经典的理论。
CAP就是Consistency、Availability、Partition Tolerence的简称。
也就是一致性，可用性，分区容忍性。
1、一致性
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、最终一致性：
一旦故障或者延迟解决了，数据过了一段时间最终一定是可以同步到其他节点的，数据最终一定是可以处于一致性的。
标签：可用性,--,分区,CAP,BASE,容忍性,一致性,节点 来源： https://www.cnblogs.com/huigelaile/p/15780343.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。