查看原文
其他

深入理解CAP理论和适用场景

大数据技术与架构点击右侧关注,大数据开发领域最强公众号!

暴走大数据点击右侧关注,暴走大数据!
本文出自:https://blog.csdn.net/new_com/article/details/105459177
概述
在分布式系统中,围绕着CAP理论,主要关注点就是复制,一致性,容错性。

复制
为了保证系统的高可用和高可靠性,通过复制的方式,让数据在系统中存储多个副本。以服务实例多副本为例,当一个服务发生异常时,客户端就直接调用其他正常的副本。如下:


 服务A有两个副本,分别为副本1和副本2。当客户端调用服务A时,如果服务A发生异常无法调用,此时,客户端调用副本1或者副本2,这样就保证了系统的高可用。

可以就这么认为,每个服务实例发生异常是无法避免的。例如,因为内存错误,第三方中间件挂掉了,甚至服务器停电等原因造成服务器宕机。或者,因为消息丢失,消息乱序,或者网络包数据错误造成网络异常等等。

一致性
在数据的复制中,由于存在多个数据副本,就会存在主数据与副本数据一致性的问题。在同一份数据的副本中,一般有一个副本为主副本,其他的备副本。在数据的复制过程中,复制的方式分为两种分别如下:

  • 强同步复制,数据的写操作需要同步到主副本和所有的备副本,并且全部写入成功后,才返回成功状态。这样,当系统出现异常时,切换到其他任何一个备份副本时,数据是一致的。但是,强同步复制性能不好,而且可用性比较差。如果,在复制过程中,如果某个备份节点出现故障,这时,会阻塞数据的正常写服务。

  • 异步复制,当数据写入操作成功后,当数据成功复制到主副本时,甚至还没复制时,写操作就返回成功状态。这样,异步复制的性别比较好,但是,当主备出现故障时可能出现数据丢失。


容错性

分布式系统中,集群的规模越大发生错误的概率就也大。一般,分布式系统发生异常时,都能够自动容错,保证系统的高可用。

CAP理论

CAP理论是Eric Brewer教授提出的,分别是一致性(Consistency),可用性(Availability),分区容错性(Tolerance of network Partition),三者不能同时满足。CAP三者可以按照如下的方式来理解:

  • 一致性:数据复制的时候,按照强一致性的方式进行数据复制。保证了在读操作总是能够读取到之前写入的数据,无论从那个主数据或者副本数据。

  • 可用性:数据写入成功后,正在进行数据复制时,任何一个副本节点发生异常也不会影响此次写入操作。可以理解为,此时数据的复制采用的是弱一致性,数据的读写操作在单台机器发生故障的情况下仍然可以正常执行。

  • 分区容错性:在服务实例发生异常时,分布式系统仍然能够满足一致性和可用性。

在分布式系统中,是必须要求系统能够自动容错的,所以,必须满足分区容错性。因此,一致性和可用性就需要根据系统需求二选一了。

CAP使用场景
AP模式

  • eureka服务注册与发现中心集群,在集群中,新增一个eureka实例时,集群中的实例是相互复制其注册的服务实例数据。示例如下:


如图,在服务B向Eureka2注册成功后,此时,Eureka2还没向Eureka3复制成功就挂掉了,此时,在Eureka的服务注册与发现中心集群中造成了数据不一致。当服务A通过服务注册于发现中心集群通过Eureka3来拿服务B的地址时,就无法拿到。

  • mysql数据集群与redis集群,由于mysql和redis的数据复制都是采用的异步复制,所以mysql数据集群与redis集群都属于AP类型,在集群中获取数据时,会存在数据不一致的情况。

CP模式

  • zookeeper服务注册与发现中心集,在集群中,包含一个Leader节点,其余全部为Follower 节点。Leader节点负责读和写操作,Follower 节点只负责读操作。当客户端向集群发出写请求时,写请求会转发到Leader节点,Leader写操作完成后,采用广播的形式,向其余Follower 节点复制数据,Follower节点也写成功,返回给客户端成功。流程如图:


如图,在服务A向zookeeper集群注册时,写请求会被转发到Leader节点(zookeeper1),此时,Leader节点写入成功后,会通知 zookeeper2和zookeeper3节点进行复制,并且复制成功了才会向服务A返回注册成功的状态。此后,服务B通过集合获取服务A的地址,无论从哪个节点都能获取服务A的服务地址。

  • 数据库两阶段提交,第一阶段,事务协调器要求每个涉及到事务的数据库预提交(precommit)此操作,并反映是否可以提交。第二阶段,事务协调器要求每个数据库提交数据。如果有任何一个数据库否决此次提交,那么所有数据库操作的数据都会回滚。

  • Kafka集群(ack=all的配置时),Kafka消息集群中,生产者生成消息时,采用ack=all的配置时,消息成功写入分区,以及其所有分区副本后才算写入成功。此时,消费者从集群中获取的数据都是一致的。


欢迎点赞+收藏+转发朋友圈素质三连


文章不错?点个【在看】吧! 👇

: . Video Mini Program Like ,轻点两下取消赞 Wow ,轻点两下取消在看

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存