集中式到分布式学习基础理论

zk本身是做分布式数据一致性的一个解决方案,分布式应用程序可以基于它实现发布订阅、负载均衡、集群管理、分布式协调、分布式锁等功能

在说zk之前还是要说一下集中式到分布式的演进,对于后续的理解也是很有帮助的

1 集中式系统

集中式系统,是由一台或多台主计算机组成的中心节点,数据集中存储于这个中心节点中,并且整个系统的所有业务单元都集中部署在这个中心节点上,系统的所有功能均由其集中处理。也就是说,在集中式系统中,每个终端或客户端机器仅仅负责数据的录入和输出,而数据的存储与控制处理完全交由主机来完成。

集中式系统最大的特点就是部署结构简单。由于集中式系统往往基于底层性能卓越的大型主机,因此无须考虑如何对服务进行多个节点的部署,也就不用考虑多个节点之间的分布式协作问题。

2 分布式系统

分布式系统是一个硬件或软件组件分布在不同的网络计算机上,彼此之间仅仅通过消息传递进行通信和协调的系统

分布式系统的几个特点:

  • 分布性
  • 对等性
  • 并发性
  • 缺乏全局时钟
  • 故障总会发生

3 分布式系统容易出现的问题

3.1 通信异常

从集中式到分布式,通信需要依靠网络,但是网络总会有一些时候不会很可靠,所以也就需要考虑网络的因素。分布式系统在各个节点之中进行通信,因此每次通信都会伴随着网络不可用的风险,硬件设备也会有可能出现不可用的情况。

由于在通信中引入了网络,所以同时也要考虑网络延迟的问题,分布式比单机的响应时间要长,因此消息丢失和消息延迟就会变得更加普遍。

3.2 网络分区

当网络发生异常,分布式系统中只有一部分节点可以正常通信,另一些节点不能,这个现象就被称为脑裂。网络分区出现时,分布式系统就会出现局部小集群,极端情况下,这些小集群就会独立完成原本需要整个分布式系统完成的功能,包括数据得事务处理,这里对分布式一致性的要求就比较高了。

3.3 三态

在分布式系统中,每一个请求的发送都对应着三种情况,成功、失败、超时,这就被称为三态。当网络出现异常时,如果出现超时,我们没有办法确定出现问题的位置,有可能在发送过程中丢失了消息,也有可能在接受返回的消息事丢失了消息。

3.4 节点故障

分布式系统中的某个节点出现宕机或僵死的现象。

4 从ACID到CAP/BASE

4.1 ACID

事务 是一系列对系统中数据进行访问与更新的操作所组成的一个程序执行逻辑单元。

一个事务要不就全部执行,要不就全不执行。

事务有四个特征,分别是原子性(Atomicity)、一致性(Consistency)、隔离性(Isolation)、持久性(Durability),简称为事务的ACID。

4.1.1 原子性

事务的执行只有两种结果:

  • 全部执行
  • 全不执行

4.1.2 一致性

事务的执行不能破坏数据库的完整性和一致性,一个事务在执行之前和之后,数据库都必须处于一致性状态,必须从一个状态到另外的一个状态。

如果数据库在运行过程中被中断,这些未完成的事务对数据库的修改就只执行了一部分,此时就造成了数据不一致的状态。

4.1.3 隔离性

在并发环境中,并发的事务时相互隔离的,一个事务不能被其他的事务所干扰。不同的事务并发操作相同的数据时,每个事务都有自己完整的数据空间,一个事务内部的操作与使用的数据对其他事务时隔离的,并发执行各个事务之间不能互相干扰

4.1.4 持久性

事务提交成功之后,对数据库中对应的数据状态是永久性的。

4.2 CAP和BASE理论

4.2.1 CAP

1. C(Consistency)一致性

一致性是指在多个副本之间能否保持一致的特性。在一致性的需求下,当一个系统在数据一致性的状态下执行更新操作后,应该保证系统的数据仍然处于一致的状态

例如,在分布式系统中,A 将一个节点的值 v1 更改为了 v2 ,但是 B 从另一个节点中读取到的值还是 v1 ,这个时候就造成了不一致。

2. A(Availability)可用性

可用性是指系统提供的服务必须一直处于可用的状态,对于用户的每一个操作请求是能够在有限的时间内返回结果。

有限的时间内:对于一个用户的请求要在指定的时间内返回处理结果,如果超过了这个时间范围,那么就被认为是不可用的

返回结果:要求系统完成的用户请求之后返回一个正常的响应结果,即成功或失败,而不是一个让用户感觉疑惑的结果

3. P(Partition tolerance)分区容错性

分区容错性约束了一个分布式系统需要具有如下特征:分布式系统在遇到任何网络分区故障的时候,仍然需要能够保证对外提供满足一致性和可用性的服务,除非是整个网络环境都发生了故障。

网络分区是指在分布式系统中,不同的节点分布在不同的子网络中,由于一些特殊的原因导致这些子网络之间出现网络不连通的状况,丹格格自网络的内部是正常的,从而导致整个系统的网络环境被分成了若干个孤立的区域。

放弃CAP定理 说明
放弃 C 要高可用并允许分区,则需放弃一致性。一旦分区发生,节点之间可能会失去联系,为了高可用,每个节点只能用本地数据提供服务,而这样会导致全局数据的不一致性。

典型的应用就如某米的抢购手机场景,可能前几秒你浏览商品的时候页面提示是有库存的,当你选择完商品准备下单的时候,系统提示你下单失败,商品已售完。这其实就是先在 A(可用性)方面保证系统可以正常的服务,然后在数据的一致性方面做了些牺牲,虽然多少会影响一些用户体验,但也不至于造成用户购物流程的严重阻塞。

但是,这里说的放弃一致性,并不是完全不需要数据一致性,放弃的只是数据的强一致性,保留了数据的最终一致性。
放弃 A 如果不要求A(可用),相当于每个请求都需要在服务器之间保持强一致,而P(分区)会导致同步时间无限延长(也就是等待数据同步完才能正常访问服务),一旦发生网络故障或者消息丢失等情况,就要牺牲用户的体验,等待所有数据全部一致了之后再让用户访问系统。

设计成CP的系统其实不少,最典型的就是分布式数据库,如Redis、HBase等。对于这些分布式数据库来说,数据的一致性是最基本的要求,因为如果连这个标准都达不到,那么直接采用关系型数据库就好,没必要再浪费资源来部署分布式数据库。
放弃 P 如果不要求P(不允许分区),则C(强一致性)和A(可用性)是可以保证的。但放弃P的同时也就意味着放弃了系统的扩展性,也就是分布式节点受限,没办法部署子节点,这是违背分布式系统设计的初衷的。

传统的关系型数据库RDBMS:Oracle、MySQL就是CA。

一般来说,分区容错性不可避免,因此可以认为CAP的P总是成立,剩下的A和P无法同时做到

4.2.2 BASE

BASE是Basically Available(基本可用)、Soft state(软状态)、Eventtually consistent(最终一致性)三个短语的简写

1. Basically Available(基本可用)

指分布式系统在出现不可预知故障的时候,允许损失部分可用性

比如:

响应时间的损失:响应时间适当延长,0.5s增加至1-2s

功能上的损失:在节日大促时,会对某些业务进行降级保护

2. Soft state(软状态)

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

3. Eventtually consistent(最终一致性)

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

你可能感兴趣的:(zk学习与使用记录)