分布式系统架构理论 - CAP、BASE
1. CAP 理论
任何分布式架构设计的系统,只能同时满足 CAP 中的任意两种,无法同时三种并存。
CAP(Consistency、Availability、Partition tolerance) 是三个单词的缩写,分别代表一致性,可用性,分区容错性。
这个理论到目前为止都适用于分布式架构系统。
1.1 Consistency 一致性
我们知道ACID中事务的一致性是指事务的执行不能破坏数据库数据的完整性和一致性,一个事务在执行前后,数据库都必须处于一致性状态。
也就是说,事务的执行结果必须是使数据库从一个一致性状态转变到另一个一致性状态。
举个例子:
A 转账 B ,A 扣款一百,B增加一百,这个是业务层级的一致性,连个业务都执行,才能保证最终一致性状态。
这种从刚开始的不变的状态,转变为另一种最终一致的状态,就是一致性。
分布式环境中的一致性是指数据在多个副本之间是否能够保持一致。这点应该不难理解,分布式集群架构中,有可能服务节点是多个,
这个时候我们就要考虑多个服务的情况下,读取的数据是否都能够一致,或者数据库集群中的数据是否都能够保证一致。
- 强一致性
要求所有系统中的数据必须一致,不管谁先执行操作,都要等到其他系统数据更新完成才能继续执行下一步。
这点就会对性能有一部分影响,因为要确保所有节点的完全一致。
数据库为例,单库的数据肯定是一致的。多库情况下,其他节点的数据必须等到日志更新所有数据库完全后才能读取,这样才会保证数据的一致性。
- 弱一致性 & 最终一致性
弱一致指数据更新后,不会立即要求所有的节点必须先同步,允许在一定时间后达到同步,这里面还有一种情况就是可能数据同步会失败,怎么办?
重试机制,失败了就再次尝试,直到最终达到一致性。
1.2 Availability 可用性
用户访问的服务会处在一种一直可用的集群状态,也就是服务高可用。能够保证一个请求在规定的有限时间返回结果。这里面还要考虑到服务
熔断、异常返回、服务降级(容错性)。这些都是微服务里面的重要概念。
1.3 Partition tolerance 分区容错性
容错性,那就是网络节点之间无法通信的情况下,节点被隔离,产生了网络分区, 整个系统仍然是可以工作的.
随着网络节点出现问题,产生了分区, 这时候其他节点和出错节点的数据必然会不一致,这时候就要面临选择,
是选择停掉所有的服务,等网络节点修复后恢复数据,以此来保证一致性(PC),
还是选择继续提供服务,放弃强一致性的要求,以此来保证整体的可用性(PA)。
2 BASE 理论
eBay的架构师Dan Pritchett源于对大规模分布式系统的实践总结,在ACM上发表文章提出BASE理论,BASE理论是对CAP理论的延伸,
核心思想是即使无法做到强一致性(Strong Consistency,CAP的一致性就是强一致性),但应用可以采用适合的方式达到最终一致性
(Eventual Consitency)
BASE是Basically Available(基本可用)、Soft state(软状态)和Eventually consistent(最终一致性)三个短语的缩写。
BASE理论是对CAP中一致性和可用性权衡的结果,是对大规模互联网系统分布式实践的总结。
BASE理论的核心思想是:即使无法做到强一致性,可以通过一些软状态和最终一致性的方式,来尽量达到一致性的要求。
2.1 基本可用
指分布式系统在出现故障的时候,允许损失部分可用性,保证核心可用。那些情况属于这种基本可用呢?
- 损失部分响应时间换取:
如果一个系统原本应该 10ms 内响应,但是现在可以允许出错后重试,可以规定重试N次,可能导致的结果就是时间变为 10*N,
或者通过网关转向可用的服务,这种情况比较乐观,可能不需要N次。
- 损失部分非核心系统功能:
正常的,我们访问一个网站服务会返回我们想要的结果,但是如果后台服务发生了雪崩或者服务降级,我们也会有降级页面返回的处理结果,
当然对于客户可能不知道后台发生了什么,只是被引导到了降级页面并看到了立即返回结果,虽然结果不是我们想要的,但是保证了
基本响应。
2.2 软状态
软状态是指允许系统存在中间状态,而该中间状态不会影响系统整体可用性。分布式存储中一般一份数据至少会有三个副本,允许不同节点间副本同步的延时就是软状态的体现。
mysql replication的异步复制也是一种体现。
2.3 最终一致性
最终一致性:各个节点的数据不一致,可以通过一系列的措施来进行更新补偿,最终达到一致性的要求。这个过程就是最终一致性。
强调的是要求最终一致,不需要实时保证系统数据的强一致。
求关注
程序领域
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
阿里云ECS服务器突发性能型t6和通用型g6实例区别在哪?哪个更好?如何选择?
阿里云ECS服务器突发性能型t6和通用型g6是阿里云的两款主力服务器机型。同属于最新一代(第六代)云服务器,都是用了最新架构,性能较强。本文说说这两款实例的区别及选择。 CPU处理器不同 突发性能型t6实例:Intel ® Xeon ® Cascade Lake处理器,2.5 GHz主频,睿频3.2 GHz;通用型g6实例:Intel ® Xeon ® Platinum 8269CY(Cascade Lake),2.5 GHz主频,睿频3.2 GHz,计算性能稳定。 通用型g6的 CPU型号明显要强过突发性能实例t6,至于具体参数都是相同的。 内存相同 搭配DDR4内存,二者内存相同。 云盘不同 通用型g6实例是I/O优化实例,也支持ESSD云盘、SSD云盘和高效云盘。突发性能型t6实例则没有提及这方面的内容。可见 g6通过 I/O优化和云盘升级,可以满足更高业务性能需要。 应用环境 突发性能型t6的适用场景如下:Web应用服务器轻负载应用、微服务开发测试压测服务应用 通用型g6实例的适用场景如下:各种类型和规模的企业级应用中小型数据库系统、缓存、搜索集群高网络包收发场景,例如视频弹幕...
- 下一篇
【云栖号直播】本周重磅推荐:宋洁与您讲述 非典与新冠背后,一个企业的生死与涅槃
云栖号在线课堂,及时了解行业动态!阿里云推出疫情专题方案,为企业业务护航,让你足不出户了解行业动态。 在这里可以走近阿里云基础产品,了解更多应用方案,还能遇见大咖分享洞见及故事!也可以通过视频的形式让你高效、生动的了解场景化的上云最佳实践。 本周重磅推荐 标题:我在阿里20年:非典与新冠背后,一个企业的生死与涅槃 简介:2003年的“非典”中,阿里有一人确认后被全员“放假”,但也正是在那一年,淘宝网正式上线,并逐渐成长为全球最大的电子商务平台。 17年过去了,被确诊的阿里巴巴女员工,如今怎么样了?听阿里巴巴合伙人、118号员工宋洁(kitty),讲述20年阿里之旅。 观看直播 标题:让机器善解人意:阿里巴巴语音技术的发展之路 简介:在本直播中,将通过对历史的回顾、现状的呈现和未来的展望,介绍达摩院语音实验室、特别是语音技术在阿里巴巴经济体的意义、定位,以及一些具体工作。我们将一窥语音技术的大图、经济体内应用,以及通过阿里云对外进行商业输出的全貌。 观看直播 标题:RocketMQ Connect 平台的搭建与实践 简介:RocketMQ Connect 是基于OpenMessaging...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- Eclipse初始化配置,告别卡顿、闪退、编译时间过长
- SpringBoot2整合MyBatis,连接MySql数据库做增删改查操作
- SpringBoot2整合Thymeleaf,官方推荐html解决方案
- SpringBoot2整合Redis,开启缓存,提高访问速度
- CentOS8编译安装MySQL8.0.19
- Docker使用Oracle官方镜像安装(12C,18C,19C)
- CentOS7,8上快速安装Gitea,搭建Git服务器
- Docker安装Oracle12C,快速搭建Oracle学习环境
- Springboot2将连接池hikari替换为druid,体验最强大的数据库连接池
- Windows10,CentOS7,CentOS8安装Nodejs环境