Nacos in Spring Cloud: Split‑Brain, Timeout, and Performance Deep Dive

Interview Question

In a Spring Cloud micro‑service architecture using Nacos as the service registry, the following problems may occur and can be mitigated as described.

Scenario 1 – Split‑brain and CAP trade‑off

Root cause : Nacos defaults to an AP model and can be switched to CP via naming.load-cache.urgently=true. A network partition splits the cluster, causing multiple leaders and inconsistent data.

Consumer impact : Stale instance lists lead to call failures.

Source‑code analysis :

CP mode uses Raft in DistroConsistencyServiceImpl with Term and LogIndex for strong consistency; manual recovery is required after split‑brain.

AP mode uses APDistroProtocol and DataSyncTask for periodic full sync, tolerating short‑term inconsistency.

Mitigation :

Production configuration:

spring:
  cloud:
    nacos:
      discovery:
        ephemeral: false   # persist instances
        fail-fast: true    # fail fast on startup

Client cache optimization:

Enable local cache with naming.load-cache.enable=true and a TTL of about 30 seconds.

Combine with Ribbon’s NIWSDiscoveryPing for health checks.

Cluster deployment:

Deploy at least three nodes across multiple availability zones.

Monitor node health via the /nacos/v1/ns/operator/servers API.

Scenario 2 – Registration timeout and retry

Root causes :

High network latency (e.g., cross‑datacenter RTT).

Thread‑pool exhaustion in NamingProxy (default core size 200).

Serialization overhead (Hessian2, large objects).

Spring Cloud Alibaba source trace :

Registration flow:

// NacosAutoServiceRegistration.java
public void start() {
    this.nacosServiceManager.registerService(...);
}

// NacosServiceManager.java
public void registerService(...) {
    namingService.registerInstance(...);
}

Timeout control:

Default client connectionTimeout=3000ms and socketTimeout=9000ms (override with spring.cloud.nacos.discovery.timeout).

On timeout the client does not retry automatically; Spring Retry or custom logic is required.

Mitigation :

Client optimization:

spring:
  cloud:
    nacos:
      discovery:
        timeout: 5000   # extend timeout
        retry:
          maxAttempts: 3
          initialInterval: 1000

Server tuning:

Adjust naming.load.thread.size (default 200) and naming.load.queue.size (default 65536).

Enable gRPC protocol (Nacos 2.x+) for up to three‑fold performance gain over HTTP.

Asynchronous registration example:

public class CachingLoadBalancerInterceptor implements ClientHttpRequestInterceptor {
    @Autowired
    private ReactiveDiscoveryClient discoveryClient;
    private final Cache<String, List<ServiceInstance>> instanceCache =
        Caffeine.newBuilder().expireAfterWrite(10, TimeUnit.SECONDS).build();

    @Override
    public Mono<ClientHttpResponse> intercept(...) {
        String serviceId = ...;
        return Mono.justOrEmpty(instanceCache.getIfPresent(serviceId))
            .switchIfEmpty(discoveryClient.getInstances(serviceId)
                .map(instances -> {
                    instanceCache.put(serviceId, instances);
                    return instances;
                }));
    }
}

Service‑mesh approach: introduce a sidecar (e.g., Spring Cloud Gateway + Nacos SDK) to centralize registry calls.

Scenario 3 – High‑concurrency instance‑list fetching bottleneck

Problem manifestation : Each request pulls the full instance list via LoadBalancerClient. At 100 k QPS the Nacos server CPU reaches ~90 %.

Root cause : Default pull mode fetches the full list on every request.

Performance comparison (100 services × 100 instances) :

Sync pull (default): client QPS 80 k, server CPU 95 %, latency 15 ms.

Local cache + periodic refresh: client QPS 120 k, server CPU 30 %, latency 2 ms.

Incremental push (Nacos 2.x): client QPS 150 k, server CPU 15 %, latency 1 ms.

Mitigation :

Enable incremental push: naming.push.receiver.enable=true (server pushes change events via UDP).

Client processes only incremental data.

Implement hierarchical cache (example code above).

Adopt sidecar‑based service mesh to reduce duplicate discovery calls.

Extended comparison – Nacos vs Eureka vs Zookeeper

Consistency model : Nacos AP (switchable to CP), Eureka AP, Zookeeper CP.

Protocol support : Nacos HTTP/gRPC, Eureka HTTP, Zookeeper TCP/ZAB.

Metadata management : Nacos supports multi‑level namespaces and groups; Eureka only application name; Zookeeper relies on ZNode paths.

High availability : Nacos provides built‑in cluster UI; Eureka requires a server cluster; Zookeeper needs external tools (e.g., Helix).

Performance (QPS) : Nacos ≈ 150 k + (with incremental push), Eureka ≈ 50 k, Zookeeper ≈ 30 k (strong consistency overhead).

Typical use case : Nacos cloud‑native microservices (Spring Cloud Alibaba); Eureka traditional microservices (Spring Cloud Netflix); Zookeeper distributed coordination (Kafka, Hadoop).