前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >分布式理论----CAP理论与Base理论

分布式理论----CAP理论与Base理论

作者头像
忧愁的chafry
发布2022-10-30 16:35:46
2640
发布2022-10-30 16:35:46
举报
文章被收录于专栏:个人技术笔记个人技术笔记

CAP 理论

  【1】CAP 理论指出对于一个分布式计算系统来说,不可能同时满足以下三点:

    1)一致性:在分布式环境中,一致性是指数据在多个副本之间是否能够保持一致的特性,等同于所有节点访问同一份最新的数据副本。在一致性的需求下,当一个系统在数据一致的状态下执行更新操作后,应该保证系统的数据仍然处于一致的状态。【指强一致性】

    2)可用性:每次请求都能获取到正确的响应,每一个操作总是能在确定的时间内返回,但是不保证获取的数据为最新数据。

    3)分区容错性:分布式系统在遇到任何网络分区故障的时候,仍然需要能够保证对外提供满足一致性和可用性的服务,除非是整个网络环境都发生了故障。

  【2】一个分布式系统最多只能同时满足一致性(Consistency)、可用性(Availability)和分区容错性(Partition tolerance)这三项中的两项。

  【3】在这三个基本需求中,最多只能同时满足其中的两项,P 是必须的,因此只能在 CP 和 AP 中选择,zookeeper 保证的是 CP,对比 spring cloud 系统中的注册中心 eureka实现的是 AP。【与其说是三项中选两项,本质上是在C与A之间进行二选一

  【4】分析高可用性与强一致性之间存在违背的地方:

    1.先说说可用性:每次请求都能在限定的时间内获取到正确的响应。

    2.再说强一致性:每次写入的时候,都会在leader(主节点)上先写入,然后同步给其他节点,在此阶段是不对外提供服务的。故而,follower(从节点)越多,其实不可控的时间也就越长。

    3.所以说可用性在强一致性同步数据阶段得不到保障,这就是问题。

  【5】故而市面上常说的CAP理论,其实是最终一致性,可用性,与分区容错性。如zookeeper ,说是CP架构:

    1)Leader接收Client的写请求,广播给其他Follower节点,其他节点将消息加入待写队列,向Leader发送成功消息,过半的Follower同意后,Leader向所有节点发送提交消息,Follower会落实写请求。(并不满足全部节点都写入,只是保证大多数节点的写入。此时系统的各节点数据并不保证完全一致)

    2)每一次写入的时候Leader(写入操作只能由Leader进行)都会有个ZXID,而从节点也会按照ZXID来进行顺序写入,从而最终达到与Leader的数据一致(顺序一致性)。

    3)所以总结起来zookeeper保证的是线性写,顺序读。但是拿到的数据不保证一致。

BASE 理论

  【1】BASE 是 Basically Available(基本可用)、Soft-state(软状态) 和 Eventually Consistent(最终一致性) 三个短语的缩写。

    1)基本可用:在分布式系统出现故障,允许损失部分可用性(服务降级、页面降级)。

    2)软状态:允许分布式系统出现中间状态。而且中间状态不影响系统的可用性。这里的中间状态是指不同的 data replication(数据备份节点)之间的数据更新可以出现延时的最终一致性。

    3)最终一致性:data replications 经过一段时间达到一致性。

  【2】BASE 理论是对 CAP 中的一致性和可用性进行一个权衡的结果,理论的核心思想就是:我们无法做到强一致,但每个应用都可以根据自身的业务特点,采用适当的方式来使系统达到最终一致性

一致性的类型

代码语言:javascript
复制
强一致性:又称线性一致性(linearizability )
1.任意时刻,所有节点中的数据是一样的,
2.一个集群需要对外部提供强一致性,所以只要集群内部某一台服务器的数据发生了改变,那么就需要等待集群内其他服务器的数据同步完成后,才能正常的对外提供服务
3.保证了强一致性,务必会损耗可用性

弱一致性:
1.系统中的某个数据被更新后,后续对该数据的读取操作可能得到更新后的值,也可能是更改前的值。
2.即使过了不一致时间窗口,后续的读取也不一定能保证一致。

最终一致性:
1.弱一致性的特殊形式,不保证在任意时刻任意节点上的同一份数据都是相同的,但是随着时间的迁移,不同节点上的同一份数据总是在向趋同的方向变化
2.存储系统保证在没有新的更新的条件下,最终所有的访问都是最后更新的值

顺序一致性:
1.任何一次读都能读到某个数据的最近一次写的数据。
2.对其他节点之前的修改是可见(已同步)且确定的,并且新的写入建立在已经达成同步的基础上。
本文参与 腾讯云自媒体分享计划,分享自作者个人站点/博客。
原始发表:2022-10-19,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 作者个人站点/博客 前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • CAP 理论
  • BASE 理论
  • 一致性的类型
相关产品与服务
微服务引擎 TSE
微服务引擎(Tencent Cloud Service Engine)提供开箱即用的云上全场景微服务解决方案。支持开源增强的云原生注册配置中心(Zookeeper、Nacos 和 Apollo),北极星网格(腾讯自研并开源的 PolarisMesh)、云原生 API 网关(Kong)以及微服务应用托管的弹性微服务平台。微服务引擎完全兼容开源版本的使用方式,在功能、可用性和可运维性等多个方面进行增强。
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档