面试--Eurake

secaiyingzi

已于 2024-10-06 11:25:24 修改

阅读量629

点赞数 3

文章标签：面试 eureka

于 2024-10-06 10:57:46 首次发布

本文链接：https://blog.csdn.net/secaiyingzi/article/details/142723829

版权

1.Euraka的注册原理

1.首先在应用启动时，系统会读取Euraka的相关配置，从而加载Euraka所配置的相关信息，以保证后续注册使用。
2.接着去加载自身配置信息，并且封装成Euraka客户端实例，并且将此实例发送给Euraka服务端。
3.然后获取Euraka服务端的注册信息，缓存至本地服务中。
4.最后将自身实例注册到Euraka注册中心内。
5.从上一步结束其实就已经是Euraka的注册流程了，但是成功注册之后，还会存在一个续约的情况，因为客户端和服务端需要频繁去获知对方是否可用；这里就牵扯到Euraka的服务续约功能了。
6.Euraka客户端还会定时的获取Euraka注册中心的注册信息，以保证本地注册信息与服务端一致度；这里就是获取注册信息功能了。
7.当Euraka客户端需要销毁当前实例时，需要执行内部代码块方可在Euraka注册中心内进行消除；这里说的就是服务下线功能。
8.在发生状况下，当服务提供方连续一段时间（这个时间默认是90s，但是可以自行设置）没有向注册中心进行续约操作时，注册中心会将该服务从服务注册列表中剔除；这里就是服务剔除功能。

服务注册

Euraka客户端向Euraka注册中心提供ip、port等一系列基础信息，以注册至注册中心。

服务续约

Euraka提供了一个心跳监测的功能，Euraka客户端通过定期的心跳时间，与注册中心进行一个续约操作，这个时间默认为30s，Euraka也提供了相关的配置项来供开发者配置。

服务剔除

若超过90s时间没有进行续约操作，则注册中心不会再保存Euraka客户端的相关信息，会进行一个剔除操作。时间默认为90s，Euraka也提供了相关的配置项来供开发者配置。

服务下线

Euraka客户端在程序关闭时向注册中心发起服务下线操作，注册中心接到通知，会将其所有信息删除，但是这个服务下线操作需要开发者自行编写代码进行调用。

获取注册信息

获取注册信息就比较好理解了，Euraka各实例都会在需要的时候想注册中心发起请求，注册中心也会反馈给实例当前所有的注册信息。

2.自我保护机制

自我保护模式正是一种针对网络异常波动时的安全保护措施，使用自我保护模式能使Eureka集群更加健壮稳定的运行。

自我保护模式的工作机制

如果15分钟内超过85%的客户端节点都没有正常的心跳，那么Eureka Server就会认为客户端与注册中心发生了网络故障，Eureka Server进入自我保护机制。

自我保护机制的缺点

如果在自我保护机制中，刚好某些服务节点非正常下线，但是Eureka Server并不会剔除该服务节点，服务消费者就会获取到一个无效的服务实例。

解决方案

① ：关闭自我保护机制(不推荐)
② ：切换请求或断路器，使用负载均衡的方式，设置当一个请求超过多少秒还未得到响应，速度切换请求到下一个注册服务，例如使用Ribbon+Hystrix配置负载均衡和断路器。

Eureka Server 进入自我保护机制后

1、Eureka Server不在从注册表中剔除因为长时间没有和注册中心续约的服务节点
2、Eureka Server仍然能够接受新服务的注册和查询请求，但是不会同步到其他Eureka Server节点上
3、网络正常后，当前Eureka Server节点会将新的服务节点信息同步到其他Eureka Server节点上

解除自我保护机制

1.当服务的网络分区故障解除之后，客户端能够和服务进行交互时，在续约的时候，更新每分钟的续约数，当每分钟的续约数大于85%时，则自动解除。
2.重启服务

3.Eureka 的多级缓存机制

Eureka Server 为了避免同事读取内存数据造成的并发冲突问题，采用了多级缓存机制提升服务请求的响应速度。
Eureka Server的缓存是通过一个只读，一个读写缓存来实现的。
一级缓存：concurrentHashMap<key,value>readOnlyCacheMap本质是HashMap，无过期时间，保存数据信息对外输出。readOnlyCacheMap依赖于定时器的更新，通过与readWriteCacheMap的值做对比，以readWriteCacheMap为准。readOnlyCacheMap缓存更新间隔，默认30s
二级缓存：LoaDing<key,value>readWriteCacheMap本质是Guava缓存，包含失效机制，保护数据信息对外输出。readWriteCacheMap 缓存过期时间，默认180s。

当服务节点发生注册，下线，过期，状态变更等变化时

1.在内存中更新注册表信息
2.同时过期掉readWriteCacheMap缓存，缓存清除只是会去清除readWriteCacheMap这个缓存， readOnlyCacheMap 只读缓存并没有更新，也就说当客户端的信息发生变化之后，只读缓存不是第一时间感知到的。只读缓存的更新只能依赖那个30秒的定时任务来更新。
3.一段时间后（默认30s），后台线程发现readWriteCacheMap缓存为空，于是也将readOnlyCacheMap中的缓存清空
4.当有服务消费者拉取注册表信息时，会调用ClassLoader的load方法，将内存中的注册表信息加载到各级缓存中，并返回注册表信息。
在Eureka Server 中会有两个线程，一个是定时同步两个缓存的数据，默认30s，一个是定时检测心跳故障，默认90s。

服务拉取

1.服务消费者，默认每30s，拉取注册表信息
2.从readOnlyCacheMap中获取信息，如果获取为空
3.从readWriteCacheMap中获取，如果还是为空
4.调用ClassLoader的load方法，将内存中的注册表信息加载到各级缓存中，并返回注册表信息。

4.集群怎么保持数据一致

对等复制

就是 Peer to Peer 模式，副本间不分主从，任何副本都可以接收写操作，然后每个副本间互相进行数据更新。
对等复制模式，任何副本都可以接收写请求，不存在写压力瓶颈，但各个副本间数据同步时可能产生数据冲突。

同步过程

1.Eureka Server 本身依赖了 Eureka Client，也就是每个 Eureka Server 是作为其他 Eureka Server 的 Client。
2.Eureka Server 启动后，会通过 Eureka Client 请求其他 Eureka Server 节点中的一个节点，获取注册的服务信息，然后复制到其他 peer 节点。
3.Eureka Server 每当自己的信息变更后，例如 Client 向自己发起注册、续约、注销请求，就会把自己的最新信息通知给其他 Eureka Server，保持数据同步。

避免死循环

Eureka Server 在执行复制操作的时候，使用 HEADER_REPLICATION 这个 http header 来区分普通应用实例的正常请求，说明这是一个复制请求，这样其他 peer 节点收到请求时，就不会再对其进行复制操作，从而避免死循环。

数据冲突

还有一个问题，就是数据冲突，比如 server A 向 server B 发起同步请求，如果 A 的数据比 B 的还旧，B 不可能接受 A 的数据，那么 B 是如何知道 A 的数据是旧的呢？这时 A 又应该怎么办呢？
数据的新旧一般是通过版本号来定义的，Eureka 是通过 lastDirtyTimestamp 这个类似版本号的属性来实现的。
lastDirtyTimestamp 是注册中心里面服务实例的一个属性，表示此服务实例最近一次变更时间。