模板网站的缺陷,盈润企业网站管理系统,wordpress 设置子菜单,wordpress搜索小工具CAP是分布式系统方向中的一个非常重要的理论#xff0c;可以粗略的将它看成是分布式系统的起点#xff0c;CAP分别代表的是分布式系统中的三种性质#xff0c;分别是Consistency#xff08;可用性#xff09;、Availability#xff08;一致性#xff09;、Partition tol…CAP是分布式系统方向中的一个非常重要的理论可以粗略的将它看成是分布式系统的起点CAP分别代表的是分布式系统中的三种性质分别是Consistency可用性、Availability一致性、Partition tolerance网络分区容忍性它们的第一个字母分别是C A P于是这个理论被称为CAP理论
理论上来说CAP三者同时最多满足两者但是并不是必须满足两个许多系统最多只能同时满足0、1个
为什么CAP最多只能满足两个呢?
我们可以以电商系统的两个集群来当做例子
C: 追求的是数据一致性 当有一个请求来了之后 它会等待网络隔离的情况结束之后 向另一个机器进行数据的同步
A: 追求的是可用性 也就是尽可能提供有效服务 当一个请求来了之后 它会立即返回 哪怕数据是陈旧的 也得优先提供服务其他分区的节点返回的结果数据可能是不一样
注意这里的AP不可同时满足指的是当整个分布式系统中出现网络隔离的时候我们不能既想着保证数据的实时强一致性又去追求服务的可用性。
但是当没有网络隔离的时候其实这两个性质是可以同时满足的因为『同步数据』和『返回结果』这两个操作都是在同一个网络中只有先后关系不会因为某个操作导致另一个操作的『死等』
在分布式系统中P是会必然发生的造成P的原因可能是网络隔离也可能是节点宕机。
我们无法保证分布式系统每一时刻都不出现网络隔离如果不满足P的特性一旦发生分区错误那么分布式系统就无法工作这显然违背了分布式的理念连最基本的分布式系统条件都没有满足
典型的CP和AP的产品
CPZookeeper 当系统在发生分区故障之后 客户端的所有请求都会被卡死或者超时 但是系统总会返回一致的数据
APEureka 分区发生故障之后 客户端依然可以访问系统 但是获取的数据有的是新数据 有的是老数据
当然 CAP这几个特性不是BOOL类型的而是一个范围类型完全是看系统具体需要什么样的要求。
比如分区容错有的系统一台机器出错系统会认为不影响业务的话认为分区不存在。只有多台机器都出问题了系统受到严重影响才认为出现分区
PACELC理论 PACELC理论是对CAP理论的扩展在维基百科上的定义是
It states that in case of network partitioning § in a distributed computer system, one has to choose between availability (A) and consistency © (as per the CAP theorem), but else (E), even when the system is running normally in the absence of partitions, one has to choose between latency (L) and consistency ©.
如果有分区P那么系统就必须在可用性A和一致性C之间取得平衡否则E当系统运行在无分区的情况下系统需要在延迟L和一致性C之间取得平衡
它相比于CAP多引入了一个延迟Latency的概念在出现分区错误的时候取前半部分PAC理论和CAP的内容一致。没有出现分区错误的时候取LC也就是Latency与Consistency
当前分布式系统指导理论更替代CAP理论理由如下
PACELC更能满足实际操作中分布式系统的工作场景是更好的工程实现策略 当P存在的场景下需要在A C之间做取舍但是实际上分布式系统大部分时间里P是不存在的那么在L和C之间做取舍是一个更好的选择 PACELC可以在latency与consistency之间获得平衡 要保证系统的高可用那么就得采用冗余的思想我的其他博文有提到4个9的异地多活策略也是采用的数据冗余思想而一旦涉及到了复制数据在分布式中就一定会在Consistency和Latency之间做一个取舍 image.png 举个例子
在强一致性的场景下需要三个从节点都落盘数据才能给客户端返回OK这个时候当master向slave同步数据的时候超过20ms触发超时了整个系统还是会不断的重试这个过程这显然造成了系统的可用性比较低 所以我们一般都会在数据一致性和请求时延之间做一个balance
当同步超过五次之后认为这个节点故障选择直接返回可以消除写时的长尾抖动同时给节点打上故障标签进行后续的处理
BASE理论 base理论是Basically Avaliable(基本可用)、Soft State软状态、Eventually Consistent最终一致性三个短语的缩写核心思想如下
即使无法做到强一致性但每个应用都可以根据自身的业务特点采用适当的方式来使系统达到最终一致性
BA基本可用指的是当系统出现了不可预知的故障系统依旧可用不过可用度也许会降低比如响应时间上出现损失功能上只能满足基本功能等等
S基于原子性而言的话当要求多个节点数据一致时我们认为这是一种『硬』状态而允许系统中的数据存在中间状态并认为其不影响系统的整体可用性即允许系统在多个不同节点的数据副本存在数据时延
E最终一致性系统不可能一直都处于一个软状态中必须有个时间期限。在期限过后应该保证所有副本保持数据一致性从而达到数据的最终一致性。这个时间期限取决于时延、负载、方案等等
在工程实践中有这么几种最终一致性的实现策略通常都是多种策略混合实现
因果一致性如果节点A在更新完某个数据后通知了节点B那么节点B之后对该数据的访问和修改都是基于A更新后的值。与此同时与节点A无因果关系的节点C的数据访问没有这样的限制 读已知所写节点A更新一个数据之后自身总是能访问到更新过的最新值而不会访问旧值 会话一致性将对系统数据的访问过程框定在了一个会话当中系统能保证同一个有效的会话中实现客户端在一个会话中读取到该数据项永远是最新值 单调读一致性如果一个节点从系统中读取出一个数据项的某个值之后那么系统对于该节点后续的任何数据访问都不该返回更旧的值 单调写一致性一个系统要能够保证来自同一个节点的写操作被顺序的执行。
