大连做网站的公司/app接入广告变现

nacos永久实例与临时实例区别

nacos实例有2种，分别为临时实例（一般业务服务是临时的）和永久实例（如mysql、redis这种运维服务需要实时看到状态的设置为永久实例）。

临时实例只会缓存到服务注册列表中，下线一段时间后会被删除，永久实例不仅缓存到服务注册表中还会持久化到磁盘，下线后只是状态的改变不会被删除。

naclos1.x版本决定实例是临时还是永久是实例的本身，所以会出现一个服务有临时实例和永久实例，2.x版本后维度变成了服务，即服务要么是临时要么是永久，下面的实力只会有一种状态。

springcloud:nacos:discovery:#ephemeral单词是临时的意思，设置成false，就是永久实例了ephemeral: false

nacos服务注册原理

nacos1.x版本客户端通过发送http请求到服务端注册服务。

nacos2.x版本客户端启动的时候会跟nacos建立长连接，后续客户端注册及其它通讯都是基于这个长连接，目前假设长连接第一次建立的时候客户端会去做注册、订阅操作，假如服务端发现实例是临时实例会把一些信息缓存到客户端（如服务信息、订阅信息），这样做的目的是为了防止长连接因为某些原因端口重新连接上的时候做一个redo（本质就是个补偿机制，启动一个定时任务不停执行3s一次）操作，如重新注册服务、订阅。

nacos临时实例保活机制？

通过心跳机制来判断注册服务的状态。

nacos1.x实现逻辑是客户端会为临时实例开启一个心跳上报定时任务（5s）,通过http请求定时上报心跳信息，nacos服务端接收到上报信息后更新服务实例最后上报时间，服务端也开启一个定时任务（3s）定时查询服务实例心跳信息，如果发现超过15s没有上报信息会标志为不健康，超过30s会直接删除实例。

nacos2.x由于通讯协议改成了grpc，客户端跟服务端保持长连接，nacos利用了grpc协议本身心跳机制实现服务实例是否存活检测，如果连接断开就任务客户端服务异常，从服务注册表剔除。nacos服务端启动一个定时任务，每3s去查询超过20s没有发送数据的连接，然后发送一个请求如果不通或者无响应就剔除服务。

nacos健康检查机制

永久实例无法通过心跳的机制来保活，所以nacos服务端启动一个健康检查定时任务向实例发送请求（2~7秒之间），检测实例是否存活，发送方式有TCP（默认）、HTTP、MYSQL。

naocs服务发现

nacos1.x版本服务发现大致分为3步

1、客户端启动的时候会去构建一个PushReceiver类，这个类会创建一个UDP Socket，端口是随机的，用来接收服务端推送订阅信息。

2、客户调用NamingService#subscribe发起订阅的时候，先去服务端查询所有订阅的服务信息，并缓存到客户端内部缓存中，并把UDP Socket作为参数传给服务端，后续服务端服务列表发生变化就会通过UDP Socket把信息推送给客户端，客户端更新缓存服务列表信息。

3、客户端会针对本次定义启动一个不定时任务（10~60秒），从服务端查询订阅的服务实例信息然后更新内部缓存（通过版本对比是否发送了变化）。

nacos2.x版本主要是抛弃了UDP推送方式，换成了更加稳定的gRPC长连接方式推送数据，定时对比机制不定时任务由默认开启改成默认不开启。

nacos数据一致性实现

nacos服务实例责任制-当nacos是与集群的方式部署时，为了平衡服务的压力，nacos会根据某些规则让每个服务只管理一部分服务实例（注册、保活机制、健康检查），服务注册列表是存了所有的。

nacos支持AP或者CP。

AP-阿里是通过自研的Distro保证集群服务的AP，每个服务端节点是平衡状态，当接收到服务实例注册请求的时候完成自身注册表更新后还会向其它所以服务发送请求，把服务实例数据同步到其它所以节点，失败了会重试直到成功。为了保证服务端之间数据最终一致性除了重试机制外还有定时对比机制，每个服务端都会启动一个定时任务，向各个服务端发送请求告诉其它服务自己负责实例的对应版本号，如果发现谁的不是最新的就会触发同步。

CP-1.x早期版本是自己手动实现Raft算法，2.x版本后改为蚂蚁开源JRaft框架，通过算法选举出一个Leader负责读写，写操作的时候同时同步从节点，只有超过一半的从节点同步成功后主节点才认为本次写操作成功。从节点只能读不能写。