分布式理论

CAP

一个系统最多能满足CAP中的两项,在系统设计中，对于不同的系统的一致性要求不一样，要对CAP的C和P进行取舍,例如看B站,用户不需要在同一时间看到所有相同的评论,而在商场中买东西需要强一致性。

CAP理论忽略网络延时,如各个副本的数据复制的时间。

CAP理论关注的是在绝对情况下 工程上,可用性和一致性并不是完全对立的,关注的往往是如何在保持相对一致性的前提下，提高系统的可用性

三个理论

一致性(Consistency)

在数据操作后,所有节点在同一时间的数据完全一致，等同于所有节点拥有数据的最新版本

可用性(Availability)

服务一直可用性

分区容忍性(PartitionTolerance)

当部分节点或者网络分区之前系统不可达的情况下,仍能对外提供满足一致性和可用性的服务

CP&AP

CP

放弃可用性，追求一致性和分区容错性

如ZooKeeper就是采用了 CP一致性ZooKeeper 是一个分布式的服务框架，主要用来解决分布式集群中应用系统的协调和一致性问题

AP

放弃强一致性，追求分区容错性和可用性

如Eureka 是 Spring Cloud 微服务技术栈中的服务发现组件Eureka 的各个节点都是平等的，几个节点挂掉不影响正常节点的工作剩余的节点依然可以提供注册和查询服务，只要有一台 Eureka 还在，就能保证注册服务可用只不过查到的信息可能不是最新的版本，不保证一致性

BASE理论

基本可用(Basically Available)

不追求CAP中的任何时候,读写都是成功的而是系统能够基本运行,一直提供服务基本可用强调了分布式系统在出现不可预知故障的时候,允许损失部分可用性

软状态(Soft-state)

软状态可以对应 ACID 事务中的原子性,在 ACID 的 事务中,实现的是强制一致性其中的原子性 (Atomicity) 要求多个节点的数据副本都是一致的,强调数据的一致性原子性可以理解为一种“硬状态 软状态则是允许系统中的数据存在中间状态,并认为该状态不影响系统的整体可用性即允许系统在多个不同节点的数据副本存在数据延时

最终一致性(EventuallyConsistent)

数据最终会达到一致性

一致性

强一致性

当更新操作完成之后，任何多个后续进程的访问都会返回最新的更新过的值根据 CAP 理论，这种实现需要牺牲可用性

弱一致性

系统在数据写入成功之后，不承诺立即可以读到最新写入的值，也不会具体的承诺多久之后可以读到用户读到某一操作对系统数据的更新需要一段时间，这段时间称为“不一致性窗口”