目录
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就任务客户端与注册中心出现了网络故障,执行下面操作
- Eureka不再从注册列表中移除因为长时间没收到心跳而应该过期的服务
- Eureka仍然能接受新的服务注册和查询请求,但不会被同步到其他节点(保证当前节点可用)
- 当网络稳定时,当前实例新的注册信息会被同步到其他节点中
总结:Eureka当遇到部分节点失效时,不会像zk一样产生整个注册服务都瘫痪的情况
什么是BASE理论?
BASE 是 Basically Available(基本可用)、Soft state(软状态)和 Eventually consistent (最终一致性)三个短语的缩写。BASE理论是对CAP中AP的一个扩展,通过牺牲强一致性来获得可用性,当出现故障允许部分不可用但要保证核心功能可用,允许数据在一段时间内是不一致的,但最终达到一致状态。满足BASE理论的事务,我们称之为“柔性事务”
- 基本可用:分布式系统在出现故障时,允许损失部分可用功能,保证核心功能可用。如,电商网站交易付款出现问题了,商品依然可以正常浏览。
- 软状态:由于不要求强一致性,所以BASE允许系统中存在中间状态(也叫软状态),这个状态不影响系统可用性,如订单的"支付中"、“数据同步中”等状态,待数据最终一致后状态改为“成功”状态。
- 最终一致:最终一致是指经过一段时间后,所有节点数据都将会达到一致。如订单的"支付中"状态,最终会变为“支付成功”或者"支付失败",使订单状态与实际交易结果达成一致,但需要一定时间的延迟、等待。