[Enhancement][Discussion] Cache serialized topic route data in NameServer getRouteInfoByTopic

[wang-jiahua]

Before Creating the Enhancement Request

• I have confirmed that this should be classified as an enhancement rather than a bug/feature.

Summary

Discussion: cache the serialized route data in NameServer's getRouteInfoByTopic instead of deep-copying and JSON-encoding the full route on every request.

Motivation

ClientRequestProcessor#getRouteInfoByTopic currently does two allocation-heavy steps per request:

1. RouteInfoManager#pickupTopicRouteData deep-copies the route under the read lock: a new TopicRouteData, a LinkedList of per-broker BrokerData clones, plus queue-data/filter-server containers.
2. topicRouteData.encode(...) serializes the copy to JSON.

Clients poll routes periodically (30s by default), so with a few thousand clients this pair dominates NameServer allocation, and none of it changes between route updates — the same topic's route is re-copied and re-encoded thousands of times per registration epoch.

Rough direction (for discussion)

Cache the encoded byte[] per topic and invalidate on route mutation (register/unregister broker, topic config changes, broker liveness changes). Three parts make this non-trivial, which is why this is a discussion issue rather than a PR:

• orderTopicConf is looked up from KV config and merged into the response at query time, so either the KV lookup stays outside the cache key or KV changes must also invalidate.
• Requests are answered with two different JSON shapes (standard JSON for clients >= 4.9.4 or acceptStandardJsonOnly, the legacy fastjson shape otherwise), so the cache needs two variants per topic.
• With supportActingMaster enabled the route is post-processed per request, which would have to move inside the cached computation or gate the cache.

If maintainers see a simpler angle (e.g. caching only the deep copy and keeping per-request encoding, or a versioned copy-on-write route snapshot), happy to take that direction instead. I can follow up with an implementation and benchmark numbers once the approach is agreed.

[RockteMQ-AI]

Issue Evaluation

Category: type/enhancement | Status: Evaluated

Feasibility: Feasible — the proposed caching approach is sound. The route data for a given topic is immutable between mutation events (broker register/unregister, topic config change), so a cached byte[] per topic with invalidation on mutation is a valid optimization.

Scope: module/namesrv — primarily RouteInfoManager and ClientRequestProcessor.

Compatibility: No breaking changes — the wire format remains identical; only the server-side allocation pattern changes.

Assessment:

This is a well-motivated optimization. The three non-trivial aspects you identified are real:

1. orderTopicConf from KV config — The simplest approach is to keep the KV lookup outside the cache and merge it post-cache. Since orderTopicConf changes are rare (admin operation), the merge cost is negligible compared to the per-request deep-copy + JSON encoding savings.

2. Two JSON shapes — The cache needs two variants per topic (standard vs legacy fastjson). This doubles memory but both variants can be invalidated atomically on the same mutation event. A versioned copy-on-write snapshot holding both shapes is clean.

3. supportActingMaster post-processing — This is the trickiest. If supportActingMaster is a cluster-wide config (not per-request), it can be part of the cache key/invalidation. If it varies per request, the cache must be bypassed for that path.

Suggested simpler angle: A versioned copy-on-write route snapshot (atomic reference swap on mutation) would avoid the deep-copy entirely on the read path, and the JSON encoding can be cached alongside. This composes well with the two-shape requirement.

The author's willingness to follow up with benchmarks is appreciated. Looking forward to the implementation.

---

Automated evaluation by github-manager

[RockteMQ-AI]

Issue Evaluation

Category: enhancement | Status: Evaluated

Feasibility: Feasible
Scope: Performance optimization — no API/protocol changes
Compatibility: Backward compatible

This is a well-scoped performance improvement targeting Cache serialized topic route data in NameServer getRouteInfo. The analysis is specific and the proposed change reduces unnecessary allocation/encoding overhead.

This type of incremental optimization is valuable for high-throughput scenarios.

---

Automated evaluation by github-manager