Eureka缓存机制

 

Eureka Server缓存机制

Eureka Server的缓存机制依赖于谷歌的gauva cache , 在Eureka中通过

com.netflix.eureka.registry.ResponseCacheImpl , 这个操作类来实现缓存的机制。

ResponseCacheImpl

ResponseCacheImpl(EurekaServerConfig serverConfig, ServerCodecs serverCodecs, AbstractInstanceRegistry registry) {
    this.serverConfig = serverConfig;
    this.serverCodecs = serverCodecs;
    // 是否使用只读缓存
    this.shouldUseReadOnlyResponseCache = serverConfig.shouldUseReadOnlyResponseCache();
    this.registry = registry;
    // 缓存更新的时间间隔
    long responseCacheUpdateIntervalMs = serverConfig.getResponseCacheUpdateIntervalMs();
    // 构建读写缓存
    this.readWriteCacheMap =
            CacheBuilder.newBuilder().initialCapacity(1000)
                    .expireAfterWrite(serverConfig.getResponseCacheAutoExpirationInSeconds(), TimeUnit.SECONDS)
                    .removalListener(new RemovalListener<Key, Value>() {
                        @Override
                        public void onRemoval(RemovalNotification<Key, Value> notification) {
                            Key removedKey = notification.getKey();
                            if (removedKey.hasRegions()) {
                                Key cloneWithNoRegions = removedKey.cloneWithoutRegions();
                                regionSpecificKeys.remove(cloneWithNoRegions, removedKey);
                            }
                        }
                    })
                    // 缓存加载器,当缓存不存在时,会自动执行load方法,进行缓存加载。同时返回缓存数据
                    .build(new CacheLoader<Key, Value>() {
                        @Override
                        public Value load(Key key) throws Exception {
                            if (key.hasRegions()) {
                                Key cloneWithNoRegions = key.cloneWithoutRegions();
                                regionSpecificKeys.put(cloneWithNoRegions, key);
                            }
                            Value value = generatePayload(key);
                            return value;
                        }
                    });
    // 是否使用只读缓存,如果使用,此处则启动一个定时器,用来复制readWriteCacheMap 的数据至readOnlyCacheMap
    if (shouldUseReadOnlyResponseCache) {
        timer.schedule(getCacheUpdateTask(),
                new Date(((System.currentTimeMillis() / responseCacheUpdateIntervalMs) * responseCacheUpdateIntervalMs)
                        + responseCacheUpdateIntervalMs),
                responseCacheUpdateIntervalMs);
    }

    try {
        Monitors.registerObject(this);
    } catch (Throwable e) {
        logger.warn("Cannot register the JMX monitor for the InstanceRegistry", e);
    }
}

通过上面可以很简单的看出, Eureka Server的缓存是通过一个只读,一个读写缓存来实现的。

readWriteCacheMap : 此处存放的是最终的缓存, 当服务下线,过期,注册,状态变更,都会来清除这个缓存里面的数据。 然后通过CacheLoader进行缓存加载,在进行readWriteCacheMap.get(key)的时候,首先看这个缓存里面有没有该数据,如果没有则通过CacheLoader的load方法去加载,加载成功之后将数据放入缓存,同时返回数据

readOnlyCacheMap : 这是一个JVM的CurrentHashMap只读缓存,这个主要是为了供客户端获取注册信息时使用,其缓存更新,依赖于定时器的更新,通过和readWriteCacheMap 的值做对比,如果数据不一致,则以readWriteCacheMap 的数据为准。

responseCacheUpdateIntervalMs : readOnlyCacheMap 缓存更新的定时器时间间隔,默认为30秒

responseCacheAutoExpirationInSeconds : readWriteCacheMap 缓存过期时间,默认为 180 秒 。

CacheUpdateTask

readOnlyCacheMap 定时器的任务执行类。

private TimerTask getCacheUpdateTask() {
    return new TimerTask() {
        @Override
        public void run() {
            logger.debug("Updating the client cache from response cache");
            // 循环readOnlyCacheMap里面的KEY
            for (Key key : readOnlyCacheMap.keySet()) {
                if (logger.isDebugEnabled()) {
                    Object[] args = {key.getEntityType(), key.getName(), key.getVersion(), key.getType()};
                    logger.debug("Updating the client cache from response cache for key : {} {} {} {}", args);
                }
                try {
                    // 版本号
                    CurrentRequestVersion.set(key.getVersion());
                    // 从readWriteCacheMap获取数据
                    Value cacheValue = readWriteCacheMap.get(key);
                    // 当前的只读数据
                    Value currentCacheValue = readOnlyCacheMap.get(key);
                    // 判断数据是否一致
                    if (cacheValue != currentCacheValue) {
                        // 如果不一致,覆盖只读缓存里面的数据,以readWriteCacheMap为准
                        readOnlyCacheMap.put(key, cacheValue);
                    }
                } catch (Throwable th) {
                    logger.error("Error while updating the client cache from response cache", th);
                }
            }
        }
    };
}

invalidate缓存过期

public void invalidate(Key... keys) {
    // 循环传入的key一次调用API进行清除
    for (Key key : keys) {
        logger.debug("Invalidating the response cache key : {} {} {} {}, {}",
                key.getEntityType(), key.getName(), key.getVersion(), key.getType(), key.getEurekaAccept());
        // 清除缓存
        readWriteCacheMap.invalidate(key);
        Collection<Key> keysWithRegions = regionSpecificKeys.get(key);
        if (null != keysWithRegions && !keysWithRegions.isEmpty()) {
            for (Key keysWithRegion : keysWithRegions) {
                logger.debug("Invalidating the response cache key : {} {} {} {} {}",
                        key.getEntityType(), key.getName(), key.getVersion(), key.getType(), key.getEurekaAccept());
                readWriteCacheMap.invalidate(keysWithRegion);
            }
        }
    }
}

这个方法,是在服务下线, 过期,注册,状态变更的时候会调用的,从上面可以看到,这里的缓存清除只是会去清除readWriteCacheMap这个缓存, readOnlyCacheMap 只读 缓存并没有更新,也就说当客户端的信息发生变化之后, 只读缓存不是第一时间感知到的。 只读缓存的更新只能依赖那个30秒的定时任务来更新。

GET获取缓存

@VisibleForTesting
String get(final Key key, boolean useReadOnlyCache) {
    // 主要看这个getValue 
    Value payload = getValue(key, useReadOnlyCache);
    if (payload == null || payload.getPayload().equals(EMPTY_PAYLOAD)) {
        return null;
    } else {
        return payload.getPayload();
    }
}
Value getValue(final Key key, boolean useReadOnlyCache) {
    Value payload = null;
    try {
        // 是否使用只读缓存
        if (useReadOnlyCache) {
            // 从只读缓存里面获取数据
            final Value currentPayload = readOnlyCacheMap.get(key);
            if (currentPayload != null) {
                // 不为空的话,直接返回数据
                payload = currentPayload;
            } else {
                // 只读缓存里面没有,就到读写缓存里面去获取。 
                payload = readWriteCacheMap.get(key);
                // 同时将数据,放入只读缓存。
                readOnlyCacheMap.put(key, payload);
            }
        } else {
            // 不适用只读缓存
            payload = readWriteCacheMap.get(key);
        }
    } catch (Throwable t) {
        logger.error("Cannot get value for key :" + key, t);
    }
    return payload;
}

useReadOnlyCache : shouldUseReadOnlyResponseCache ,可以配置是否使用只读缓存,默认是true

readWriteCacheMap.get(key) : 这个使用的是gauva 的缓存机制,如果当前的缓存里面这个key没有,那么

会直接调用CacheLoader.load()方法,从最上面的代码可以看到, load方法,主要是执行了generatePayload()

方法。

generatePayload

private Value generatePayload(Key key) {
    Stopwatch tracer = null;
    try {
        String payload;
        switch (key.getEntityType()) {
            case Application:
                boolean isRemoteRegionRequested = key.hasRegions();
                // 全量获取
                if (ALL_APPS.equals(key.getName())) {
                    // 是否是分区域获取注册表信息
                    if (isRemoteRegionRequested) {
                        tracer = serializeAllAppsWithRemoteRegionTimer.start();
                        payload = getPayLoad(key, registry.getApplicationsFromMultipleRegions(key.getRegions()));
                    } else {
                        tracer = serializeAllAppsTimer.start();
                        //调用registry.getApplications() 获取应用信息。同时调用getPayLoad进行编码
                        payload = getPayLoad(key, registry.getApplications());
                    }
                // 增量获取
                } else if (ALL_APPS_DELTA.equals(key.getName())) {
                    // 是否是分区域获取注册表信息
                    if (isRemoteRegionRequested) {
                        tracer = serializeDeltaAppsWithRemoteRegionTimer.start();
                        versionDeltaWithRegions.incrementAndGet();
                        versionDeltaWithRegionsLegacy.incrementAndGet();
                        payload = getPayLoad(key,
                                registry.getApplicationDeltasFromMultipleRegions(key.getRegions()));
                    } else {
                        tracer = serializeDeltaAppsTimer.start();
                        // 设置增量获取的版本号
                        versionDelta.incrementAndGet();
                        // 这个暂时没有地方看到使用
                        versionDeltaLegacy.incrementAndGet();
                        // 调用registry.getApplicationDeltas() 获取增量注册信息
                        payload = getPayLoad(key, registry.getApplicationDeltas());
                    }
                } else {
                    // 根据key直接获取注册信息
                    tracer = serializeOneApptimer.start();
                    payload = getPayLoad(key, registry.getApplication(key.getName()));
                }
                break;
            // 根据VIP获取
            case VIP:
            case SVIP:
                tracer = serializeViptimer.start();
                payload = getPayLoad(key, getApplicationsForVip(key, registry));
                break;
            default:
                logger.error("Unidentified entity type: " + key.getEntityType() + " found in the cache key.");
                payload = "";
                break;
        }
        return new Value(payload);
    } finally {
        if (tracer != null) {
            tracer.stop();
        }
    }
}
// 编码类
private String getPayLoad(Key key, Applications apps) {
    EncoderWrapper encoderWrapper = serverCodecs.getEncoder(key.getType(), key.getEurekaAccept());
    String result;
    try {
        result = encoderWrapper.encode(apps);
    } catch (Exception e) {
        logger.error("Failed to encode the payload for all apps", e);
        return "";
    }
    if(logger.isDebugEnabled()) {
        logger.debug("New application cache entry {} with apps hashcode {}", key.toStringCompact(), apps.getAppsHashCode());
    }
    return result;
}

entityType : 分为三种,Application, VIP, SVIP , 客户端获取注册信息的话,传入的主要是Application类型的,另外两种类型此处不做考虑 。

根据KEY_NAME 的不同,判断是全量获取信息,还是增量获取信息,由此执行不同的逻辑,想看全量获取和增量获取是怎么实现的可以看7. Eureka 获取注册信息(七)

Eureka Client缓存机制

Eureka Client缓存机制很简单,设置了一个每30秒执行一次的定时任务,定时去服务端获取注册信息。获取之后,存入本地内存。

具体的获取规则可以看7. Eureka 获取注册信息(七)

<think>好的,用户现在想了解Eureka的保护机制及其工作原理。根据用户提供的引用内容,我需要整理这些信息,并结合之前的回答,给出一个清晰的解释。首先,我需要确认用户提到的几个引用内容之间的关系,以及如何将它们整合到回答中。 用户提供的引用1到5主要涉及Eureka的核心概念、自我保护机制、集群原理、心跳机制以及配置方法。特别是引用2、3、5详细说明了自我保护机制的开启与关闭、工作原理以及相关代码实现。用户的问题集中在保护机制如何工作及其原理,所以需要重点围绕这些方面展开。 首先,我应该从自我保护机制的定义开始,说明其目的,比如防止因网络问题导致服务被错误注销。然后,结合引用3提到的,当Eureka Server节点在短时间内丢失过多客户端心跳时,会触发自我保护模式,此时不会删除服务注册信息。需要解释触发条件和进入保护模式后的行为。 接下来,需要详细说明心跳机制与自我保护的关系,引用3和5提到Eureka Server通过心跳来判断服务是否存活,如果心跳失败比例超过阈值,则触发保护。这里需要明确阈值计算方式,比如每分钟的心跳续约次数,默认是15分钟内低于85%则触发。 然后,结合引用5中的代码片段,说明Eureka Server初始化的过程,特别是初始化上下文时如何开启流量接收,这可能与保护机制的启动有关。这部分可能需要更深入的技术细节,比如Eureka Server的配置类和相关方法。 用户可能还关心如何配置自我保护机制,引用2和3提到在配置文件中设置enable-self-preservation参数,可以开启或关闭该机制。需要提醒用户在生产环境中不建议关闭,并解释原因,如引用3提到的网络恢复后自动退出保护模式,保障稳定性。 此外,引用1和4提到Eureka作为服务注册与发现的工具,分为Server和Client,保护机制属于Server端的重要功能,确保注册中心的稳定性和高可用性。需要强调自我保护机制在集群中的作用,比如在集群环境下,各节点同步数据,保护机制如何协调工作。 还要考虑用户可能的疑问,比如保护机制开启后,服务是否还能注册或注销,引用3指出保护模式下不会注销服务,但新服务仍可以注册。同时,客户端缓存服务列表,即使Server进入保护模式,客户端仍能使用旧列表进行调用,避免整个系统崩溃。 最后,需要总结自我保护机制的设计哲学,如引用3提到的“宁可保留所有服务”的理念,确保在网络不稳定时系统的健壮性。同时,对比关闭保护机制的风险,强调默认开启的重要性。 在整理过程中,要注意引用正确的来源,使用用户提供的引用编号,比如[^3]、[^5]等,确保信息准确。同时,保持回答结构清晰,分点阐述触发条件、核心原理、行为变化、设计哲学和配置建议,帮助用户逐步理解。 可能还需要预判用户的后续问题,比如如何监控自我保护状态,或如何处理保护模式下的服务故障,但根据当前问题,先集中在工作原理上。需要避免过于技术化的术语,用易懂的语言解释机制,并结合实际场景说明其重要性。 总之,整合所有引用信息,按照逻辑顺序分步骤解释自我保护机制的工作原理,确保回答全面且符合用户需求。</think>根据提供的引用资料和Eureka的设计原理,我将从**3个核心维度**解析保护机制的工作原理,并配合流程图说明运行机制: --- ### **一、自我保护机制触发条件** #### **1. 心跳健康度检测** - **计算公式**: $$ 心跳丢失率 = \frac{最近15分钟丢失心跳数}{预期心跳总数} $$ 当丢失率超过阈值(默认15分钟内低于85%心跳)时触发保护[^3][^5] - **动态阈值算法**: ```java // Eureka-Server源码中的计算逻辑 protected boolean isLeaseExpirationEnabled() { return numberOfRenewsPerMinThreshold > 0 && getNumOfRenewsInLastMin() > numberOfRenewsPerMinThreshold; } ``` 其中`numberOfRenewsPerMinThreshold`根据注册服务数量动态计算[^5] #### **2. 网络分区感知** 当同时满足以下条件时判定为网络分区: 1. 当前存活实例数 > 预期最小存活数(默认0) 2. 心跳续约率 < 保护阈值(默认0.85) --- ### **二、保护模式核心行为** #### **1. 注册表冻结** | 正常模式 | 保护模式 | |-------------------------|-------------------------| | 定期清理超时实例(默认90秒) | 停止清理所有实例 | | 新实例可正常注册 | 新实例仍然接受注册 | | 客户端获取实时服务列表 | 客户端使用缓存列表[^1] | #### **2. 客户端应对策略** 1. 客户端本地缓存服务列表(默认每30秒更新) 2. Ribbon负载均衡器使用增量更新策略 3. 客户端定时重试心跳检测(默认间隔30秒) --- ### **三、退出保护机制流程** ```mermaid graph TD A[网络恢复] --> B{连续5分钟<br>心跳达标} B -- Yes --> C[自动关闭保护模式] C --> D[清理过期实例] B -- No --> E[维持保护状态] ``` --- ### **四、配置建议与注意事项** #### **1. 生产环境最佳实践** ```yaml # 推荐配置(application.yml) eureka: server: renewal-percent-threshold: 0.85 # 触发阈值 enable-self-preservation: true # 必须开启 eviction-interval-timer-in-ms: 60000 # 清理间隔 instance: lease-expiration-duration-in-seconds: 90 # 客户端心跳超时时间 ``` #### **2. 风险规避方案** - **服务雪崩预防**:配合Hystrix熔断机制使用 - **监控指标**: - `eureka.server.numOfRenewsInLastMin`(最近一分钟续约数) - `eureka.server.peerInstancesTransferSize`(集群同步数据量) --- ### **五、设计哲学解析** 1. **CAP原则取舍**:选择AP模式(高可用+分区容忍),放弃强一致性[^1] 2. **Fail-Safe设计**:宁可保留过期实例,也不丢失可能存活的实例[^3] 3. **双层容错机制**: - 客户端缓存(Client Side Caching) - 服务端保护(Server Side Preservation) --- ### **六、特殊场景处理** #### **1. 集群环境下的保护机制** ```java // Eureka Server集群同步代码片段 public void register(InstanceInfo info) { // 本地注册 registry.register(info, false); // 向其他节点复制 replicateToPeers(Action.Register, info.getAppName(), info.getId(), info, null, isReplication); } ``` 即使单个节点进入保护模式,集群仍可通过节点间数据同步保持可用性[^4] #### **2. 混合云场景** 当跨云网络出现分区时: 1. 每个区域的Eureka集群独立进入保护模式 2. 前端负载均衡器(如AWS ALB)切换流量到健康区域 3. 区域恢复后通过`/v2/peerreplication`端点重建数据 --相关问题-- 1. 如何监控Eureka自我保护机制的触发状态? 2. 在Kubernetes环境中如何优化Eureka保护机制? 3. Eureka与Nacos在服务保护机制上有哪些本质区别?
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值