从ACID到CAP到BASE

百般思念 提交于 2019-12-20 20:30:57

学习思路

  1. CAP理论
  2. BASE理论
  3. 应用场景

ACID相关请看《ACID-本地事务-分布式事务

一、CAP理论

  1. C(一致性):分布式系统中所有备份节点的数据任何时间都保持一致(从任何一个节点取到的数据都一样)
  2. A(可用性):系统在任何情况下(发生故障)都仍然可以对外提供服务(高可用)
  3. P(分区容错性):如果数据产生了不一致的情况或者始终高可用,那么肯定存在分区(我们所有的线上服务都是集群部署)

一致性和可用性是我们设计的目标,但就目前的系统设计来说分区容错性又是不可避免的,下面我们单独分析CA、CP、AP

  1. CA:放弃分区容错意味着是单机服务,宕机概率大,一旦宕机后整个服务不可用(线上避免)
  2. CP:放弃可用性,保证数据一致性和分区容错,意味着我们在做数据同步(一致性)的时候系统可能一直处于等待,直至所有数据一致(比如我们之前说的分布式事务2PC、3PC)
  3. AP:放弃一致性,意味着数据在短时间内可能是不一致的,但一直能对外服务

就现阶段的微服务架构设计中CA很明显不符合,因此我们将在CP和AP中根据不同场景分别设计

我们比较熟悉的zookeeper是CP系统,eureka是AP系统

这里联想到为什么eureka比zookeeper更适合做注册中心:eureka是去中心化设计,每个节点都可以单独对外读写,数据同步可能出现短暂时间差,但zk是leader负责写并同步其它节点,如果leader宕机,将进行选举操作而不能对外提供服务(这里只是举例这一点)

二、BASE理论

BASE Basically Available(基本可用)Soft state(软状态) Eventually consistent (最终一致性) 三个短语的缩写。是对 CAP AP 的一个扩展

  1. BA 基本可用:分布式系统在出现故障时,允许损失部分可用功能,保证核心功能可用。
  2. S 软状态:允许系统中存在中间状态,这个状态不影响系统可用性,这里指的是 CAP 中的不一致。
  3. E 最终一致:最终一致是指经过一段时间后,所有节点数据都将会达到一致。

BASE 解决了 CAP 中理论没有网络延迟,在 BASE 中用软状态和最终一致,保证了延迟后的一致性。

BASE ACID 是相反的,它完全不同于 ACID 的强一致性模型,而是通过牺牲强一致性来获得可用性,并允许数据在一段时间内是不一致的,但最终达到一致状态。

对于大部分的分布式应用而言,只要数据在规定的时间内达到最终一致性即可。我们可以把符合传统的 ACID 叫做刚性事务,把满足 BASE 理论的最终一致性事务叫做柔性事务。

三、应用场景

实际场景中,我们用的比较多的就是注册中心的选取和分布式事务的处理

1、注册中心,我们往往选取一些AP系统加上一些BASE理论,允许短时间的数据不一致,保证高可用

2、分布式事务,强一致性事务往往性能不理想,不能满足高并发场景,从而我们一般选择一些最终一致性的设计方法(TCC、基于MQ做最终一致性等)

总之一味的追求强一致性,并非最佳方案。对于分布式应用来说,刚柔并济是更加合理的设计方案,即在本地服务中采用强一致事务,在跨系统调用中采用最终一致性。实际中要权衡系统的性能与一致性并从中取舍从而设计出更适合自己的业务系统

 

 

公众号主要记录各种源码、面试题、微服务技术栈,帮忙关注一波,非常感谢

标签
易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!