架构师训练营第六周 - 作业

发布于: 3 小时前
架构师训练营第六周 - 作业

简述CAP原理

概念

CAP原理是指对一个分布式系统,不可能同时满足以下三点:

  • 一致性(Consistency)—— 所有节点访问同一份最新的数据副本

  • 可用性(Availability)—— 每次请求都能获取到响应,但不保证获取的是最新的数据

  • 分区耐受性(Partition tolerance)—— 节点间网络通信发生了丢失消息或消息延迟(导致系统各节点不能在时限内达成一致的看法)造成分区,系统仍然可以使用

解释

想象在系统发生分区时,有两个分别处于分区两侧的节点。如果允许其中一个节点更新状态会导致数据不一致,即丧失了 C 性质。如果为了保证数据的一致性,将分区一侧的节点设置为不可用,那么又丧失了 A 性质。除非两个节点能够恢复互相通信,才能同时呈现出 CA。通常架构师无法选择是否要 P(因为在实践当中网络故障或通信延迟总会发生),所以在发生分区时只能在 CA 之间作出选择。

传统的关系数据库系统通常以提供 ACID 特性为主导思想,但是在互联网应用的高并发和大数据量场景下,单机处理的上限已无法满足要求,多服务节点的分布式系统成为唯一可行的方案,这时就要在CAP三者之间进行取舍。

但CAP理论并非严格的“三选二”,非黑即白:

  • 首先,分区很少发生,在系统不存在分区的情况下,没理由牺牲 CA

  • 其次, CA 之间的取舍可以在系统内以不同的粒度作出,每次取舍的决策也可能因为牵涉的数据或用户不同而有所不同(不必僵化地要求对整个系统只存在一种恒定不变的取舍方式)

  • 可用性可分为不同的程度,而不仅仅是 0 和 1;一致性也可以分不同的级别;甚至连分区也可能有不同的含义(例如系统内部的不同部分对于是否存在分区可以有不同的认知)

近年涌现的各种 NoSQL 系统,就是在不同程度上对可用性、一致性进行取舍的方案。这些系统放弃了传统数据库的 ACID,而采用 BASE:

  • 基本可用(Basicallly Available)—— 响应时间加长或者部分功能损失

  • 软状态(Soft state)—— 系统中的数据存在中间状态,数据副本间同步存在延迟

  • 最终一致性(Eventually Consistent)—— 经过一段时间后数据最终能达到一致,但不能实时保证系统数据的强一致性

讨论

一致性的作用范围

对一致性作用范围的划定,可以影响 CAP 的整体效果。例如在一个主分区内内保证一致和可用,但在分区外服务可能不可用。分区期间,独立且能自我保证一致性的节点子集可以继续操作。

放弃严格一致性意味着什么

选择可用性牺牲一致性,意味着在分区结束后最终需要恢复到一致,以满足业务上的不变性约束。需要考虑以下三个点:

  • 检测到分区的发生(注意分区可能并非全体节点的一致见解,通信延迟的时限也需要由设计者根据需求而定)

  • 明确进入分区模式后,限制某些操作(例如可能违反业务不变性约束的操作)

  • 通信恢复后进行分区恢复,达到最终一致的状态,以及补偿在系统分区过程期间可能产生的错误。(例如超卖,视乎具体业务而定)

https://www.infoq.com/articles/cap-twelve-years-later-how-the-rules-have-changed/

恢复时解决数据一致性冲突的技术手段

  • 时间戳,最后写入胜出

  • 节点投票

  • 客户端解决

业务设计与CAP

例如电商系统的下单操作,接收到用户的下单请求时,先记录下订单信息,并返回“订单处理中”状态,而不是直接在下单时马上执行扣减库存、扣费等具有外部化特征的事务。系统以用户不易察觉的方式降低了可用性,用户只知道自己下了指令,系统稍后会执行。

依靠审计和补偿,例如透支后收取补偿费用。

总结

在网络正常的时候,分布式系统可以同时保证一致性和可用性。但网络故障总有可能发生(高可靠的网络会帮助减少故障发生的概率,但无法彻底避免),这时无法同时保证一致性和可用性,需要在C和*A*两者之间进行取舍。某些故障组合甚至可能导致同时丢失 CA

CAP 三个性质是一个度的问题,设计者可以在不同程度的可用性与一致性间作出不同的组合。

参考

Eric Brewer, “CAP Twelve Years Later: How the Rules Have Changed”

Martin Kleppmann, “Designing Data-Intensive Applictaions”

用户头像

Lost Horizon

关注

给写代码的人写代码 2017.10.17 加入

Clojure

评论

发布
暂无评论
架构师训练营第六周 - 作业