我们在CAP理论中保证强一致性必然会影响到可用性,比如,采用两阶段提交协议的集群系统中,如果执行提交操作,需要所有节点的确认和投票
所以,为了保证可用性,一般我们会考虑使用合适的AP模型
那么,难道没有现成的方案来实现合适的AP模型,这时候就先考虑是否能运用上BASE理论
BASE理论是AP的眼神,是对互联网大规模分布式系统的总结,很多互联网后台都有BASE支持,可以根据这个设计出合适的高可用的分布式西永
核心总结为
基本可用性 Basically Available
最终一致性 Eventually consistent
软状态 Soft state 实现服务可用性时候系统数据的一种过渡状态,数据副本的短暂不一致
那么合适体现BASE理论的四板斧
BASE理论可以认为是一个弹簧,在收到外界的压迫的时候,会不断的收缩,以便适应外力
那么可以类比12306的订票系统来进行设计
12306在出售火车票的时候,会在不同区域,设计不同的开售时间,来讲访问请求错开,比如往北京的8点卖,往上海的9点开卖,这就是流量削峰
然后还有就是在请求购票时候的排队操作,这就是延迟响应机制
再好比微博的处理操作,如果出现了一个特殊的网络热点事件,就会出现好多的用户涌入,导致海量的突发请求,系统过载了,导致显示不出图片
这时候可以想到一个处理方式,就是体验降级,比如图片使用小图片来代替原始图片,降低视频清晰度,提高处理能力
使用过载保护,将接收到的请求放在指定的队列中处理,如果出现了超时的或者无法访问的,直接拒绝访问请求从队列中清理掉,保证系统的基本可用
上面的方案中,都是去牺牲部分的功能可用性,来保证服务的基本空性
对于分布式系统的开发过程中,不仅仅需要掌握流量削峰,延迟响应,体验降级,过载保护这四板斧,还需要知道背后的思考
还有就是BASE里面体现的最终一致性
系统之中所有的数据副本在一定时间后,都能达到一个一致的状态,存在着一个短暂的延迟
大部分的互联网的系统的都是最终一致性,基本不会先采用强一致性,只有金融业务才会使用
当然,可以将强一致性认为是最终一致性的特例,强一致性看做是不存在延迟的一致性
如何实现最终的一致性,基本上分布式的数据都有两种场景情况,
一种是最新写入的数据为准,这样AP模型KV存储采用的就是这种方式
一种是数据不会变化,可以以其为准
实现最终一致性的方式,常用有
读时修复,我们会读取数据的时候,检测数据的不一致,进行修复,比如Cassndra的Read Repair实现
写时修复,写入数据的时候,检测数据的不一致,进行修复,比如Cassandra的Hinted Handoff.节点之间进行远程写数据的时候,发现写入失败,就会将数据进行修复
异步修复,这是最常用的方式,定期检测是否一致性,并修复
这样的话,我们说写时修复,不需要做数据一致性的对比,性能消耗比较低,对系统运行影响不大,这样,也是比较适合实现的方式,所以优先的考虑
在实现最终一致性的时候,最好保证有着对应的自定义写一致性级别 All Quorum One Any,可以自主的选择对应的一致性级别,比如设置为All,来实现一致性
简单的一个实现手段
我们来看下自研的InfluxDB系统的DATA集群,看BASE理论,如何保证可用性
DATA节点的核心功能是读和写,所以基本可用的指读和写的基本可用,那么可以通过分片和多副本来保证读写的基本可用,比如下面,就是3节点2副本,就能保证超过一半的节点故障了,不然就能保证读和写
本章,我们通过BASE理论的讲解开始,进行了BASE理论的支持
1.BASE理论是对CAP的一致性和可用性的权衡结果,对大规模的互联网网分布式的事件总结,基于CAP的定理逐步演进的,核心思想是,不是必须的话,不推荐实现事务或者强一致性,鼓励保证数据的最终一致性
2.BASE理论主张通过牺牲部分功能的可用性,实现整体的基本可用,通过服务降级,保证极端下的系统可用性
3.ACID是传统数据库的设计理论,追求强一致性模型,BASE理论支持的大型分布式系统,通过牺牲强一致性保证了高可用性,BASE理论在很大的程度上,解决了事务性系统在性能,容错,可用性的通断,是NoSSQL系统的设计理论支持
除了流量削峰,延迟响应,体验降级,过载保护,还有什么方法可以实现基本可用
不能一味的缩小服务范围,还可以扩展服务能力,比如使用云平台的弹性扩容功能来进行服务