阿里1面:谈一谈CAP

简介: CAP定理

引言

在理论计算机科学中,CAP定理(CAP theorem),又被称作布鲁尔定理(Brewer's theorem),它指出对于一个分布式计算系统来说,不可能同时满足以下三点:
  • 一致性(Consistency) (等同于所有节点访问同一份最新的数据副本)
  • 可用性(Availability)(每次请求都能获取到非错的响应——但是不保证获取的数据为最新数据)
  • 分区容错性(Partition tolerance)(以实际效果而言,分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性,就意味着发生了分区的情况,必须就当前操作在C和A之间做出选择)

    根据定理,分布式系统只能满足三项中的两项而不可能满足全部三项。理解CAP理论的最简单方式是想象两个节点分处分区两侧。允许至少一个节点更新状态会导致数据不一致,即丧失了C性质。如果为了保证数据一致性,将分区一侧的节点设置为不可用,那么又丧失了A性质。除非两个节点可以互相通信,才能既保证C又保证A,这又会导致丧失P性质。

这个定义读下来是不是让人看的一脸懵逼,多读几遍是不是又会觉得有那么点明白了。CAP 理论听起来十分抽象,本文尝试以生活中的例子并用通俗易懂的语言来解释 CAP 理论的含义。

CAP小故事

这个故事感觉讲的还是挺有意思的,大家点击链接https://zhuanlan.zhihu.com/p/265670196进去看看或者点击阅读原文进行阅读。相信看了这个小故事之后,再来看看前面的定义可能会觉得
更好理解了。

Cap的权衡

通过CAP理论我们可以无法同时满足一致性、可用性和分区容错性这三个特性,那么我们需要舍弃哪些呢?

选择CA放弃 P

这种情况的话在分布式系统中基本是不可能存在的。因为在分布式环境下分区是必然的,如果我们要舍弃P就意味着我们要舍弃分布式系统,所以也就没必要再来讨论CAP理论了,

选择CP放弃A

一个分布式系统如果不能做到可用性,经常宕机或者停止提供服务的话,这样的话用户体验是非常差的,就像曾经的“微盟删库事件”,只有等到所有的数据都被找回来才会继续对外提供服务,这期间停机多久,给商家造成了的多大的损失。我们常见的CP分布式系统有分布式数据库(redis)等,以及Zookeeper等都是优先保证数据的强一致性,来舍弃系统的可用性。

放弃AP放弃C

如果要保证高可用并允许分区,则需要放弃一致性。一旦网络问题发生,节点之间可能会失去联系。
为了保证高可用,需要在用户访问时可以马上得到返回,则每个节点只能用本地数据提供服务,而这样会导致全局数据的不一致性。
现如今应该大多数场景都是会选择可用性,而去牺牲一致性(保持最终一致性),就像我们春节抢红包的时候,它不会立马告诉你抢了多少金额,只是提示你过多久再去查看。
以及我们春节抢票的时候,明明看到这辆高铁还是邮票的但是等你填完验证码,以及乘客信息真正提交订单的时候就告诉你没票了,你再返回列表页查看该车次的时候,也还继续显示着有票
。这些虽然用户体验有那么一丢丢的不友好,但是也能接受。

小结

CAP的选择的话没有哪种更好,只有根据自己的业务场景来选择,选择适合自己的才是最好的。

Base理论

BASE:全称:Basically Available(基本可用),Soft state(软状态),和 Eventually consistent(最终一致性)三个短语的缩写,来自 ebay 的架构师提出。Base 理论是对 CAP 中一致性和可用性权衡的结果,其来源于对大型互联网分布式实践的总结,是基于 CAP 定理逐步演化而来的。其核心思想是:

既是无法做到强一致性(Strong consistency),但每个应用都可以根据自身的业务特点,采用适当的方式来使系统达到最终一致性(Eventual consistency)。

Basically Available(基本可用)

什么是基本可用?牺牲性能(服务响应时间)、体验(部分功能体验)以保证基本可用。
牺牲性能:比如我们查询商品正常情况响应时间都是1s左右返回结果,但是基本可用的话返回结果都是10s返回结果。
牺牲体验:比如双十一的时候,淘宝只会保证核心功能可用(下单、支付等),其他非核心(退货、修改地址等)的功能都会进行降级,关于降级可以看下以前这个文章《高并发系统三大利器之降级》

Soft State(软状态)

允许不影响整体可用性的中间状态 即允许系统在多个不同节点的数据副本存在数据延时。

Eventual Consistency(最终一致性)

上面说软状态,然后不可能一直是软状态,必须有个时间期限。在期限过后,应当保证所有副本保持数据一致性。从而达到数据的最终一致性。
这个时间期限取决于网络延时,系统负载,数据复制方案设计等等因素。

系统能够保证在没有其他新的更新操作的情况下,数据最终一定能够达到一致的状态,因此所有客户端对系统的数据访问最终都能够获取到最新的值。

结束

  • 由于自己才疏学浅,难免会有纰漏,假如你发现了错误的地方,还望留言给我指出来,我会对其加以修正。
  • 如果你觉得文章还不错,你的转发、分享、赞赏、点赞、留言就是对我最大的鼓励。
  • 感谢您的阅读,十分欢迎并感谢您的关注。

站在巨人的肩膀上摘苹果:
https://zh.wikipedia.org/wiki/CAP%E5%AE%9A%E7%90%86
https://www.hollischuang.com/archives/666
https://www.cnblogs.com/stateis0/p/9062123.html

目录
相关文章
|
10月前
|
监控 测试技术 数据库连接
RunnerGo API 性能测试实战:从问题到解决的全链路剖析
API性能测试是保障软件系统稳定性与用户体验的关键环节。本文详细探讨了使用RunnerGo全栈测试平台进行API性能测试的全流程,涵盖测试计划创建、场景设计、执行分析及优化改进。通过电商平台促销活动的实际案例,展示了如何设置测试目标、选择压测模式并分析结果。针对发现的性能瓶颈,提出了代码优化、数据库调优、服务器资源配置和缓存策略等解决方案。最终,系统性能显著提升,满足高并发需求。持续关注与优化API性能,对系统稳定运行至关重要。
|
7月前
|
存储 缓存 NoSQL
Redis核心数据结构与分布式锁实现详解
Redis 是高性能键值数据库,支持多种数据结构,如字符串、列表、集合、哈希、有序集合等,广泛用于缓存、消息队列和实时数据处理。本文详解其核心数据结构及分布式锁实现,帮助开发者提升系统性能与并发控制能力。
|
9月前
|
存储 安全 Ubuntu
从Linux到Windows:阿里云服务器系统镜像适配场景与选择参考
阿里云为用户提供了丰富多样的服务器操作系统选择,以满足不同场景下的应用需求。目前,云服务器的操作系统镜像主要分为公共镜像、自定义镜像、共享镜像、镜像市场和社区镜像五大类。以下是对这些镜像类型的详细介绍及选择云服务器系统时需要考虑的因素,以供参考。
|
12月前
|
人工智能 关系型数据库 Serverless
【满血+高速+不限流+超长上下文+知识库+可定制+可分享】阿里云专属DeepSeek R1极速部署教程
本文教您在阿里云部署专属DS服务,实现满血、高速、不限流和超长上下文,支持知识库分享与客服等应用。基于阿里云百炼和云应用开发平台(CAP),通过AgentCraft平台一键部署,简单易用,适合普通用户。您可以轻松搭建家庭医生助理、行业动态机器人或图画工具等,享受高效AI服务。
【满血+高速+不限流+超长上下文+知识库+可定制+可分享】阿里云专属DeepSeek R1极速部署教程
|
网络虚拟化 数据安全/隐私保护 网络架构
无线网络管理设备
无线网络管理设备
963 3
|
物联网 5G 数据处理
|
网络协议 Java Unix
从0到服务器开发——TinyWebServer(上)
从0到服务器开发——TinyWebServer
1083 1
|
存储 开发框架 Java
【CLR C#】浅谈.Net的GC(垃圾回收)机制及其整体流程
在.NET程序开发中,为了将开发人员从繁琐的内存管理中解脱出来,将更多的精力花费在业务逻辑上,CLR提供了自动执行垃圾回收的机制来进行内存管理,开发人员甚至感觉不到这一过程的存在。.NET程序可以找出某个时间点上哪些已分配的内存空间没有被程序使用,并自动释放它们。自动找出并释放不再使用的内存空间机制,就称为垃圾回收机制。本文主要介绍.Net中的GC(垃圾回收)机制及其整体流程。
【CLR C#】浅谈.Net的GC(垃圾回收)机制及其整体流程
|
Java 应用服务中间件
IDEA的Web项目启动Tomcat出现404错误
IDEA的Web项目启动Tomcat出现404错误
981 0
IDEA的Web项目启动Tomcat出现404错误
金润·高速通-高速通行费查验接口文档
高速通行费查验接口介绍:查询企业/个人(ETC开户人/车辆所有人)名下所有车辆,月/周通行费用总值 更新时间:实时 接口类型:API接口 数据优势:直连交通部路网中心,合法合规、权威、精确 数据安全:仅提供月/周通行费用总值,保护个人信息隐私 计费方式:核验计费,详情请咨询
金润·高速通-高速通行费查验接口文档