前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >CAP学习笔记

CAP学习笔记

作者头像
良辰美景TT
发布2018-09-11 14:24:06
5120
发布2018-09-11 14:24:06
举报
文章被收录于专栏:java、Spring、技术分享

  定义:在一个分布式系统(指互相连接并共享数据的节点的集合)中,当涉及读写操作时,只能保证一致性(Consistence)、可用性(Availability)、分区容错性(Partition Tolerance)三者中的两个,另外一个必须被牺牲。CAP关注的是分布式数据读写

  • 一致性(Consistence):对某个指定的客户端来说,读操作保证能够返回最新的写操作结果。
  • 可用性(Availability): 非故障的节点在合理的时间内返回合理的响应(不是错误和超时的响应)。
  • 分区容错性(Partition Tolerance:当出现网络分区后,系统能够继续“履行职责”。

  虽然 CAP 理论定义是三个要素中只能取两个,但放到分布式环境下来思考,我们会发现必须选择 P(分区容忍)要素,因为网络本身无法做到 100% 可靠,有可能出故障,所以分区是一个必然的现象。如果我们选择了 CA 而放弃了 P,那么当发生分区现象时,为了保证 C,系统需要禁止写入,当有写入请求时,系统返回 error(例如,当前系统不允许写入),这又和 A 冲突了,因为 A 要求返回 no error 和 no timeout。因此,分布式系统理论上不可能选择 CA 架构,只能选择 CP 或者 AP 架构

CAP关键细节点
  • CAP关注的粒度是数据,而不是系统或者节点,所以在系统设计的时候应该将关注点放到数据上,具体数据具体分析。
  • CAP是忽略网络延时的,意味着CAP 理论中的 C 在实践中是不可能完美实现的。在需要强一致性的业务场景中,只能单点写入,其它节点备份。(这里只争对数据,系统还是可以设计成分布式的)
  • 正常运行的情况下,不存在CP或者AP的选择,可以同时满足CA。
  • CAP 理论的“牺牲”只是说在分区过程中我们无法保证 C 或者 A,但并不意味着什么都不做。因为在系统整个运行周期中,大部分时间都是正常的,发生分区现象的时间并不长。分区期间放弃 C 或者 A,并不意味着永远放弃 C 和 A,我们可以在分区期间进行一些操作,从而让分区故障解决后,系统能够重新达到 CA 的状态。
本文参与 腾讯云自媒体同步曝光计划,分享自作者个人站点/博客。
原始发表:2018.08.28 ,如有侵权请联系 cloudcommunity@tencent.com 删除

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

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

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

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • CAP关键细节点
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档