Nacos做分布式配置中心

分布式配置中心产生的背景?
在项目中定义配置文件,最大的缺陷就是在生产环境正在运行的时候修改配置文件需要重启服务器。

Nacos默认登录地址:http://127.0.0.1:8848/nacos/
Nacos手册地址:https://nacos.io/zh-cn/docs/deployment.html
Dataid名称:默认的情况
服务名称-版本.yml|properties
版本:dev/test/pre/prd等

切换数据源之前的配置都会没掉,切换成mysql或者本地

@RefreshScope 刷新配置文件

默认加载propertity

nacos中默认嵌入小型数据库

nacos集群到同一个mysql

Nacos、Eureka的区别
相同点:都可以实现分布式服务注册中心
不同点:Nacos从1.0版本开始支持CP/AP混合模式集群,默认AP模式保证服务可用性,CP的形式底层集群使用raft协议(选举)保证数据的一致性。在网络分区产生抖动的情况下不可以继续注册服务。AP模式仅支持服务临时注册的,注册中心列表存在内存里,不是持久化的,在网络分区产生抖动的情况下仍然可以继续注册我们的服务列表。

什么情况下选择AP和CP呢?
必须要求读取的接口的地址保证强一致性的问题,可以采用CP模式。

如何切换模式?
‘192.168.3.100:8848/nacos/v1/ns/operator/switches?entry=serverMode&value=CP’
‘192.168.3.100:8849/nacos/v1/ns/operator/switches?entry=serverMode&value=CP’
‘192.168.3.100:8850/nacos/v1/ns/operator/switches?entry=serverMode&value=CP’
必须使用post

Eureka与Nacos有哪些区别
1、Eureka采用ap模式形式实现注册中心
2、Nacos默认采用Ap模式,在1.0版本之后采用ap+cp模式混合实现注册中心。

eureka与nacos底层实现集群协议有哪些区别?
1、去中心化对等
2、Raft协议实现集群产生领导角色

什么是分布式一致性算法?
保证集群中每个节点的一致性问题
场景:redis集群、nacos集群、mongdb集群

分布式事务一致性框架与分布式系统一致性算法有哪些?
:核心解决我们在实际系统中产生跨事务导致分布式事务问题。核心靠的就是最终一致性。
有哪些:rocketmq事务消息、rabbitmq补单、lcn、seata等。

分布式系统一致性算法:解决我们系统之间集群之后每个节点保持数据的一致性
有哪些:raft(nacos),zab(zookeeper),paxos等。

Zab协议,选举策略,配置myid,myid数值大的能力强为领导,要满足>=n/2+1节点,已经选举出领导之后,再加入更强大的节点也不会重新选领导,除非原先的节点不可用

如何保持一致性的问题:所有写的请求统一交给领导角色实现,领导角色写完数据之后,领导角色把数据同步给跟随节点,

首先领导节点把zxid=100发送给跟随节点,通知接受领导节点的数据同步,只要有过半的跟随节点同意就可以同步

有一个情况:当领导节点把数据同步给其中一个跟随节点之后,这个跟随节点的zxid就会变成100,这时候领导节点宕机了,其他节点重新选举,最新领导节点为zxid为100的。
zxid相等的情况下,myid最大的为领导角色,zxid是代表更新的情况,初始为0,越大越新,自增。

raft协议:
1、状态:分为三种,跟随者、竞选者(候选人),领导角色。
2、大多数:>=n/2+1
3、任期:每次选举一个新的领导角色,任期都会实现增加
,比如第一任,第二任
4、竞选者谁的票数最多,谁就是为领导角色

存在的疑问:
多个竞选者,产生的票数都完全一样,谁的领导角色?
集群节点为偶数才会发生,奇数不会

选举的过程:
1、默认的情况下每个节点都是跟随者
2、每个节点会随机生成一个选举超时时间,例如大概是100-300ms,在这个超时的时间范围内必须要等待,
3、超时时间(Leader止时)最短的变为竞选者,超时时间过后,当前的节点的状态可能有跟随者变为竞选者,这个竞选者对其他节点发出投我一票的通知
4、如果随机的超时时间碰巧相同,
5、所有节点的随机超时时间都一样,本次投票全部作废,重新生成随机超时时间
6、偶数个节点,竞选者的票数一致时,一样作废,
7、建议奇数个nacos节点
谁超时时间最短,大概率为领导角色

故障重新实现选举
1、领导角色每隔一段时间发送心跳,每发送一次就连任一次,如果跟随者节点不能及时的收到领导角色的消息,那么这时候跟随者状态就会变为竞选者,发给其他的节点发出选举投票通知

数据是如何保持一致性的?类似zab
1、所有的写的请求都是统一交给我们的领导角色完成,会写入该对应的日志,标记该状态是未提交状态
2、为了提交该日志,领导角色就会将该日志以心跳的形式发送给其他的跟随者节点,只要超过过半的跟随者节点写入该日志,则直接通知其他的跟随者节点同步该数据,这个过程称做为日志复制的过程。

以上是cp模式的

任何算法来源于生活

zk要满足n/2+1以上节点,整个zk环境才能使用

keepalivd可以重启除了ngnix之外的服务器吗

Eureka、Zk的区别
相同点:都可以实现分布式服务注册中心
不同点:ZK采用CP模式保证数据的一致性问题,原理采用Zab原子广播协议,当我们的Zk领导因为某种原因宕机的情况下,会自动重新选一个新的领导角色,整个选举过程为了保持数据的一致性问题,在选举的过程中整个zk环境是不可以使用的,短暂的无法使用zk。微服务采用该模式的情况下,可能无法实现通讯(本地无缓存的情况)。可运行的节点必须满足过半机制,否则不允许。
Eureka采用ap的设计理念架构注册中心,完全去中心化思想。相互注册,你中有我我中有你,没有主从之分,有一台就能工作

中心化:必须围绕一个领导角色作为核心
去中心化:每个角色均等。

最大的区别:Nacos支持CP/AP模式,默认AP模式
CP模式:提供强一致性,数据持久性和网络分区容忍度。(宁愿服务不能用,也要保持数据一致性)
AP模式:提供了最终的一致性和网络分区容忍性,但提供了数据持久性。(可以短暂数据不一致,但是最终数据一致,不管怎么样服务必须能用)
混合模式:为某些数据提供CP,为某些其他数据提供AP。

分布式一致性的算法raft协议
java,c,c++都写过该协议,大公司都是自己写

大多数的注册中心都是Ap,比如Eureka

服务级别信息和集群级别信息始终通过CP协议进行操作,因此在AP模式下无法对其进行编辑。

CAP定律:这个定理的内容是指的是在一个分布式系统中、Consistency(一致性)、 Availability(可用性)、Partition tolerance(分区容错性),三者不可得兼

一致性©:在分布式系统中,如果服务器集群,每个节点在同时刻访问必须要保持数据的一致性。
可用性(A):集群节点中,部分节点出现故障后任然可以使用 (高可用)
分区容错性§:在分布式系统中网络会存在脑裂的问题,部分Server与整个集群失去节点联系,无法组成一个群体。
只有在CP和AP选择一个平衡点

nacos-github问题社区:https://github.com/alibaba/nacos/releases

nginx有故障转移功能

Nacos怎么做集群
通过Nginx做反向代理

默认单机模式

注册中心没有必要将数据持久化到数据库中,可以持久化到本地的硬盘。**
分布式配置中心,默认是将数据持久化到本地嵌入式的数据库,可以跟换数据源到Mysql

服务同时注册到三台Nacos上不好,注册信息冗余,三台都有注册信息太冗余

Nacos在不同的版本下运行集群是不一样的:
1、在linux版本中运行的时候默认是集群模式,如果需要改为单机启动,需要修改配置
2、在Windows版本中运行的时候默认是单机模式()
3、使用命令startup.cmd -m cluster、startup.cmd -m standlone

配置集群时,nacos,conf目录下的cluster.conf文件中不能使用127.0.0.1,必须使用准确的ip地址,比如192.168.3.100

注册中心:
Eureka、nacos、consul、Zookeeper

1、分布式配置中心有哪些?
(1)spring cloud config的最大缺点是没有界面(常用),需要去github上配置
(2)Nacas属于轻量级配置中心(常用)
(3)携程阿波罗重量级(常用)
(4)disConfig

2、轻量级和重量级的区别?
(1)轻量级:部署、架构设计原理都比较简单,学习成本比较低(小项目)
(2)重量级:部署、架构设计、体量都是非常大,学习成本比较高(大项目)

3、分布式配置中心要有
视图层(门户网站)
服务器(接口)
Mysql服务器
本地应用,启动时去服务器中读取配置,缓存到jvm和本地硬盘中
使用长连接,一旦配置文件发生变化,通知本地应用,

4、怎么判断配置文件是否发生变化?
(1)版本号
(2)MD5
(3)时间戳

5、分布式配置中心实现原理
(1)本地应用读取我们云端分布式配置中心文件(第一次建立长连接)
(2)本地应用读取到配置文件之后,本地jvm和硬盘中都会缓存一份。
(3)本地应用与分布式配置中心服务器端一直保持长连接.
(4)当我们的配置文件发生变化(MD5|版本号)实现区分,将变化结果通
知给我们的本地应用及时的刷新我们的配置文件。

6、Nacos使用配置中心的发布规则
()
()
()
()

7、注意事项
naocs本地如果也配置的话,会抛nacos异常,因为它不
知道要读本地的还是配置中心上的

8、bootstrap和application的区别
(1)bootstrap是属于整个应用程序配置,最先被加载
,属于整个应用程序的上下文,优先启动
(2)application是属于spring的上下文

9、nacos默认支持三种部署形式
(1)单机-用于测试和单机试用
(2)集群模式-用于生产环境,确保高可用
(3)多集群模式-用于多数据中心场景,跨网络集群比如上海和武汉

10、nacos集群
1、使用lvs,不太好,windows没有虚拟化技术
2、使用nginx进行负载均衡
3、集群访问的是同一个Mysql,实现数据共享

发布了54 篇原创文章 · 获赞 2 · 访问量 1882

猜你喜欢

转载自blog.csdn.net/qq_42972645/article/details/104170541