avatar

分布式架构设计理论-01

分布式架构介绍

什么是分布式系统

分布式系统是一个硬件或软甲组件分布在不同的网络计算机上,彼此之间仅仅通过消息传递进行通信和协调的系统。
通俗的理解,所谓分布式系统,就是一个业务拆分成多个子业务,分布在不同的服务器节点,共同构成的系统称为分布式系统,同一个分布式系统中的服务器节点在空间部署上市可以随意分布的,这些服务器可能放在不同的机柜中,也可能在不同的机房中,甚至分布在不同的城市中。

分布式和集群的区别

集群: 多个服务器做同一件事

分布式:多个服务器做不同的事情

分布式系统特性

  • 分布性:空间随机分布,这些计算机可以分布在不同的机房,不同的城市,甚至不同的国家
  • 对等性:分布式系统中的计算机没有主从之分,组成分布式系统的所有节点都是对等的
  • 并发性:同一个分布式系统的多个节点,可能会并发的操作一些共享的资源,诸如数据库或分布式存储
  • 缺乏全局时钟:既然各个计算机之间是依赖于交换信息来进行通信,很难定义两件事件的先后顺序,缺乏全局时钟控制顺序
  • 故障总是会发生:组成分布式的计算机,都有可能在某一个时刻突然间崩掉,分的计算机越多,可能崩掉一个的几率就越大。如果再考虑到设计程序时的异常故障,也会加大故障的概率
  • 处理单点故障:单点SPoF(Single Point of Failure): 某个角色或者功能只有某一台计算机再支撑,在这台计算机上出现的故障是单点故障。

分布式系统面临的问题

1、通信异常
网络本身的不可靠性,因此每次网路通信都会伴随着网络不可用的风险,都会导致最终分布式系统无法顺利进行一次网络通信,另外,即使分布式系统各个节点之间的网络通信能够正常执行,其延时也会大于单机操作,存在巨大的延时差别,也会影响消息的收发过程,因此消息丢失和消息延迟变得非常普遍
2、网路分区
网络之间出现了网路不连通,但各个子网络的内部网络是正常的,从而导致整个系统的网络环境被分成若干个孤立的区域,分布式系统就会出现局部小集群,在极端情况下,这些小集群会独立完成原本需要整个分布式系统才能完成的功能,包括数据的事务处理,这就对了分布式一致性提出非常大的挑战
3、节点故障
节点故障是分布式系统下另一个比较常见的问题,指的是组成分布式系统的服务器节点出现的宕机或”僵死”现象,根据经验来说,每个节点都有可能出现故障,并且经常发生
4、三态
分布式系统每一次请求与相应存在特有的三态概念,即成功、失败和超时
5、重发
分布式系统在发生调用的时候可能会出现失败、超时的情况,这个时候需要重新发起调用
6、幂等
一次和多次请求某一个字段本身应该具有相同,也就是说,其任意多次执行对资源本身所产生的影响均与第一次执行的影响相同。

分布式理论

数据一致性

什么是分布式数据一致性

分布式数据一致性,指的是数据在多份副本中存储时,各副本中的数据是一致的

副本一致性

分布式系统当中,数据往往会有多个副本,多个副本就需要保证数据的一致性,这就带来了同步的问题,因为网络延迟等因素,我们几乎没有办法保证可以同时更新所有及其当中的包括备份所有数据,就会有数据不一致的情况。
总的来说,我们无法找到一种能够满足分布式系统中数据一致性解决办法。因此,如何即保证数据的一致性,同时又不影响系统运行的性能,是每一个分布式系统都需要重点考虑和权衡的。于是,一致性级别由此诞生。

一致性分类

1、强一致性:这种一致性级别是最符合用户直觉的,它要求系统写入什么,读出来的也会是什么,用户体验好,但是实现起来往往对系统的性能影响大,但是强一致性很难实现
2、弱一致性:这种一致性级别约束了系统在写入成功后,不承诺立即可以读到写入的值,也不承诺多久之后数据能够达到一致性,但是尽可能的保证某个时间级别(比如秒级)后,数据能够达到一致性状态
3、最终一致性:最终一致性也是弱一致性的一种,它无法保证数据更新后,所有后续的访问都能看到最新的数据,但是需要一个时间,在这个时间之后可以保证这一点(就是在一段时间后,节点间的数据最终达到一致状态),而在这个时间内,数据也许是不一致的,这个系统无法保证强一致性的时间片段被称为“不一致窗口”。不一致窗口的时间长短取决于很多因素,比如备份数据的个数、网路传输延迟速度、系统负载等
4、因果一致性:如果一个进程A它已经更新了一个数据项,那么进程B的后续访问将返回更新后的数据,与进程A无因果关系的进程C的访问遵守一般的最终一致性规则

5、 读已之所写一致性:当进程A自己更新一个数据项之后,它总是访问到更新过的值,绝不会看到旧值。这是因果一致性模型的一个特例

6、会话一致性:它把访问存储系统的进程放到会话的上下文中,只要会话还存在,系统就保证读已之所写一致性。如果由于某些失败情形会话终止,就要建立新的会话,而且系统的保证不会延续到新的会话。

7、单调读一致性:如果一个进程已经读取到一个特定值,那么该进程不会读取到该值以前的任何值
8、单调你写一致性:系统保证对同一个进程的写操作时串行化的

一致性模型:

CAP理论

CAP定理(CAP theorem),又被称为布鲁尔定理,它指出对于一个分布式计算系统来说,不可能同时满足以下三点
| 选项 | 具体意义 |
|一致性(Consistency)|所有节点访问时都是同一份最新的数据副本|
|可用性(Availability)|每次请求都能获取到非错的响应,但是不保证获取的数据为最新数据|
|分区容错性(Partitiontolerance)|分布式系统在遇到任何网络分区故障的时候,仍然能够对外提供满足一致性和可用性的服务,除非整个网络环境都发生了故障|

1、 一致性:这里指的是强一致性,在写操作完成后开始的任何读操作都必须返回该值,或者后续写操作的结果,也就是说,在一致性系统中,一旦客户端将值写入任何一台服务器并获得响应,那么之后client从其他任何服务器读取的都是刚写入的数据
2、可用性:系统中非故障节点收到的每个请求都必须有响应,在可用系统中,如果我们的客户端向服务器发送请求,并且服务器未崩溃,则服务器必须最终响应客户端,不允许服务器忽略客户的请求
3、分区容错性:允许网络丢失从一个节点发送到另一个节点的任意多条消息,即不同步,也就是说,G1和G2发送给对方的任何消息都是可以放弃的,也就是说G1和G2可能因为各种意外情况,导致无法成功进行同步,分布式系统要能容忍这种情况。

CAP三者不能同时满足

  • CA(Consistency+Availability):关注一致性和可用性,它需要非常严格的全体一致性的协议。CA的系统不能容忍网络错误或节点错误,一旦出现这样的问题,整个系统就会拒绝写请求,因为它并不知道对面的那个节点是否挂掉了,还是只是网络问题。唯一安全的做法就是把自己变成只读

  • CP(consistency+parition tolerance):关注一致性和分区容错性。它关注的是系统里大多数人的一致性协议。这样的系统只需要保证大多数节点数据一致性,而少数节点会在没有同步到最新版本的数据时变成不可用的状态。这样能够提供一部分的可用性

  • AP(availability+partition tolerance):这样的系统关心可用性和分区容错性。因此这样的系统不能达成一致性,需要给出数据冲突,给出数据冲突就需要维护数据版本

如何进行三选二

放弃了一致性,满足分区容错性,那么节点之间就有可能失去联系,为了高可用,每个节点只能用本地数据提供服务,而这样会容易导致全局数据不一致性。对于互联网应用来说,机器数量庞大,节点分散,网络故障再正常不过了,那么此时就是保障AP,放弃C的场景了,而从实际中理解,像网站这种偶尔没有一致性是能接受的,但是不能访问问题就非常严重了。
对于银行来说,就是必须保证强一致性,也就是说C必须存在,那么就只能用CA或者CP两种情况了,当保障强一致性和可用性(CA),那么一旦出现通信故障,系统将完全不可用。另一方面,如果保障了强一致性和分区容错性(CP),那么就具备了部分可用性。实际究竟应该选择什么,是需要通过业务场景进行权衡的(并不是所有情况都是CP好于CA的,只能查看信息但不能更新信息有时候还不如直接拒绝服务)

BASE理论

之前说过CAP,不可能同时满足,而分区容错性是对于分布式系统而言,是必须的,最后,我们说,如果系统能够同时实现CAP是再好不过的了,所以出现了BASE理论。
BASE:全称Basically Available(基本可用),Soft state(软状态)和Eventually consistent(最终一致性)三个短语的缩写,Base理论是对CAP中一致性和可用性权衡的结果,其来源于对大型互联网分布式实践的总结,是基于CAP定理逐步演化而来的。其核心思想是:既是无法做到强一致性(Strong consisitency),但每个应用都可以根据自身的业务特点,采用适当的方式来使系统达到最终一致性(Eventual consistency)。
1、基本可用:什么是基本可用性,假设系统出现了不可预知的故障,但是还能用,想比较正常的系统而言:

  • 响应时间上的损失:正常情况下的搜索引擎0.5秒既返回给用户结果,而基本可用的搜索引擎可以在1秒返回结果
  • 功能上的损失:在一个点上网站上,正常情况下,用户可以顺利完成每一笔订单,但是到了大促期间,为了保证购物系统的稳定,部分消费者可能会被引导到一个降级页面。

2、软状态:相对于原子性而言,要求多个节点的数据副本都是一致的,这是一种”硬状态”。软状态指的是:允许系统中的数据存在中间状态,并认为该状态不会影响系统的整体可用性,即允许系统在多个不同节点的数据副本存在数据延迟
3、最终一致性:上面说的软状态,不可能一直是软状态,必须有一个时间期限,在期限过后,应当保证所有的副本保持数据一致性,从而达到数据的最终一致性,这个时间期限取决于网络延迟,系统负载,数据复制方案设计等等因素

分布式一致性协议

两阶段提交协议(2PC)

两阶段提交协议

两阶段提交协议,简称2PC(2 Prepare Commit)是比较常用的解决分布式事务问题的方式,要么所有参与进程都提交事务,要么都取消事务,即实现ACID的原子性(A)的常用手段。

分布式事务:事务提供一种操作本地数据库的不可分割的一系列操作”要么什么都不做,要么做全套(All or Nothing)”的机制,而分布式事就是为了操作不同数据库的不可分割的一系列操作”要么什么都不做,要么做全套(All or Nothing)”的机制

2PC执行流程

1、成功执行事务,事务提交流程

第一阶段:

  • 事务询问,协调者向所有的参与者发送事务内容,询问是否可以执行事务提交操作,并开始等待各个参与者的响应
  • 执行事务,(写本地的Undo/Redo日志)
  • 各个参与者向协调者反馈事务询问的响应

阶段二:

  • 发送提交请求,协调者向参与者发出commit请求
  • 事务提交,参与者收到commit请求后,会正式执行事务提交操作,并在完成提交之后释放整个事务执行期间占用的事务资源
  • 反馈事务提交结果,参与者在完成事务提交之后,向协调者发送ACK消息
  • 完成事务,协调者接收到所有参与者反馈的Ack消息后,完成事务

2、中断事务流程
假如任何一个参与者向协调者反馈了No响应,或者等待超时之后,协调者尚无法接收到所有参与者的反馈响应,那么就会中断事务

阶段一:

  • 事务询问,协调者向所有的参与者发送事务内容,询问是否可以执行事务提交操作,并开始等待各个参与者的响应
  • 执行事务,(写本地的Undo/Redo日志)
  • 各个参与者向协调者反馈事务询问的响应

阶段二:

  • 发送回滚请求,协调者向所有参与者发送Rollback请求
  • 事务回滚,参与者接收到Rollback请求后,会利用其在阶段一重记录的Undo信息来执行事务回滚操作,并在完成回滚之后,释放在整个事务执行期间占用的资源
  • 反馈事务回滚结果,参与者在完成事务回滚之后,向协调者发送Ack消息
  • 中断事务,协调者接收到所有参与者反馈的Ack消息后,完成事务中断

2PC优缺点

  • 优点:原理简单
  • 缺点:
    • 同步阻塞,在二阶段提交的执行过程中,所有参与该事务操作的逻辑都处于阻塞状态,即当参与者占有公共资源时,其他节点访问公共资源会处于阻塞状态
    • 单点问题:如果协调者出现问题,那么整个二阶段提交流程将无法运转,若协调者是在二阶段中出现问题,那么其他参与者将会一直处于锁定事务资源的状态中,而无法继续完成事务操作
    • 数据不一致,在二阶段中,执行事务提交的时候,当协调者向所有的参与者发送Commit请求之后,发生了局部网络异常或者是协调者在尚未发送完Commit请求之前自身发生了崩溃,导致最终只有部分参与者收到了Commit请求,于是会出现数据不一致的现象
    • 太过保守,在进行事务提交询问的过程中,参与者出现故障而导致协调者始终无法获取到所有参与者的响应信息的话,此时协调者只能依靠自身的超时机制来判断是否需要中断事务,这样的策略过于保守,即没有完善的容错机制,任意一个节点的失败都会导致整个事务的失败

三阶段提交协议(3PC)

NWR协议

Gossip协议

Paxos协议

Raft协议

分布式系统设计策略

在分布式环境下,有几个问题是普遍关心的

  • 如何检测当前节点还存活
  • 如何保证高可用
  • 容错处理
  • 负载均衡

心跳检测

心跳顾名思义,就是以固定的频率向其他节点汇报当前节点状态的方式。收到心跳,一般可以认为一个节点和现在的网络是良好的。当然,心跳汇报时,一般也会携带一些附属的状态、元数据信息,以便管理

分布式服务治理

架构设计基本原则

文章作者: zenshin
文章链接: https://zlh.giserhub.com/2022/02/17/cl35o0mqv0037p4tg4cee82ur/
版权声明: 本博客所有文章除特别声明外,均采用 CC BY-NC-SA 4.0 许可协议。转载请注明来自 zenshin's blog
打赏
  • 微信
    微信
  • 支付宝
    支付宝

评论