CAP

分布式

  • C:一致性
  • A:可用性
  • P:分区容忍性

CAP场景分析:

假设我们用一台服务器A对外提供存储服务,为了避免这台服务器宕机导致服务不可用,我们又在另外一台服务器B上运行了同样的存储服务,每当用户在往服务器A写入数据时,A都往服务器B上写一份,然后再返回客户端。一切都运行的很好,用户的每份数据都分别在A和B上,用户访问任意一台机器都能读取到最新的数据。

这时候,不幸的事情发生啦:A和B之间的网络断了导致A和B无法通信,也就是说网络网络出现了分区,那么用户在往服务器A写入数据的时候,A无法将数据写入到服务器B,这时,服务器A就必须做一个艰难的选择:

要么选择一致性C而牺牲可用性:为了保证服务器A和服务器B上面数据是一致的,服务器A决定暂停对外提供写入服务,从而保证了服务器A和B上数据的一致性,凡是牺牲了可用性。注意,这里的可用性不是我们通常所说的高可用性(比如服务器宕机导致服务不可用),而是指服务器虽然还活着,但是却不能对外提供写入服务。

要么选择可用性而牺牲一致性:为了保证服务不中断,服务器A先把数据写入到本地,然后返回客户端,从而让客户端感觉数据已经写入了,这导致了服务器A和B上数据不一致了。

可用性和一致性之间的选择不是非此即彼的,而是根据业务的需求在他们两者之间做妥协:

我们可以放弃对强一致性的要求,让其变成最终一致性,也就是说当服务器不能把数据传给服务器B的时候,先将数据缓存在本地,等到网络恢复之后再将数据传给服务器B,这样,服务还是可用的,只是在一定的时间窗口内两者的数据是不一致的。

保证最终一致性,不保证实时的一致性。

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

  • 1
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值