一、分布式系统的需求与困境
是不是会有人(产品?老板?)对你所负责的分布式系统提出以下三点要求:
- 既要:系统高可用
- 又要:数据一致且实时可见
- 还要:系统具有集群容错能力
这些要求看似简单,当你仔细思考时就会发现很让人头疼了、无法全部实现;如果你还不理解,我们举个例子,如防疫时期的静态化管理:
- 人停工企业停产(失去可用性)
- 全城全面核酸,统一采用核酸码平台,实时统筹管理数据(保证数据的一致性)
- 人被限制在小区内活动、交换物资,小区间封闭(分区容错)
经历过的人应该了解,当我们要满足2、3时,就必须牺牲1;或许你也尝试思考过如何破局但又困惑无解;不过无需自责,不仅仅是你会觉得困难,其他人也一样,因为它违背了CAP定理。
二、CAP 理论引导脱离实现困境
在理论计算机科学中,CAP定理(CAP theorem),又被称作布鲁尔定理(Brewer's theorem),定理讨论了在两个互相矛盾的请求,到达彼此连接不通的两个不同的分布式节点 的时候的处理方案。
CAP定理 指出对于一个分布式计算系统来说,不可能同时满足一致性(Consistency)、可用性(Availability)、分区容错性(Partition tolerance)。
有这么一种说法:以实际效果而言,系统若不能在时限内完成同步,达到数据一致性;就意味着发生了分区的情况,必须就当前操作在一致性和可用性之间做出选择。
三、一致性(Consistency)
一致性是说,所有节点访问同一份最新的数据副本;即一致性保证了无论将数据写入哪一个节点,其它的节点都能实时同步到这个新数据,随后无论从哪个节点读到的都是最新的数据。如下图所示:
如果节点之间数据同步有异常,那就必须先解决掉同步的问题,挂起所有的请求,等待数据同步完成后才响应,那么会出现以下几种情况:
- 在等待很久后才得到了正确结果
- 写入数据异常
- 读取数据异常
四、可用性(Availability)
可用性是说,如果有节点异常了,只要向其它无异常的节点发送请求,总能正常的收到响应数据,但数据可以不是最新的,如下图所示:
五、分区容错性(Partition tolerance)
先说分区是什么,在分布式系统中,不同的节点分布在不同的子网络中,若因一些网络故障,出现了子网络之间不通的情况,但每个子网络内是正常的;这样一个完整的系统就被切分成了若干个相对孤立的区域。这就是分区。
对于分布式系统来说,在遇到任何网络故障而导致分区时,仍然能够对外提供具有一致性或可用性的服务。也就是说会分区之间即使无法同步数据,也能对外提供服务。
六、反推CAP定理
借用一个示例以反证法的方式来梳理CAP定理,如整个系统由服务节点A、B组成,节点之间通过网络通信,当节点 A 进行更新数据操作的时候,需要同时更新节点 B 的数据。
假设同时满足CAP这三个特性,由于具有分区容错,则可以切断 A、B两个节点间的通信
- 当A、B通信断开后,因无法通信,一致性就无法满足,但A、B都还能对外提供服务,满足可用性
- 若要强行满足一致性,就必须让A、B不再提供服务,等A、B的网络通信故障修复后才继续提供服务,这就放弃了可用性。
所以总结来看:
- 若要一致性:则必须保障节点间数据同步,同步执行期间数据锁定、请求挂起,会导致期间的请求失败或超时,破坏了可用性
- 若要可用性:则不允许节点间数据同步时被数据锁定、请求挂起,这又破坏了一致性。
七、一致性的取舍
总结来说,在分布式系统中,首先必须要满足P,因为是多节点,一定要会遇到并要容忍分区错误,而C或A需要根据具体场景进行取舍。
组合 | 结果 |
CP | 满足一致性和分区容错性,也就是说,要放弃可用性。当系统被分区,为了保证原子性,必须放弃可用性,让请求挂起。 |
AP | 满足可用性和分区容错性,当出现分区,同时为了保证可用性,即使数据尚未完成同步,也必须让节点继续对外服务,这样导致数据不一致 |
当系统既要提供可用性,而又不能放弃一致性的情况下,通常会因场景差异而调整对一致性的要求,而差异点体现在时效性上如:
- 强一致性
任意时刻,任意节点都读取到最新的数据 - 弱一致性
可能无法在明确限定的时间内读到最新的数据 - 最终一致性
是一种特殊的弱一致性,系统保证在过了某个时间窗口后,数据将达到完全一致的状态,而之后的读取一定是新数据。
分布式业务系统实现中,多数场景中会选择牺牲一致性来换取可用性。而所谓的牺牲其实是不追求强一致,而选择弱一致或最终一致。
最后说一句(请关注,莫错过)
如果这篇文章对您有帮助,或者有所启发的话,欢迎关注公众号【 架构染色 】进行交流和学习。您的支持是我坚持写作最大的动力。