CAP理论&Base理论

目录

CAP理论的核心

ZK与Eureka

什么是BASE理论？

---

 

CAP理论的核心

 

一个分布式系统不可能同时很好的满足一致性、可用性和分区容错性这三个需求

Consistency:指的是写操作后进行的读操作可以读取到最新的数据状态。为了保证这一特性主从同步过程会对“写”产生一定延迟

Availability：指的是所有操作都会得到响应结果，并且不会出现响应超时或错误。即任何时候分布式系统都能提供正常服务

Partition tolerance：分布式系统部署在不同的网络中，容错性要求即使网络问题导致通信失败仍可以对外提供服务

 

 

ZK与Eureka

 

• Zookeeper保证的是CP

当注册中心查询服务列表时，我们可以容忍注册中心返回的是几分钟以前的注册信息，但不能接受服务直接down掉不可用。当master节点因为网络故障与其他节点失去联系时，剩余节点会重新进行leader选举。问题在于选举leader的时间可能在120s以内，且选举期间整个zk集群都是不可用的，这就导致在选举期间注册服务瘫痪。在云部署的环境下，因为网络问题使得zk集群失去master节点是较大概率会发生的。虽然服务最终恢复，但漫长的选举时间导致注册长期不可用是不能容忍的。

 

• Eureka保证的是AP

Eureka优先保证可用性，Eureka各个集群节点都是平等的，几个节点挂掉不会影响正常节点的工作，剩余节点仍然可以提供注册和查询服务，而eureka的客户端向某个Eureka注册时，如果连接失败则会自动切换至其他节点，只要有一台eureka还在，就能保证注册服务的可用性，但可能查到的信息不是最新的。Eureka的自我保护机制当15分钟内超过85%的节点都没有正常信息时，Eureka就任务客户端与注册中心出现了网络故障，执行下面操作

1. Eureka不再从注册列表中移除因为长时间没收到心跳而应该过期的服务
2. Eureka仍然能接受新的服务注册和查询请求，但不会被同步到其他节点(保证当前节点可用)
3. 当网络稳定时，当前实例新的注册信息会被同步到其他节点中

 

总结：Eureka当遇到部分节点失效时，不会像zk一样产生整个注册服务都瘫痪的情况

 

 

什么是BASE理论？

 

BASE 是 Basically Available(基本可用)、Soft state(软状态)和 Eventually consistent (最终一致性)三个短语的缩写。BASE理论是对CAP中AP的一个扩展，通过牺牲强一致性来获得可用性，当出现故障允许部分不可用但要保证核心功能可用，允许数据在一段时间内是不一致的，但最终达到一致状态。满足BASE理论的事务，我们称之为“柔性事务” 

• 基本可用:分布式系统在出现故障时，允许损失部分可用功能，保证核心功能可用。如，电商网站交易付款出现问题了，商品依然可以正常浏览。
• 软状态:由于不要求强一致性，所以BASE允许系统中存在中间状态（也叫软状态），这个状态不影响系统可用性，如订单的"支付中"、“数据同步中”等状态，待数据最终一致后状态改为“成功”状态。
• 最终一致:最终一致是指经过一段时间后，所有节点数据都将会达到一致。如订单的"支付中"状态，最终会变为“支付成功”或者"支付失败"，使订单状态与实际交易结果达成一致，但需要一定时间的延迟、等待。