微服务分布式场景看CAP

1、CAP定义:

CAP定义:在一个分布式系统,且这个分布式系统互相连接并共享数据的集合,当涉及到读写时,只能保证一致性(Consistence)、可用性(Availability)、分区容错性(Partition Tolerance)三者中的两个。CAP关注的是对数据的读写操作,而不是分布式系统的所有功能。

2、分布式系统与集群的区别:

分布式系统的定义:指将业务拆分到不同的服务节点上,分布式中的每一个节点,都可以做集群。

集群的定义:将几台服务器集中在一起,实现同一业务。

3、有状态系统与无状态系统:

  • 无状态的服务:客户端的每次请求必须具备自描述信息,通过这些信息识别客户端身份。服务端不保存任何客户端请求者信息。
  • 有状态的服务:有状态服务,即服务端需要记录每次会话的客户端信息,从而识别客户端身份,根据用户身份进行请求的处理,典型的设计如 tomcat 中的 session。

4、一致性Consistence:

对某个指定的客户端来说,读操作保证能够返回最新的写操作结果。

微服务分布式场景看CAP_第1张图片

5、可用性Availability:

没有发生故障的系统节点在合理的时间内返回合理的响应,这个响应不是网络相关错误。而是业务上的正常响应,比如订单已提交或不能重复提交订单都算正常响应。

6、分区容错性Partition Tolerance:

什么是分区容错:如果网络故障时,系统能够继续执行正常请求,那就是分区容忍的
(大白话就是节点与节点之间网络无法连接,比如订单节点无法连接商服节点时,两边还可以继续提供服务)

如下出现网络分区,节点间无法连接。

微服务分布式场景看CAP_第2张图片

上图中已经明确解释了微服务分布式场景下,允许其中部分节点网络故障,业务还能继续处理,这就是所谓的分区容错性(或分区容忍性)。由于网络故障是避免不了,我们必须要解决网络故障带来的问题,所以必须要保障网络故障时对业务运转无影响,即CAP中需要保障P(网络异常情况时,分布式系统也能正常处理业务)。

7、CAP场景推导:

如上在保障P的前提下,来推到C和A能否同时满足,在我们分布式系统中:

  • 满足C,无法满足A:当网络分区时,一般情况都会直接抛出异常,不会更新数据,这样虽然保障了各域数据的一致性, 但对client来说,系统的可用性降低。
  • 满足A,无法满足C:当网络分区时,如果不抛异常,要保障系统可用性,对client反馈就必须是合理的,这样就造成实际上系统调用下游失败,但还是正常反馈合理结果,则各域数据会出现不一致,这样虽然保障了系统可用性,但无法保障各域数据的一致性。

8、ACID

ACID是数据库管理系统为了保证事务正确性提出来的一个理论,ACID包含四个特征:

原子性( Atomicity )、一致性( Consistency )、隔离性( Isolation )和持续性( Durability )。这四个特性简称为 ACID 特性。

8.1 原子性
原子性是指事务是一个不可分割的工作单位,事务中的操作要么都发生,要么都不发生。

8.2 一致性
数据库总是从一个一致性的状态转移到另一个一致性的状态。一致性确保了即使在执行第三、第四条语句之间时系统崩溃,前面执行的第一、第二条语句也不会生效,因为事务最终没有提交,所有事务中所作的修改也不会保存到数据库中。

8.3 隔离性
一个事务的执行不能其它事务干扰。即一个事务内部的操作及使用的数据对其它并发事务是隔离的,并发执行的各个事务之间不能互相干扰。

持续性
指一个事务一旦提交,它对数据库中的数据的改变就应该是永久性的。接下来的其它操作或故障不应该对其执行结果有任何影响。

9、BASE

BASE指基本可用(Basically Available)、软状态(Soft State)、最终一致(Eventual Consistency),因CAP的一致性就是强一致性,BASE的核心思想是即使无法做到强一致性,可以采用适合的方式达到最终一致性。

9.1 基本可用(Basically Available)

基本可用是指分布式系统在出现不可预知故障的时候,允许损失部分可用性,以保障核心可用。

比如:常说的系统降级,通过开关把一些不太重要的功能降级掉。或者把对客的部分不重要但浪费性能的功能关掉。

9.2 软状态(Soft State)

软状态指允许系统中的数据存在中间状态,并认为该中间状态的存在不会影响系统的整体可用性,即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时

9.3 最终一致(Eventual Consistency)

系统中所有的数据副本,在经过一段时间的同步后,最终能够达到一个一致的状态,不要求实时。

你可能感兴趣的:(架构师,微服务,分布式,架构)