Dynamic Clients in NCache
Dynamic clients are an important part of the NCache distributed caching architecture. They allow application servers to connect to an NCache cluster at runtime without requiring the cache cluster or other client applications to stop.
A dynamic client is any application node that uses the NCache client API to connect to a clustered cache. Once connected, the client receives cluster membership, caching topology, and data distribution information from the cache cluster. This allows the client to understand which cache servers are available and how to route cache operations efficiently.
Why Dynamic Clients Are Important
In a distributed application environment, application servers may be added, removed, restarted, or scaled automatically. For example, web servers may be added behind a load balancer, containers may restart, or cloud instances may scale up and down.
Dynamic clients help support these environments by allowing client applications to join or leave the cache cluster connectivity model without disrupting the cache or other running applications. This makes NCache suitable for environments where both cache servers and application clients need to change at runtime.
How Dynamic Clients Connect to the Cluster
When an NCache client application starts, it does not need to know every cache server in the cluster. It only needs one valid cache server address to establish the initial connection. After the client connects to that server, the cache cluster provides the required cluster information, such as the current server membership, cache topology, connection details for other cache servers, and data distribution information where applicable.
Using this information, the client can determine which cache servers it needs to connect to for cache operations. This allows the client to communicate with the cluster efficiently without requiring all server addresses to be hard-coded in the application configuration.
Runtime Client Addition
NCache allows new application clients to be added at runtime without stopping the cache cluster or restarting existing client applications. When a new client connects, it becomes part of the client connectivity layer and starts communicating with the appropriate cache servers based on the cluster and topology information it receives.
This is useful in environments where new application servers are added, web farms are scaled out, containers or pods are created dynamically, cloud auto-scaling adds new application instances, or a restarted application reconnects to the cache cluster. In all these cases, the cache cluster continues running while the new client joins and begins sending cache operations.
Runtime Client Removal
Clients can also leave the cluster connectivity layer at runtime. This may happen when an application server is shut down, a container is removed, a pod is restarted, or a cloud instance is terminated.
When a client disconnects, the cache cluster continues to serve the remaining connected clients. Existing client applications are not required to restart, and the cache itself remains available. This allows application environments to scale down or recover from client-side changes without disrupting the running cache cluster.
Topology-Aware Client Connections
Dynamic client behavior depends on the cache topology. In Partitioned and Partition-Replica topologies, data is distributed across multiple cache servers. Because of this, the client receives distribution information from the cluster and uses it to route read and write operations to the correct cache server. This avoids unnecessary network hops and helps improve performance.
In these topologies, the client connects to the active partitions on the cache servers. It does not directly connect to replica partitions for normal cache operations because replicas are synchronized by their corresponding active partitions. When a new cache server is added to the cluster, the cluster membership and distribution information are updated. Connected clients receive this updated information and can start communicating with the newly added server as part of the updated cluster topology.
Client Failover
Dynamic clients also support connection failover. If the cache server to which a client is connected becomes unavailable, the client can reconnect to another available cache server in the cluster. This helps keep application operations available during cache server failure, network interruption, planned server maintenance, or runtime cluster changes.
Client failover reduces the need for manual application intervention when a cache server becomes unavailable. The client can continue working with the cluster by using another available server connection.
Relationship with Dynamic Clustering
Dynamic clients work together with dynamic clustering. Dynamic clustering allows cache servers to be added or removed at runtime, while dynamic clients allow application nodes to receive updated cluster information and adjust their server connections accordingly.
Together, these capabilities help NCache provide a scalable and highly available distributed caching architecture. As the cache cluster changes, connected clients can update their view of the cluster and continue communicating with the appropriate cache servers.
Dynamic Clients vs Client Cache
Dynamic clients should not be confused with Client Cache. A dynamic client is an application node that connects to a clustered cache and participates in the client-side connectivity model of NCache. It represents how application nodes discover, connect to, and communicate with cache servers.
Client Cache is a separate feature that creates a local synchronized cache on the application node. It works as an L1 cache close to the application, while the clustered cache works as the L2 cache. Dynamic clients are related to cluster connectivity, whereas Client Cache is related to local data access optimization.
