springcloud学习二

2020-05-20 17:22:00
admin
原创
1296
摘要:springcloud学习二

sprigncloud alibaba实际上是对我们的springcloud2.x版本和1.x版本实现的扩展版本。

springcloud alibaba实际上是对我们的springcloud实现扩展组件,能够完美整合到springcloud开发的组件

1、nacos分布式注册中心、分布式配置中心 springcloudeureka+config

2、目的为了推广阿里云的产品,如果使用了springcloud alibaba,建议最好使用alibaba的张哥体系产品

分布式配置中心:

使用专门的服务器统一存放管理我们整个微服务的配置文件,能够完全动态实现对我们配置文件修改、新增,是不需要重启的我们的服务器。

分布式配置中心实现原理:

1、本地应用读取我们云端分布式配置中心文件(第一次建立长连接)

2、本地应用读取到配置文件之后,本地jvm和硬盘中都缓存一份。

3、本地应用与分布式配置中心服务器端一直保持长连接

4、当我们的配置文件发生变化(MD5|版本号)实现区分,将变化结果通知给我们的本地应用及时的刷新我们的配置。

注意:nacos分布式配置中心一定采用,bootstrap.yml形式优先加载,否则可能报错

bootstrap与application的区别

bootstrap 属于整个应用程序配置,最先被加载

bootstrap.yml用于应用程序上下文的引导阶段,appliation.yml由父spring applicaiontContext加载

CAP定律概念:

一致性(C):在分布式系统中,如果服务器是在集群的请求下,每个节点统一时刻查询的数据必须保持一致性的问题

可用性(A):集群节点中,部分节点出现了故障后,仍然可以继续使用

分区容错性(P):在分布式系统中网络存在脑裂的问题,部分的server与整个集群失去联系无法形成一个整体

采用:

cp情况下,虽然我们的服务不能用,但是必须要保证数据的一致性

AP情况下,可以短暂保证数据不一致性,但是最终可以一致性,不管怎样,要能够保证我们的服务可用

Zookeeper和eureka的区别

相同点:都可以实现分布式注册中心

不同点:Zookeeper采用CP保证数据的一致性的问题,原理采用Zab原子广播协议,当我们的zk领导因为某种原因

宕机的情况下,会自动触发重新选一个新的领导的角色,整个选举的过程是为了保证数据的一致性的问题,在选举过程中整个zk环境是不可以用的,可以短暂可能无法使用到zk,微服务采用改模式的情况下可能无法实现通讯(本地有缓存除外)

eureka:采用ap的设计理念架构注册中心,完全中心化思想,也就是没有主从之分。每个节点都是均等,采用互相注册原理,你中我有我,我中有你,只要最后有一个eureka节点存在就可以保证整个微服务可以实现通讯。

我们在注册中心,可用性在优先级最高,可以读取数据短暂不一致性,但是至少要能够保证注册中心可用性

中心化:必须围绕一个领导角色作为核心,

去中心化:每个角色相等,均等

nacos 和eureka的区别

nacos从1.0版本支持CP和AP混合模式集群,默认是采用AP保证服务可用性,CP的形式底层集群raft协议保证数据的一致性。

如果我们采用AP模式注册服务的实例仅支持临时注册形式,在网络分区产生抖动的情况下仍然还可以继续注册我们的服务列表。

那么选择CP模式必须保证数据的强一致性的问题,在网络分区产生抖动的情况下,是无法注册我们的服务列表的。选择CP模式可以支持注册实例永久的

ZAB的协议实现原理(zookeeper)

通过比较myid,myid谁最大谁可能是领导角色,只要满足过半的机制就可以成为领导角色,后来启动的节点不会参与选举的。

如何保持数据的一致性的问题

所有的写的请求统一交给我们的领导角色实现,领导角色写完数据之后,领导这将数据同步给每个节点

注意:数据之间同步采用2pc两阶段提交协议

选举过程:

先去比较zxid,zxid谁最大谁就是领导角色

如果zxid相等的情况下,myqid谁最大谁就是领导角色

raft协议氛围角色|名词

1、状态:分三种:跟随者,竞选者、领导者

2、每次选举一个新的领导角色,任期都会实现增加,例如:第一届、第二届

选举的过程是怎么样的?

1、默认的情况下每个节点都是跟随者

2、每个节点会随机的生成一个选举的超时时间,例如大概是100-300ms在这个超时的时间范围必须要等待

3、超时时间过后,当前的节点的状态可能有跟随者变为竞选者状态,谁先苏醒谁是竞选者,会给其他的节点发出选举的投票通知,只有该竞选者有超过半数,即可为领导角色

raft 数据的复制原理

1、所有的请求统一交给我们的领导角色完成,会写入该对应的日志,标记该状态我提交状态

2、为了提交该日志,领导角色就会将该日志心跳的形式发送其他的跟随者,只要满足过半的跟随者可以写入

该数据,则为直接通知其他节点同步该数据,这个称作为日志复制。

发表评论
评论通过审核之后才会显示。
文章分类
联系方式
联系人: 郑州-小万
电话: 13803993919
Email: 1027060531@qq.com
QQ: 1027060531
网址: www.wanhejia.com