Day07_01_分布式教程之分布式系统详解

最新推荐文章于 2024-03-12 11:38:45 发布

一一哥Sun

最新推荐文章于 2024-03-12 11:38:45 发布

阅读量2k

点赞数 1

分类专栏： Java系列文章标签：分布式一致性

本文为博主原创文章，如需转载，请联系作者并注明出处。如有抄袭等行为，则视为侵权！

本文链接：https://blog.csdn.net/syc000666/article/details/90795011

版权

Java系列专栏收录该内容

147 篇文章 21 订阅

订阅专栏

分布式系统详解

一. 大型网站的特点

用户多,分布广泛;
大流量,高并发;
海量数据,服务高可用;
安全环境恶劣,易受网络攻击;
功能多,变更快,频繁发布;
从小到大,渐进发展;
以用户为中心;
免费服务,付费体验.

二. 大型网站的架构目标

高性能:提供快速的访问体验;
高可用:网站服务一直可以正常访问;
可伸缩:通过硬件的增加/减少来提高/降低处理能力;
安全性:提供网站安全访问和数据加密,实现安全存储等策略;
扩展性:方便的通过新增/移除方式来增加/减少新的功能/模块;
敏捷性:随需应变,快速响应.

三、大型网站的架构模式

分层:一般可分为应用层,服务层,数据层,管理层,分析层等;
分割:一般按照业务/模块/功能特点进行划分,比如应用层分为首页,用户中心;
分布式:将应用分开部署(比如多台物理机),通过远程调用协同工作;
集群:一个应用/模块/功能部署多份(如多台物理机),通过负载均衡共同提供对外访问;
缓存:将数据放在距离应用或用户最近的位置,加快访问速度;
异步:将同步的操作异步化.客户端发出请求,不用等待服务端的响应,而是等服务端处理完毕后,使用通知或轮询的方式告知请求方.一般是指 请求——响应——通知 模式;
冗余:增加副本,提高可用性,安全性,性能;
安全:对已知问题有有效的解决方案,对未知/潜在问题建立发现和防御机制;
自动化:将重复的,不需要人工参与的事情,通过工具的方式,使用机器来完成;
敏捷性:积极接受需求变更,快速响应业务发展需求.

四. 分布式系统概述

要想实现以上所说的大型网站的架构目标,在目前的Java开发领域中,基本上进行项目架构设计的时候都要考虑采用分布式系统.

1. 如何理解分布式系统?

上述这张图,在图中有三个机器节点,每台机器各自部署一个应用程序,然后我们将这三台机器通过网络通信将其连接起来,构成一个完整的系统来为用户提供服务.对用户来说这个系统的架构是透明的,他感觉不到我们这个系统是一个什么样的架构,那么我们就可以把这种系统称作为一个分布式系统.

2. 什么是分布式系统?

分布式系统是由一组通过网络进行通信,为了完成共同的任务而协调工作的计算机节点组成的系统.简单来说就是一群独立的计算机集合在网络通信的支撑下,共同对外提供服务,但是对于系统的用户来说,就像是一台计算机在提供服务一样.分布式系统的出现是为了用廉价(相对于昂贵的大型机)的、普通的机器完成单个计算机无法完成的计算、存储任务,其目的是利用更多的机器,处理更多的数据.分布式系统主要包含了:分布式网络,分布式计算,分布式存储,分布式应用.

3. 分布式系统组成

分布式系统分为分布式计算(computation),分布式存储(storage),分布式网络,分布式应用.其中计算与存储是相辅相成的,计算需要数据,要么来自实时数据(流数据),要么来自存储的数据;而计算的结果也是需要存储的.在操作系统中,对计算与存储有非常详尽的讨论,分布式系统只不过将这些理论推广到多个节点罢了.

4. 搭建分布式系统的必要性与否

分布式系统涉及到很多的技术、理论与协议,我们在自己的开发中是否有必要每个项目都采用分布式系统?

首先需要明确的是,只有当单个节点的处理能力无法满足日益增长的计算、存储任务的,且硬件的提升(加内存、加磁盘、使用更好的CPU)高昂到得不偿失,应用程序也不能进一步优化的时候,我们才需要考虑分布式系统.因为,分布式系统要解决的问题本身就是和单机系统一样的,而由于分布式系统多节点、通过网络通信的拓扑结构,会引入很多单机系统没有的问题,为了解决这些问题又会引入更多的技术、机制、协议,可能会带来更多的问题...

5. 构建分布式系统的指导思想--Partition与Replication

分布式系统是根据什么指导思想将共同任务分发到不同的计算机节点呢?

5.1 Partition分片

分而治之,即分片(Partition)的思想.对于计算任务而言,就是将计算任务进行切换,每个节点计算一些,最终汇总,这也是MapReduce(映射规约,用于大规模数据集(大于1TB)的并行运算)的思想;对于存储任务而言,可以在每个节点里存储一部分数据.当数据规模变大的时候,Partition是唯一的选择,同时这也会带来一些好处:

1️⃣.提升性能和并发,操作被分发到不同的分片,相互独立;

2️⃣.提升系统的可用性,即使部分分片不能用,其他分片也不会受到影响.

5.2 Replication复制

理想的情况下,有分片就行了,但事实的情况却不大理想.原因在于,分布式系统中有大量的节点,且通过网络通信.单个节点的故障(进程crash、断电、磁盘损坏)是个小概率事件,但整个系统的故障率会随节点的增加而指数级增加,而且网络通信也可能会出现断网、高延迟的情况.在这种一定会出现的“异常”情况下,分布式系统还是需要继续稳定的对外提供服务,即分布式系统需要较强的容错性.最简单的办法,就是冗余或者复制集(Replication),即多个节点负责同一个任务,最为常见的就是在分布式存储中,多个节点负责存储同一份数据,以此增强可用性与可靠性.同时,Replication也会带来性能的提升,比如数据的locality(局部性)可以减少用户的等待时间.

Partition与Replication协作示意图

该图说明了Partition与Replication是如何协作的.

Partition和Replication是解决分布式系统问题的一记组合拳,很多具体的问题都可以用这个思路去解决,但这并不是银弹!因为往往是为了解决一个问题,会引入更多的问题.比如为了保证可用性与可靠性,引用了冗余(复制集),有了冗余,各个副本间的一致性问题就变得很头疼.一致性在系统的角度和用户的角度又有不同的等级划分,如果要保证强一致性,那么会影响可用性与性能,在一些应用(比如电商、搜索)中是难以接受的.如果要保证最终一致性,那么就需要处理数据冲突的情况.CAP、FLP这些理论告诉我们,在分布式系统中,没有最佳的选择,都需要进行权衡,做出最合适的选择.

6. 分布式系统可能存在的问题

分布式系统需要大量机器协作,所以面临诸多的挑战.

1️⃣. 异构的机器与网络

分布式系统中的机器,配置不一样,每台机器上面运行的服务也可能由不同的开发语言、架构实现,因此处理能力也不一样;节点间通过网络连接,而不同网络运营商提供的网络带宽、延时、丢包率又不一样,怎么保证大家齐头并进,共同完成目标,这是个不小的挑战.

2️⃣. 节点故障

节点故障指的是组成分布式系统的服务器节点出现的宕机或"僵死"现象,通常根据经验来说,每个节点都有可能出现故障,并且每天都在发生.虽然单个节点的故障概率较低,但节点数目达到一定规模,出故障的概率就变高了.分布式系统需要保证故障发生的时候,系统仍然是可用的,这就需要监控节点的状态,在节点故障的情况下将该节点负责的计算、存储任务转移到其他节点.

3️⃣. 不可靠的网络,网络分区

节点间通过网络通信,而网络是不可靠的,可能的网络问题包括:网络分割、延时、丢包、乱序等.
分布式系统需要在各个节点之间进行网络通信,因此每次网络通信都会伴随着网络不可用的风险,网络光纤、路由器或是DNS等硬件设备或是系统不可用都会导致最终分布式系统无法顺利完成一次网络通信.另外,即使分布式系统各个节点之间的网络通信能够正常进行,其延时也会大于单机操作.通常我们认为现代计算机体系结构中,单机内存访问的延时在纳秒数量级(通常是10ns),而正常的一次网络通信的延迟在0.1~1ms左右(相当于内存访问延时的105倍),如此巨大的延时差别,也会影响到消息的收发过程,因此消息丢失和消息延迟变得非常普遍.

4️⃣. 网络分区

当网络由于发生异常情况,导致分布式系统中部分节点之间的网络延时不断增大,最终导致组成分布式系统的所有节点中,只有部分节点之间能够正常通信,而另一些节点则不能----我们将这个现象称为网络分区。当网络分区出现时，分布式系统会出现局部小集群，在极端情况下，这些局部小集群会独立完成原本需要整个分布式系统才能完成的功能，包括对数据的事物处理，这就对分布式一致性提出了非常大的挑战.

5️⃣. 分布式系统中网络的三态

相比单机过程调用,网络通信最让人头疼的问题是可能会超时:节点A向节点B发出请求,在约定的时间内没有收到节点B的响应,那么B是否处理了请求,这个是不确定的,这个不确定会带来诸多问题,最简单的,是否要重试请求,节点B会不会多次处理同一个请求.

通过上面几点,我们已经了解到在分布式环境下,网络可能会出现各式各样的问题,因此分布式系统的每一次请求与响应,存在特有的三态概念: 即成功、失败、超时.在传统的单机系统中,应用程序在调用一个函数之后,能够得到一个非常明确的响应: 成功或失败. 而在分布式系统中,由于网络是不可靠的,虽然在绝大部分情况下,网络通信也能够接受到成功或失败的响应,当时当网络出现异常的情况下,就可能会出现超时现象,通常有以下两种情况:
(1).由于网络原因,该请求并没有被成功地发送到接收方,而是在发送过程中就发生了消息丢失现象;
(2).该请求成功地被接收方接收后,进行了处理，但是在将响应反馈给发送方的过程,发生了消息丢失现象,当出现这样的超时现象时,网络通信的发起方是无法确定当前请求是否被成功处理的.

总而言之,分布式的挑战来自不确定性,不确定计算机什么时候crash、断电,不确定磁盘什么时候损坏,不确定每次网络通信要延迟多久,也不确定通信对端是否处理了发送的消息.而分布式的规模放大了这个不确定性.不确定性是令人讨厌的,所以有诸多的分布式理论、协议来保证在这种不确定性的情况下,系统还能继续正常工作.

而且,很多在实际系统中出现的问题,来源于设计时的盲目乐观,觉得这里、那里应该不会出问题.
在Fallacies_of_distributed_computing里面介绍了分布式系统新手可能存在的错误假设:

The network is reliable.

Latency is zero.

Bandwidth is infinite.

The network is secure.

Topology doesn't change.

There is one administrator.

Transport cost is zero.

The network is homogeneous.

处理这些异常的最佳原则是:在设计、推导、验证分布式系统的协议、流程时,最重要的工作之一就是思考在执行流程的每个步骤时一旦发生各种异常的情况下系统的处理方式及造成的影响.

7. 分布式系统的特性

1️⃣. 分布性
分布式系统中的多台计算机之间在空间位置上可以随意分布,系统中的多台计算机之间没有主、从之分,即没有控制整个系统的主机,也没有受控的从机.

2️⃣. 透明性
系统资源被所有计算机共享.每台计算机的用户不仅可以使用本机的资源,还可以使用本分布式系统中其他计算机的资源(包括CPU、文件、打印机等).

3️⃣. 同一性
系统中的若干台计算机可以互相协作来完成一个共同的任务,或者说一个程序可以分布在几台计算机上并行地运行.

4️⃣. 通信性
系统中任意两台计算机都可以通过通信来交换信息.

8. 分布式系统的衡量标准

1️⃣. 内聚性:
是指每一个分布节点高度自治,有本地的一个子系统;

2️⃣. 透明性:
使用分布式系统的用户并不关心系统是怎么实现的,也不关心读到的数据来自哪个节点,对用户而言,分布式系统的最高境界是用户根本感知不到这是一个分布式系统,在《Distributed Systems Principles and Paradigms》一书中,作者是这么说的:

A distributed system is a collection of independent computers that appears to its users as a single coherent system.

3️⃣. 可扩展性:
分布式系统的根本目标就是为了处理单个计算机无法处理的任务,当任务增加的时候,分布式系统的处理能力需要随之增加.简单来说,要比较方便的通过增加机器数量来应对数据量的增长;同时,当任务规模缩减的时候,可以撤掉一些多余的机器,达到动态伸缩的效果.

4️⃣. 可用性与可靠性:
一般来说,分布式系统是需要长时间甚至7*24小时不间断提供服务的.可用性是指系统在各种情况下对外提供服务的能力,简单来说,可以通过不可用时间与正常服务时间的比值来衡量;而可靠性是指计算结果正确、存储的数据不丢失.

5️⃣. 高性能:
不管是单机还是分布式系统,大家都非常关注性能.不同的系统对性能的衡量指标是不同的,最常见的:高并发,单位时间内处理的任务越多越好;低延迟:每个任务的平均时间越少越好.这个其实跟操作系统CPU的调度策略很像.

6️⃣. 一致性:
分布式系统为了提高可用性可靠性,一般会引入冗余(复制集).那么如何保证这些节点上的状态是一致的,这就是分布式系统不得不面对的一致性问题.一致性有很多等级,一致性越强,对用户越友好,但会制约系统的可用性;一致性等级越低,用户就需要兼容数据不一致的情况,但系统的可用性、并发性很高很多.

9. 对分布式系统中一个请求的剖析

假设此时有一个对外提供服务的大型分布式系统,用户连接到该系统,做了一些操作,产生了一些需要存储的数据,那么在这个过程中,会涉及哪些组件、理论与协议呢?

假设用户发起了某个请求:

1️⃣.用户在PC或者APP上,通过HTTP、TCP协议连接到了该系统;

2️⃣.利用负载均衡(load balance)选择某个节点上的服务--在分布式系统中,为了高并发、高可用,一般都是有多个节点提供相同的服务,那么具体选择哪个节点来提供服务,这个就涉及到了负载均衡(load balance).

3️⃣.当用户通过负载均衡找到了一个节点,接下来开始真正处理用户的请求,这个请求有可能简单,也有可能很复杂.

4️⃣.数据缓存:如果上面的请求比较简单,比如就是进行读取数据,此时这个数据可能是有缓存的,我们就需要用到分布式缓存(redis);如果缓存没有命中,然后需要去数据库拉取数据.

5️⃣.利用RPC进行远程过程调用:如果上面的请求比较复杂,可能会调用到系统中其他的服务.此时假设服务A需要调用服务B,首先两个节点需要通信,网络通信都是建立在TCP/IP协议的基础上.如果我们每个应用都手写Socket那会是非常冗杂、低效,因此需要应用层的封装,所以有了HTTP、FTP等各种应用层协议.但当系统愈加复杂,提供大量的Http接口也是一件困难的事情.因此,有了更进一步的抽象,那就是RPC(remote produce call).远程过程调用就跟本地过程调用一样方便,屏蔽了网络通信等诸多细节,增加新的接口也更加方便.

6️⃣.利用分布式事务保证一致性:一个请求可能包含诸多操作,即在服务A上做一些操作,然后在服务B上做另一些操作.比如简化版的网络购物,在订单服务上发货,在账户服务上扣款.这两个操作需要保证原子性,要么都成功,要么都不操作,这就涉及到分布式事务的问题,分布式事务会从应用层面保证一致性.

7️⃣.服务的注册与发现机制:上面说道一个请求包含多个操作,其实就是涉及到多个服务,分布式系统中有大量的服务,每个服务又是多个节点组成.那么一个服务是怎么找到另一个服务(某个节点)的呢?通信是需要地址的,怎么获取这个地址,最简单的办法就是配置文件写死,或者写入到数据库,但这些方法在节点数据巨大、节点动态增删的时候都不大方便,这个时候就需要服务注册与发现:提供服务的节点向一个协调中心注册自己的地址,使用服务的节点去协调中心拉取地址.

从上可以看见,协调中心提供了中心化的服务:以一组节点提供类似单点的服务,使用非常广泛,比如命令服务、分布式锁.协调中心最出名的就是chubby,zookeeper.

8️⃣.利用消息队列进行异步通信:在用户请求的过程中,这个请求操作可能会产生一些数据、日志等信息,其他一些系统可能会对这些消息感兴趣,比如个性化推荐、监控等.这里就抽象出了两个概念,消息的生产者与消费者.那么生产者怎么讲消息发送给消费者呢,RPC并不是一个很好的选择,因为RPC肯定得指定消息发给谁,但实际的情况是生产者并不清楚、也不关心谁会消费这个消息,这个时候消息队列就出马了.简单来说,生产者只用往消息队列里面发就行了,队列会将消息按主题(topic)分发给关注这个主题的消费者.消息队列起到了异步处理、应用解耦的作用.

9️⃣.利用分布式计算平台进行大数据操作:用户操作会产生一些数据,这些数据忠实记录了用户的操作习惯、喜好,是各行各业最宝贵的财富,比如各种推荐、广告投放、自动识别.这就催生了分布式计算平台,比如Hadoop，Storm等,用来处理这些海量的数据.

?.利用分布式存储技术进行数据存储:最后,用户的操作完成之后,用户的数据需要持久化,但数据量很大,大到单个节点无法存储,那么这个时候就需要分布式存储:将数据进行划分放在不同的节点上;同时,为了防止数据的丢失,每一份数据会保存多分.传统的关系型数据库是单点存储,为了在应用层透明的情况下分库分表,会引用额外的代理层,而对于NoSql,一般天然支持分布式.

10. 分布式系统相关技术栈

一个分布式系统中可能会涉及到的技术栈.

负载均衡相关技术

Nginx: 一款工作在应用层的高性能、高并发的web服务器,功能包括负载均衡、反向代理、静态内容缓存、访问控制等;

LVS: 是一个工作在网络层的Linux virtual server,基于集群技术和Linux操作系统实现一个高性能、高可用的服务器;

WebServe相关技术

Java: Tomcat,Apache,Jboss;

Python: gunicorn、uwsgi、twisted、webpy、tornado;

微服务相关技术　

SOA、SpringCloud、Spring boot,django

容器化相关技术

docker, kubernetes

cache相关技术

memcache、redis等

协调中心相关技术

zookeeper、etcd等

zookeeper使用了Paxos协议,Paxos是强一致性的,高可用的去中心化分布式,zookeeper的使用场景非常广泛.

RPC框架相关技术

grpc、dubbo、brpc

dubbo是阿里开源的用Java开发的高性能RPC框架,在阿里系的诸多架构中,都使用了dubbo + SpringBoot

消息队列相关技术

kafka、rabbitMQ、rocketMQ、QSP

消息队列的应用场景:异步处理、应用解耦、流量削峰和消息通讯等.

实时数据平台相关技术

storm、akka

离线数据平台相关技术

hadoop、spark

apark、akka、kafka都是scala语言写的

DBProxy相关技术

cobar等

cobar也是阿里开源的,在阿里系中使用也非常广泛,是关系型数据库的Sharding + Replica 代理.

DB相关技术

mysql、oracle、MongoDB、HBase

搜索相关技术

elasticsearch、solr

日志相关技术

rsyslog、elk、flume

11. 分布式系统与集中式系统对比劣势

和集中式系统相比,分布式系统的性价比更高、处理能力更强、可靠性更高、也有很好的扩展性.但是,分布式在解决了网站的高并发问题的同时也带来了一些其他问题.

1️⃣. 性能和服务能力
分布式的必要条件就是网络,这可能对性能甚至服务能力造成一定的影响;
2️⃣. 故障率
一个集群中的服务器数量越多,服务器宕机的概率也就越大;
3️⃣. 一致性
由于服务在集群中式分布式部署的,但用户的请求只会落到其中一台机器上,所以,一旦处理不好就很容易产生数据一致性问题.

五. 分布式系统的几个理论/概念理解

1. CAP理论

1.1 CAP概念

2000 年,加州大学伯克利分校计算机教授 Eric Brewer 提出了著名的 CAP 理论,任何基于网络的数据共享系统(即分布式系统)最多只能满足数据一致性(Consistency)、可用性(Availability)和网络分区容错(Partition Tolerance)三个特性中的两个.

在大规模的分布式环境下,网络故障是常态,所以网络分区容错是必须保障的,只能在可用性和一致性两者间做出选择,即 CP 模型或者 AP模型,实际的选择需要通过业务场景来权衡.

在分布式系统中,同时满足CAP定律中的一致性 Consistency、可用性 Availability和分区容错性 Partition Tolerance三者是不可能的.在绝大多数的场景,都需要牺牲强一致性来换取系统的高可用性,系统往往只需要保证最终一致性.

1.2 CAP理解

1️⃣. Consistency: 一致性是指数据在多个副本之间能否保持一致的特性.在一致性的需求下,当一个系统在数据一致的状态下执行更新操作后,应该保证系统的数据仍然处于一直的状态.而强一致性就是指在客户端任何时候看到的各节点数据都是一致的(All nodes see the same data at the same time);

对于一个将数据副本分布在不同分布式节点上的系统来说,如果对第一个节点的数据进行了更新操作并且更新成功后,却没有使得第二个节点上的数据得到相应的更新,于是在对第二个节点的数据进行读取操作时,获取的依然是旧数据(或称为脏数据),这就是典型的分布式数据不一致的情况.在分布式系统中,如果能够做到针对一个数据项的更新操作执行成功后,所有的用户都可以读取到其最新的值,那么这样的系统就被认为具有强一致性.

2️⃣. Availability: 可用性是指系统提供的服务必须一直处于可用的状态,对于用户的每一个操作请求总是能够在有限的时间内返回结果.这里的重点是"有限时间内"和"返回结果".而高可用性就是指在任何时候系统都是可以读写的(Reads and writes always succeed);

"有限时间内"是指,对于用户的一个操作请求,系统必须能够在指定的时间内返回对应的处理结果,如果超过了这个时间范围,那么系统就被认为是不可用的.另外,"有限的时间内"是指系统设计之初就设计好的运行指标,通常不同系统之间有很大的不同.无论如何,对于用户请求,系统必须存在一个合理的响应时间,否则用户便会对系统感到失望.
"返回结果"是可用性的另一个非常重要的指标,它要求系统在完成对用户请求的处理后,返回一个正常的响应结果.正常的响应结果通常能够明确地反映出队请求的处理结果,即成功或失败,而不是一个让用户感到困惑的返回结果.

3️⃣. Partition Tolerance: 分区容错性是指在网络故障、某些节点不能通信的时候系统仍能继续工作,继续保证对外提供满足一致性和可用性的服务.(The system continue to operate despite arbitrary message loss or failure of part of the the system).

网络分区是指在分布式系统中,不同的节点分布在不同的子网络(机房或异地网络)中,由于一些特殊的原因导致这些子网络出现网络不连通的状况,但各个子网络的内部网络是正常的,从而导致整个系统的网络环境被切分成了若干个孤立的区域.需要注意的是,组成一个分布式系统的每个节点的加入与退出都可以看作是一个特殊的网络分区.

以实际效果而言,分区相当于对通信的时限要求.系统如果不能在时限内达成数据一致性,就意味着发生了分区的情况,必须就当前操作在C和A之间做出选择.

1.3 CAP的搭配方案对比

说明:对于一个分布式系统而言,分区容错性是一个最基本的要求.因为既然是一个分布式系统,那么分布式系统中的组件必然需要被部署到不同的节点,否则也就无所谓分布式系统了,因此必然出现子网络.而对于分布式系统而言,网络问题又是一个必定会出现的异常情况,因此分区容错性也就成为了一个分布式系统必然需要面对和解决的问题,因此系统架构师往往需要把精力花在如何根据业务特点在 C（一致性）和A（可用性）之间寻求平衡.

2. 数据一致性

1️⃣. 强一致性:
当用户完成更新操作之后,任何多个后续进程或者线程的访问都会返回最新的更新过的值.这种是对用户最友好的,就是用户上一次写什么,下一次就保证能读到什么.根据 CAP 理论,这种实现需要牺牲可用性.

2️⃣. 弱一致性:
系统并不保证后续进程或者线程的访问都会返回最新的更新过的值.系统在数据写入成功之后,不承诺立即可以读到最新写入的值,也不会具体的承诺多久之后可以读到.

3️⃣. 最终一致性:
这是弱一致性的特定形式,系统保证在没有后续更新的前提下,系统最终返回上一次更新操作的值.在没有故障发生的前提下,不一致窗口的时间主要受 通信延迟/系统负载和复制副本 的个数影响. DNS 是一个典型的最终一致性系统.这里之所以将最终一致性单独提出来,是因为它是弱一致性中非常推崇的一种一致性模型,也是业界在大型分布式系统的数据一致性上比较推崇的模型.

3. BASE理论

3.1 BASE理论概念

BASE是Basically Available(基本可用)、Soft State(软状态)和Eventually Consistent(最终一致性) 三个短语的缩写.
BASE理论是对CAP中一致性和可用性权衡的结果,其来源于对大规模互联网系统分布式实践的总结,是基于CAP定理逐步演化而来的.BASE理论的核心思想是:即使无法做到强一致性,但每个应用都可以根据自身业务特点,采用适当的方式来使系统达到最终一致性.

3.2 BASE理论中的三要素:

1️⃣. 基本可用
基本可用是指分布式系统在出现不可预知故障的时候,允许损失部分可用性----注意:这绝不等价于系统不可用.比如:

(1).响应时间上的损失.正常情况下,一个在线搜索引擎需要在0.5秒之内返回给用户相应的查询结果,但由于出现故障,查询结果的响应时间增加了1~2秒;

(2).系统功能上的损失:正常情况下,在一个电子商务网站上进行购物的时候,消费者几乎能够顺利完成每一笔订单,但是在一些节日大促购物高峰的时候,由于消费者的购物行为激增,为了保护购物系统的稳定性,部分消费者可能会被引导到一个降级页面.

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

3️⃣. 最终一致性
最终一致性强调的是所有的数据副本,在经过一段时间的同步之后,最终都能够达到一个一致的状态.因此,最终一致性的本质是需要系统保证最终数据能够达到一致,而不需要实时的保证系统数据的强一致性.

总的来说,BASE理论面向的是大型高可用可扩展的分布式系统,和传统的事务ACID特性是相反的,它完全不同于ACID的强一致性模型,而是通过牺牲强一致性来获得可用性,并允许数据在一段时间内是不一致的,但最终达到一致状态.但同时,在实际的分布式场景中,不同业务单元和组件对数据一致性的要求是不同的,因此在具体的分布式系统架构设计过程中,ACID特性和BASE理论往往又会结合在一起.

六. CAP,BASE以及ACID的关系

CAP描述了对于一个分布式系统而言重要的三要素:数据一致性,可用性,分区容错性之间的制约关系,当你选择了其中的两个时,就不得不对剩下的一个做出一定程度的牺牲;BASE和ACID都可以看做是对CAP三要素进行取舍后的某种特殊情况.
BASE强调可用性和分区容错性,放弃强一致性,这是大部分分布式系统的选择,比如NoSQL系统,微服务架构下的分布式系统.
ACID是单机数据的事务特性,因为不是分布式系统无需考虑分区容错,故而是选择了可用性和强一致性后的结果.

它们之间的关系如下所示:

七. 分布式系统的幂等性

幂等的概念来自于抽象代数,比如对于一元函数来说,满足以下条件即可称为满足幂等性.

在计算机科学中,一个操作如果多次执行产生的结果与一次执行的结果相同,这样的操作即符合幂等性.在分布式系统中,服务消费方调用服务提供方的接口,多次调用的结果应该与一次调用的结果一样,这正是分布式环境下幂等性的定义.

为什么幂等性对分布式系统而言如此重要?因为在分布式环境下,服务的调用一般采用http协议或者rpc的方式,即双方需要通过网络进行通信,而因为网络故障或者消息超时的存在,可能服务消费方已经成功调用了服务提供方的服务接口,但是消费方并没有收到来自对方的成功响应,导致消费方以为服务调用失败从而再次进行调用,也就是说网络的不可靠性导致了服务接口被多次调用的可能.分布式系统必须保证在这种情况下,即使接口被多次调用,它对系统产生的影响应该与该接口只被调用一次的结果一样.