写在前面
在这篇文章 我们分析了分布式系统中的CAP理论,但是CAP理论其实并不是完全适用于现代的互联网系统的,当我们将系统设计为CP时,此时假设我们的系统有3个节点,如果每个节点的可用性是99.9%,则整个集群的可用性就是99.7%,则每个月集群不可用的时间是(30*24*60)*0.003=129.6分钟
,一个月就有超过两个小时的时间集群不可用,简直就是灾难级了,这还只是3个节点,节点越多会越严重,这么看来CP显然是有很大问题的。接着再来看AP,AP的问题是过分要求可用,现在我们考虑流量突增的场景,为了满足A,我们可能需要额外的机器来stand by,但是这些stand by的机器虽然在平时用不到,但也是需要额外的成本的,即要多花钱
,这有时候可能都是得不偿失的,为了解决这个问题,当大规模分布式系统在实践中不断的被应用后,一个对于AP升级后的全新理论就被被提出来了,这既是BASE,也是我们本文的绝对主角,下面我们就一起看下吧!
1:BASE
1.1:理论分析
BASE理论的核心思想是基本可用
和最终一致性
,这里的基本可用就是basically available,也就是BASE中的BA
,最终一致性就是eventually consistency,也就是BASE中的E
,注意这里的最终一致性中的最终
,说明这个一致是有一个过程的,而这个过程叫做是Soft State
,也就是BASE中的S
,因此BASE的组成如下:
BA:basically available
S:soft state
E:eventually consistency
我们可以看到以上的带有妥协性的词汇,基本
,最终
这其实都是一种对于设计的妥协,对于AC结合现代互联网实际情况的一种升级。
1.2:理论实现
1.2.1:基本可用
包括但不限于如下4中方式
流量削峰(业务无损):在可预料的场景中,通过程序控制来分散流量到不同的时间点,如12306春运购票,在不同的时间点发放不同热点城市的车票,如8点发放北京的,9点发放上海的
延迟响应(业务无损吧我认为,毕竟只是慢了点):基于任务队列延迟处理,保证核心业务正常
体验降级(业务无损):如因为流量激增,导致商品图片无法显示,此时就可以考虑返回较低清晰度图片,降低服务器压力,这就是体验降级,视频等也是同样的道理,用户依然在使用,但体验不那么好了。
过载保护(业务有损):超过一定量后,直接拒绝请求。
不同的方式要根据自己具体的业务场景来做出最优选择,不可一概而论。
1.2.2:最终一致性
最终一致性描述的是,所有的数据副本并非立即达到数据的一致性状态,而是经过一段时间之后,才达到一致性的状态,一般有如下几种方式实现最终一致性:
1:读时检测,在读数据时检测是否为最新数据,不是则修改为最新数据
2:写时检测,在写数据时检测是否为最新数据,不是则修改为最新数据
3:异步检测,通过异步的方式来定时检测数据是否为最新数据,不是则修改为最新数据
写在后面
小结
本文先分析了CAP理论对于现代互联网系统的不足,并分析了其问题,从而引出了BASE理论,然后分析了BASE理论的基本可用
,最终一致性
,最后给出了实现基本可用和最终一致性的常用方案。希望本文能够帮助到你。