Shulou(Shulou.com)06/01 Report--

Today, I will talk to you about how to parse the Eureka caching mechanism, which may not be well understood by many people. in order to make you understand better, the editor has summarized the following for you. I hope you can get something from this article.

Introduction

Eureka is an open source service from Netflix for service registration and discovery. Spring Cloud Eureka is repackaged based on Eureka, which adds a more user-friendly UI and is more convenient to use. However, due to the existence of too much cache in Eureka itself, the update of service status lags behind. The most common situation is that the status of the service is not updated in time after the service is offline, and the request fails when the service consumer calls the offline service. Based on Spring Cloud Eureka 1.4.4.RELEASE, the caching mechanism of Eureka is introduced under the premise of default region and zone.

AP characteristics

From the perspective of CAP theory, Eureka is an AP system, which gives priority to ensuring availability (A) and partition fault tolerance (P), not strong consistency (C), but only final consistency, so more caches are designed in the architecture.

(Eureka High availability Architecture)

Service statu

Eureka service status enum class: com.netflix.appinfo.InstanceInfo.InstanceStatus

Status description status description UP online OUT_OF_SERVICE failure DOWN offline UNKNOWN unknown STARTING is starting

Eureka Server

In Eureka high availability architecture, Eureka Server can also be registered with other server as Client. Multiple nodes register with each other to form an Eureka cluster, and the clusters are regarded as peer to each other. When Eureka Client registers, renews and updates status with Server, the receiving node updates its service registration information and synchronizes to other peer nodes one by one.

[note] if server-A registers with the server-B node one-way, server-A regards server-B as a peer node, and the data accepted by server-A will be synchronized to server-B, but the data accepted by server-B will not be synchronized to server-A.

Caching mechanism

There are three variables in Eureka Server: (registry, readWriteCacheMap, readOnlyCacheMap) save service registration information. By default, scheduled tasks synchronize readWriteCacheMap to readOnlyCacheMap every 30s, clean up nodes that have not been renewed for more than 90s every 60s, Eureka Client updates service registration information from readOnlyCacheMap every 30s, and UI updates service registration information from registry.

Three-level cache

Cache type description registryConcurrentHashMap real-time update, class AbstractInstanceRegistry member variable, UI side request is here service registration information readWriteCacheMapGuava Cache/LoadingCache real-time update, class ResponseCacheImpl member variable, cache time 180s readOnlyCacheMapConcurrentHashMap cycle update, class ResponseCacheImpl member variable, default every 30s from readWriteCacheMap update, Eureka client default update service registration information from here, can be configured to update directly from readWriteCacheMap

Cache related configuration

Configuration default indicates that eureka.server.useReadOnlyResponseCachetrueClient updates data from readOnlyCacheMap, while false skips readOnlyCacheMap update eureka.server.responsecCacheUpdateIntervalMs30000readWriteCacheMap update directly from readWriteCacheMap to readOnlyCacheMap cycle, default 30seureka.server.evictionIntervalTimerInMs60000 cleanup unrenewed node (evict) cycle, default 60seureka.instance.leaseExpirationDurationInSeconds90 cleanup unrenewed node timeout, default 90s

Key class

The class name indicates that com.netflix.eureka.registry.AbstractInstanceRegistry holds the service registration information, holds registry and responseCache member variables com.netflix.eureka.registry.ResponseCacheImpl, holds readWriteCacheMap and readOnlyCacheMap member variables Eureka Client

Eureka Client has two roles: service provider and service consumer, who are generally used in conjunction with Ribbon or Feign (Feign uses Ribbon internally) as a service consumer. Immediately after Eureka Client starts, it registers with Server as a service provider and renews its contract every 30s by default (renew); as a service consumer, it immediately updates the service registration information to Server, and by default updates the service registration information every 30s; Ribbon delays 1s to get the service registration information used from Client. By default, the service registration information used is updated every 30s, and only services with a status of UP are saved.

Second-level cache

Cache type description: localRegionAppsAtomicReference periodic update, class DiscoveryClient member variable, Eureka Client saves service registration information, immediately after startup, full update to Server, default every 30s incremental update upServerListZoneMapConcurrentHashMap cycle update, class LoadBalancerStats member variable, Ribbon saves service registration information used and status is UP, delay 1s after startup to update Client, default every 30s update

Cache related configuration

Configure default description eureka.instance.leaseRenewalIntervalInSeconds30Eureka Client renewal cycle, default 30seureka.client.registryFetchIntervalSeconds30Eureka Client incremental update cycle, default 30s (full update under normal incremental update, timeout or inconsistent with Server side, etc.) ribbon.ServerListRefreshInterval30000Ribbon update cycle, default 30s

Key class

The class name states that com.netflix.discovery.DiscoveryClientEureka Client is responsible for registration, renewal and update. The method initScheduledTasks () initializes the renewal and updates the scheduled task com.netflix.loadbalancer.PollingServerListUpdaterRibbon updates the service registration information, respectively, and start initializes the update scheduled task com.netflix.loadbalancer.LoadBalancerStatsRibbon. Save the service registration information with the status of UP under the default configuration, the maximum perceived time of service consumers Eureka Client time indicates that 30 (readOnly) + 30 (Client) + 30 (Ribbon) = 90sreadWrite-> readOnly-> Client-> Ribbon each 30s normal offline 30 (readonly) + 30 (Client) + 30 (Ribbon) = 90s service normal offline (kill or kill-15 kill process) will give the process a chance to clean up. DiscoveryClient.shutdown () will update its status to DOWN to Server. Then send DELETE request to log off yourself, registry and readWriteCacheMap real-time update, so UI will no longer show the service instance abnormal offline 30,60,30,30,30,30,240s (kill-9 kills the process or crashes) will not trigger the DiscoveryClient.shutdown () method, Eureka Server will rely on cleaning every 60s for more than 90s unrenewed service to delete the service instance from registry and readWriteCacheMap

Consider the following situation

In 0s, the service goes offline without notifying Eureka Client.

At 29s, the first expiration check evict is not more than 90s.

At 89s, the second expiration check evict does not exceed 90s.

The third expiration check at 149s indicates that evict has not renewed its contract for more than 90s, so the service instance is deleted from registry and readWriteCacheMap.

179s timing task updated from readWriteCacheMap to readOnlyCacheMap

Update Eureka Client from readOnlyCacheMap of Eureka Server at 209s

Ribbon is updated from Eureka Client at 239s.

Therefore, in the extreme case, the longest perception time of service consumers will be infinitely close to 240s.

Response measures

When choosing to use Eureka, the service registry indicates that it has accepted its characteristics of priority guaranteed availability (A), partition fault tolerance (P) and strong consistency (C). If you need to give priority to strong consistency (C), you should consider using a CP system such as ZooKeeper as a service registry. Multi-nodes are generally configured in distributed systems, and the lag of status update on the service of a single node has no impact. Here, we mainly consider the response measures of the lag of status update after the offline service.

Eureka Server

1. Shorten the readOnlyCacheMap update cycle. Shortening the scheduled task cycle can reduce the lag time.

Eureka.server.responsecCacheUpdateIntervalMs: 10000 # Eureka Server readOnlyCacheMap update cycle

two。 Close readOnlyCacheMap. Small and medium-sized systems can consider this option, and Eureka Client updates service registration information directly from readWriteCacheMap.

Eureka.server.useReadOnlyResponseCache: whether false # uses readOnlyCacheMapEureka Client

1. Service consumers use fault-tolerant mechanisms. For example, Spring Cloud Retry and Hystrix,Ribbon, Feign and Zuul can all be configured with Retry. Service consumers usually report ConnectTimeout when they visit an offline node. In this case, you can retry the next node through the Retry mechanism.

two。 Service consumers shorten the update cycle. Eureka Client and Ribbon secondary caches affect status updates, and shortening these two scheduled task cycles can reduce latency, such as configuration:

Eureka.client.registryFetchIntervalSeconds: 5 # Eureka Client update cycle ribbon.ServerListRefreshInterval: 2000 # Ribbon update cycle

3. The service provider ensures that the service is offline normally. Use the kill or kill-15 command when the service is offline to avoid using the kill-9 command, kill or kill-15 command to kill the process will trigger the shutdown () method of Eureka Client, actively delete the registration information in registry and readWriteCacheMap of Server, and do not have to rely on evict removal of Server.

4. The service provider has delayed going offline. Before the service goes offline, call the API to make the service status saved in Eureka Server as DOWN or OUT_OF_SERVICE, and then go offline. The time difference between the two is determined according to the cache mechanism and configuration. For example, by default, a delay of 90s after calling the API will ensure that the service consumer will not call the offline service instance.

The gateway realizes real-time awareness of service downline.

In software engineering, there is no problem that can not be solved by the middle layer, and the gateway is the middle layer between service providers and service consumers. Take the Spring Cloud Zuul gateway as an example, the gateway saves the service registration information as the Eureka Client, and the service consumer forwards the request to the service provider through the gateway. It only needs to inform the gateway to invalidate the service in the service list saved by the service provider when the service provider goes offline. In order to maintain the independence of the gateway, an independent service can be implemented to receive offline notifications and coordinate the gateway cluster.

After reading the above, do you have any further understanding of how to parse the Eureka cache mechanism? If you want to know more knowledge or related content, please follow the industry information channel, thank you for your support.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.