序言:
文章内容输出来源:拉勾教育Java高薪训练营。
本篇文章是学习课程中的一部分课后笔记
一、分布式系统
1、分布式概述
- 一个业务拆分成多个子业务,分布在不同的服务器节点,共同构成的系统称为分
布式系统。
集群:多个人在一起作同样的事 。
分布式 :多个人在一起作不同的事 。
2、分布式系统面临的问题
-
1)通信异常
网络本身的不可靠性,因此每次网络通信都会伴随着网络不可用的风险(光纤、路由、DNS等硬件设备或系统的不可用),都会导致最终分布式系统无法顺利进行一次网络通信,另外,即使分布式系统各节点之间的网络通信能够正常执行,其延时也会大于单机操作,存在巨大的延时差别,也会影响消息的收发过程,因此消息丢失和消息延迟变的非常普遍。 -
2)网络分区
网络之间出现了网络不连通,但各个子网络的内部网络是正常的,从而导致整个系统的网络环境被切分成了若干个孤立的区域,分布式系统就会出现局部小集群,在极端情况下,这些小集群会独立完成原本需要整个分布式系统才能完成的功能,包括数据的事务处理,这就对分布式一致性提出非常大的挑战。 -
3)节点故障
节点故障是分布式系统下另一个比较常见的问题,指的是组成分布式系统的服务器节点出现的宕机或"僵死"现象,根据经验来说,每个节点都有可能出现故障,并且经常发生.。 -
4)三态
分布式系统每一次请求与响应存在特有的“三态”概念,即成功、失败和超时。
分布式系统中,由于网络是不可靠的,虽然绝大部分情况下,网络通信能够接收到成功或失败的响应,但当网络出现异常的情况下,就会出现超时现象,通常有以下两种情况:
- 由于网络原因,该请求并没有被成功的发送到接收方,而是在发送过程就发生了丢失现象。
- 该请求成功的被接收方接收后,并进行了处理,但在响应反馈给发送方过程中,发生了消息丢失现象。
3、CAP定理
-
CAP 理论含义是:
一个分布式系统不可能同时满足一致性(C:Consistency),可用性(A: Availability)和分区容错
性(P:Partition tolerance)这三个基本需求,最多只能同时满足其中的2个。
cap理论.png


4、BASE 理论
- BASE:全称:Basically Available(基本可用),Soft state(软状态),和 Eventually consistent(最终一致性)三个短语的缩写,来自 ebay 的架构师提出。
- 核心思想:
即使无法做到强一致性,但每个应用都可以根据自身业务特点,采用适当的方式来使系统达到最终一致性。
- Basically Available(基本可用)
例:- 响应时间上的损失:正常情况下,一个在线搜索引擎需要在0.5秒之内返回给用户相应的查询结果,但由于出现故障(比如系统部分机房发生断电或断网故障),查询结果的响应时间增加到了1~2秒。
-
功能上的损失:正常情况下,在一个电子商务网站(比如淘宝)上购物,消费者几乎能够顺利地完成每一笔订单。但在一些节日大促购物高峰的时候(比如双十一、双十二),由于消费者的购物行为激增,为了保护系统的稳定性(或者保证一致性),部分消费者可能会被引导到一个降级页面。
功能上损失.png
- Soft state(软状态)
- 什么是软状态呢?相对于一致性,要求多个节点的数据副本都是一致的,这是一种“硬状态”。
- 软状态指的是:允许系统中的数据存在中间状态,并认为该状态不影响系统的整体可用性,即允许系统在多个不同节点的数据副本之间进行数据同步的过程中存在延迟。
- Eventually consistent(最终一致性)
最终一致性强调的是系统中所有的数据副本,在经过一段时间的同步后,最终能够达到一个一致的状态。因此最终一致性的本质是需要系统保证最终数据能够达到一致,而不需要实时保证系统数据的强一致性。
5、分布式理论:一致性协议 2PC
- 2PC ( Two-Phase Commit缩写)即两阶段提交协议,是将整个事务流程分为两个阶段,准备阶段(Preparephase)、提交阶段(commit phase)。
两个阶段过程:
-
准备阶段(Prepare phase):事务管理器给每个参与者发送Prepare消息,每个数据库参与者在本地执行事务,并写本地的Undo/Redo日志,此时事务没有提交。
(Undo日志是记录修改前的数据,用于数据库回滚,Redo日志是记录修改后的数据,用于提交事务后写入数据文件) -
提交阶段(commit phase):如果事务管理器收到了参与者的执行失败或者超时消息时,直接给每个参与者发送回滚(Rollback)消息;否则,发送提交(Commit)消息;参与者根据事务管理器的指令执行提交或者回滚操作,并释放事务处理过程中使用的锁资源。注意:必须在最后阶段释放锁资源。
-
2PC执行正常流程
正常流程.png
正常流程.png
-
2PC执行异常流程
异常流程.png

-
2PC 优点缺点
优点:
原理简单,实现方便缺点:
同步阻塞:
在二阶段提交的执行过程中,各个参与者在等待其他参与者响应的过程中,无法进行其他操作。这种同步阻塞极大的限制了分布式系统的性能。
单点问题:
协调者在整个二阶段提交过程中很重要,如果协调者在提交阶段出现问题,那么整个流程将无法运转,更重要的是:其他参与者将会处于一直锁定事务资源的状态中,而无法继续完成事务操作。
数据不一致:
假设当协调者向所有的参与者发送 commit 请求之后,发生了局部网络异常或者是协调者在尚未发送完所有commit 请求之前自身发生了崩溃,导致最终只有部分参与者收到了 commit 请求。这将导致严重的数据不一致问题。
过于保守:
如果在二阶段提交的提交询问阶段中,参与者出现故障而导致协调者始终无法获取到所有参与者的响应信息的话,这时协调者只能依靠其自身的超时机制来判断是否需要中断事务,显然,这种策略过于保守。换句话说,二阶段提交协议没有设计较为完善的容错机制,任意一个节点失败都会导致整个事务的失败。
6、分布式理论:一致性协议 3PC
-
3PC,全称 “three phase commit”,是 2PC 的改进版,将 2PC 的 “提交事务请求” 过程一分为二,共形成了由CanCommit、PreCommit和doCommit三个阶段组成的事务处理协议。
3pc.png
-
2PC对比3PC
1.首先对于协调者和参与者都设置了超时机制(在2PC中,只有协调者拥有超时机制,即如果在一定时间内没有收到参与者的消息则默认失败),避免了参与者在长时间无法与协调者节点通讯(协调者挂掉了)的情况下,无法释放资源的问题,因为参与者自身拥有超时机制会在超时后,自动进行本地commit从而进行释放资源。降低了整个事务的阻塞时间和范围。2.通过CanCommit、PreCommit、DoCommit三个阶段的设
计,相较于2PC而言,多设置了一个缓冲阶段保证了在最后提交阶段之前各参与节点的状态是一致的 。问题:3PC协议并没有完全解决数据不一致问题。
7、分布式理论:一致性算法 Paxos


- 保证Paxos算法的活性
通过选取主Proposer,并规定只有主Proposer才能提出议案。
这样一来只要主Proposer和过半的Acceptor能够正常进行网络通信,
那么但凡主Proposer提出一个编号更高的提案,该提案终将会被批准,这样通过选择一个主Proposer,整套Paxos算法就能够保持活性,防止死循环。
8、分布式理论:一致性算法 Raft
- Raft 是一种为了管理复制日志的一致性算法。
Raft提供了和Paxos算法相同的功能和性能,但是它的算法结构和Paxos不同。
Raft将一致性算法分解成了3模块
1. 领导人选举: Raft使用心跳机制来触发选举
2. 日志复制 :
Leader把请求作为日志条目(Log entries)加入到它的日志中,
然后并行的向其他服务器发起 AppendEntries RPC复制日志条目。当这条日志被复制到大多数服务器上,Leader将这条日志应用到它的状态机并向客户端返回执行结果。
日志复制.png
3. 安全性
二、分布式架构网络通信
1、什么是RPC
-
RPC全称为remote procedure call,即远程过程调用。
-
RPC架构包含了四个核心的组件,分别是Client,Client Stub,Server以及Server Stub,这个Stub
可以理解为存根。1).客户端(Client),服务的调用方。
2).客户端存根(Client Stub),存放服务端的地址消息,再将客户端的请求参数打包成网络消息,然后通过网络远程发送给服务方。
3).服务端(Server),真正的服务提供者。
4).服务端存根(Server Stub),接收客户端发送过来的消息,将消息解包,并调用本地的方法。

2、什么是RMI
-
Java RMI 指的是远程方法调用 (Remote Method Invocation),是java原生支持的远程调用 ,采用JRMP(Java Remote Messageing protocol)作为通信协议。
-
1.客户端:
1)存根/桩(Stub):远程对象在客户端上的代理;
2)远程引用层(Remote Reference Layer):解析并执行远程引用协议;
3)传输层(Transport):发送调用、传递远程方法参数、接收远程方法执行结果。 -
2.服务端:
1)骨架(Skeleton):读取客户端传递的方法参数,调用服务器方的实际对象方法,
并接收方法执行后的返回值;
2)远程引用层(Remote Reference Layer):处理远程引用后向骨架发送远程方法调用;
3)传输层(Transport):监听客户端的入站连接,接收并转发调用到远程引用层。

3、BIO、NIO、AIO
- 同步&阻塞

-
BIO
同步阻塞IO。B代表blocking
服务器实现模式为一个连接一个线程,即客户端有连接请求时服务器端就需要启动一个线程进行处理。
适用场景:Java1.4之前唯一的选择,简单易用但资源开销太高. -
NIO
同步非阻塞IO (non-blocking IO / new io)是指JDK 1.4 及以上版本。
服务器实现模式为一个请求一个通道,即客户端发送的连接请求都会注册到多路复用器上,多路复用器轮询到连接有IO请求时才启动一个线程进行处理。-
通道(Channels)
NIO 新引入的最重要的抽象是通道的概念。Channel 数据连接的通道。 数据可以从Channel读到Buffer中,也可以从Buffer 写到Channel中 。 -
缓冲区(Buffers)
通道channel可以向缓冲区Buffer中写数据,也可以像buffer中存数据。 -
选择器(Selector)
使用选择器,借助单一线程,就可对数量庞大的活动 I/O 通道实时监控和维护。
-

例子:

-
AIO
异步非阻塞IO。A代表asynchronize
当有流可以读时,操作系统会将可以读的流传入read方法的缓冲区,并通知应用程序,对于写操作,OS将write方法的流写入完毕是操作系统会主动通知应用程序。
因此read和write都是异步 的,完成后会调用回调函数。使用场景:连接数目多且连接比较长(重操作)的架构,比如相册服务器。重点调用了OS参与并发操作,编程比较复杂。Java7开始支持
网友评论