Eureka Client Incremental Registry Synchronization Mechanism
This article explains how Eureka clients periodically fetch incremental registry updates, the underlying 30‑second synchronization interval, the server’s recentlyChangedQueue data structure, the merging process of delta and full registries, and hash‑based consistency checks to ensure client‑server registry alignment.
After the initial full registry pull, a Eureka client must keep its local copy up‑to‑date when services register or deregister; repeatedly pulling the entire registry would be costly, so the client uses incremental fetching.
Incremental fetching reduces bandwidth by only retrieving changed entries, but raises questions about fetch frequency, storage of changes on the server, and how the client merges these deltas.
The default synchronization interval is 30 seconds, defined by the client.refresh.interval property. Every 30 s a background thread named cacheRefresh triggers the client to request delta updates.
The client calls the getDelta method, sending an HTTP request to the REST endpoint http://localhost:8080/v2/apps/delta . The server processes this request via its Jersey controller.
On the server side, the method getContainerDifferential gathers recent changes stored in recentlyChangedQueue , which is a ConcurrentLinkedQueue<RecentlyChangedItem> .
Each RecentlyChangedItem holds three fields: the instance information (a Lease object), an action type (ADD, UPDATE, DELETE), and the last update timestamp.
The queue is cleaned every 30 s: items older than three minutes are removed, ensuring only recent changes are kept for delta responses.
When the client receives a delta, it invokes updateDelta to merge the changes into its local registry. The merge logic iterates over each delta entry, adds new instances, updates existing ones (by deleting then adding), or removes instances based on the action type.
To verify consistency, the server returns a hash of the full registry alongside the delta. After merging, the client computes its own hash and compares the two; a mismatch triggers a full registry fetch.
Key points:
Client fetches incremental data every 30 s.
Server checks the change queue every 30 s and discards entries older than three minutes.
Delta merging handles add, update, and delete actions.
Hash comparison ensures client and server registries stay synchronized, falling back to a full fetch when needed.
Wukong Talks Architecture
Explaining distributed systems and architecture through stories. Author of the "JVM Performance Tuning in Practice" column, open-source author of "Spring Cloud in Practice PassJava", and independently developed a PMP practice quiz mini-program.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.