专栏首页全栈码农画像墙裂推荐:这可能是CAP理论的最好解释

墙裂推荐:这可能是CAP理论的最好解释

> 英文蓝本:http://ksat.me/a-plain-english-introduction-to-cap-theorem 经过小码甲意译、原创配图, 建议收藏。


你可能经常听到CAP定理, 这个定理描述了在设计分布式系统时的天然约束。就像其他文章一样, 本文以现实场景对比理解CAP定理。

1.记忆公司

昨晚你的老婆过生日,你这个渣男记得并精心准备了生日礼物,夫妇相视一笑。 一个天才创意在你头脑中产生:既然人们的记忆通常不好,而我偏偏擅长记忆,那我为什么不利用记忆天赋开创一番事业。

立马行动, 你制作了【记忆公司】的开业广告:

Remembrance Inc! - Never forget, even without remembering! Ever felt bad that you forget so much? Don’t worry. Help is just a phone away! When you need to remember something, just call 555—55-REMEM and tell us what you need to remember. For eg., call us and let us know of your boss’s phone number, and forget to remember it. when you need to know it back.. call back the same number[(555)—55-REMEM ] and we’ll tell you what’s your boss’s phone number. Charges : only $0.1 per request

记忆公司的日常业务通话记录:

•客户:喂,你好,你可以存储我邻居的生日吗?•你:可以,您说。•客户:1月2号•你:记录(在笔记本这个客户页上记下信息), 好的,欢迎下次垂询。•客户:谢谢•你:请支付1元

2.业务扩张

凭借创意和人品,【记忆公司】的规模越做越大,而成本只需要笔记本和电话。

当你某天生病不能工作时,你会损失一天的收入;更不用说当天想要信息的客户会因此发狂。

你有了新计划:

1. 你和你老婆分别使用分机2. (555)—55-REMEM 客服电话不变3. 客服电话会转到空闲的分机号

3.第一次业务宕机

有一天你收到老客户罗志祥的电话,要求查询"明天的约会安排";

你一脸蒙蔽,我不知道啊,你的记忆页上没这个信息啊; 客户咣当挂断了电话。

当天复盘, 猜想是昨天罗志祥把业务电话打到我老婆那里了,事实确实如此。

你们都意识到分机号带来的新问题。

多么可怕的分布式设计中的缺陷!你的分布式系统是不一致的!总会有一个时机,客户会将业务电话打到你们其中一个;在下一次拨号时,客户就可能收到不一致的信息。

4.修复一致性问题

睡前吹风时间, 你想到一个主意:

• 当我们其中一个人接到客户新的记忆业务,我们会在挂电话之前告诉另一个人• 这样我们都能在笔记本上记下新业务• 当客户查询时,我们两个都可以轻松应对

这里有一个问题:当其中一人收到新业务电话,两人就不能并行工作了。 例如:当你收到新业务并告诉我记录信息时, 我不能接其他电话。

但是这个问题也不大,因为大部分都是查询业务(可以再拨电话重试),我们首要的是确保信息正确。

你老婆进一步提出:如果某天你不在岗,我收到新业务,你的笔记本不能得到最新信息,这就会有可用性问题, 因为我没能通知你,我就不能挂断电话完成这单业务。

5. 更优方案

你慢慢理解了分布式系统中的“一致性”和“可用性”。你提出了更优方案:

1. 收到新业务电话, 挂电话前通知对方,这样两个人都能记下信息2. 某天其中一人不在岗,另外一人收到新业务电话 ,给缺岗者发一封邮件3. 第二天缺岗者上岗查收邮件,更新自己的笔记本。

Nice, 现在一致性和可用性都满足了。

6. 老婆难养

使用优化方案,一切都很顺利,你们的笔记本是一致的,当你们其中一人不在岗系统也能很好的运作。

但是, 凡事都有但是, 某天你们都在岗,但是你老婆嫌你碗没洗干净,今儿不想理你,收到新业务不通知你了,你的查询业务就有问题了

你的方案包含了“一致性”,“可用性”, 但是不满足“分区容错”。

为了满足“分区容错”, 你可以自我下线(直到你们修复关系),让你老婆一人接手业务,但是你的系统就不可用了

7.结论

我们回过头看CAP定理:在设计分布式系统时,“一致性Consistency ”“可用性Availability”“分区容错Partition Tolerance” 你只能满足两个。

•Consistency:一旦接受了客户的新业务,在客户后续查询时必须得到最新的信息•Availability:只要你们一人在岗,记忆公司就一直提供服务 (节点下线的角度)•Partition Tolerance:你们夫妻二人闹矛盾了,记忆公司依旧运作(节点连通性角度)有了这样的场景,理解CP、AP、CA就不难了

雇佣工具人-->最终一致性

雇佣工具人,更新[未更新的人]的笔记本,相比你老婆实时通知你更新, 这个工具人有个好处是在后台跑腿,你们两个业务都不会阻塞。

这也是很多NoSql的工作方式:一个节点在本地更新,后台进程同步到其他节点, 唯一存在的问题是少数时候丢失一致性。

你老婆收到新业务,工具人还没来得及跑腿,客户就立即回拨并转到你的分机,你给出不一致的答复。这种情况有限,因为客户不会如此迅速忘记事情。

这就是CAP定理和最终一致性的现实解释。

本文分享自微信公众号 - Dotnet Plus(nodotnet),作者:小码甲

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2021-04-16

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 支付宝的架构到底有多牛逼?

    自 2008 年双 11 以来,在每年双 11 超大规模流量的冲击上,蚂蚁金服都会不断突破现有技术的极限。

    芋道源码
  • 全栈设计师技术Wiki之Polyfills

    Polyfills 一项主要用于 web 前端开发的技术。 Polyfills 允许 Web 开发人员使用 HTML5 的 API ,而不管它是否受用户的浏览器...

    mixlab
  • 《从0开始学架构》读书笔记

    本质是通过冗余实现高可用(多台、多机房、多通道), 但是冗余带来了更大的复杂性. 比如任务分配器(例nginx)连接检测、管理、维护、中断处理.

    用户2825413
  • DotNet.CAP,或是.NET唯一靠谱的开源分布式框架!

    .NET5、容器化、K8S、分布式、微服务、DevOps、云原生,热门的技术名词很多,然而无论概念如何包装,落地的底层逻辑是不变的,分布式事务就是一个钉子户,任...

    寒树Office与RPA
  • 一篇文章带你了解Go语言基础之切片补充

    上篇文章中我们学习了Go语言基础中的变量,一篇文章带你了解Go语言基础之变量,这篇文章我们继续介绍Go语言基础知识,今天跟大家分享的是基础数据类型之切片...

    Go进阶者
  • 关于 etcd 的一些谣言

    这是一个被广为流传的误解,众所周知 etcd 使用 Raft 协议来解决数据一致性问题。一个 Raft Group 只能有一个 Leader 存在,如果一旦发生...

    poslua
  • keepalived实现mycat高可用问题排查;道路坎坷,布满荆棘,定让你大吃一惊!

        医院里,一母亲带着小女孩打针。小女孩:“妈妈我不想打针,疼!”妈妈:“宝贝儿听话,这里这么多护士阿姨,咱们找个打针不疼的。”小女孩:“那哪个阿姨打针不疼...

    青石路
  • Golang 语言的内存管理

    使用 len() 获取字符串长度,返回的是字节长度,如果想要获取 unicode 长度,需要使用 utf8 包的方法。

    frank.
  • nacos的一致性协议distro介绍

    它可作为服务的注册中心,也可用于配置的管理。作为注册中心强调了“更易于构建云原生应用”。注册中心我们可能更加熟悉zookeeper,这里做一个简单的对比

    龟仙老人

扫码关注云+社区

领取腾讯云代金券