9268 commented on PR #12867: URL: https://github.com/apache/apisix/pull/12867#issuecomment-4151796956
> Hi @9268, thank you for optimizing the Nacos discovery with privileged agent and LRU cache! > > Running Nacos discovery only in the privileged agent (rather than all workers) is a smart optimization that reduces redundant API calls. With 9 reviews already, this seems well-discussed. > > **To move forward**: > > 1. Please confirm all 9 review comments have been addressed > 2. Does the LRU cache properly handle Nacos service updates? What's the cache invalidation strategy? > 3. Any performance benchmarks showing the reduction in Nacos API calls? > > This looks like a solid optimization. Let's get it to merge-ready! Thank you. Overall, a two-level cache architecture is adopted: Nacos API → (periodic pull) → nacos_dict (shared memory) → nodes_lrucache (worker-local) The invalidation strategy is version-driven: 1. On write (fetch_from_host): After each pull, calculate the CRC32 of the node list using ngx.crc32_long(content) as the version number, and write to key#version. If the node content remains unchanged, the version number stays the same. 2. On read (_M.nodes): First retrieve key#version from nacos_dict, then pass it as the version parameter to nodes_lrucache(key, nodes_version, ...). The LRU cache internally compares the version number; if the version number changes, the local cache is automatically invalidated and reloaded from nacos_dict. 3. On service decommissioning: At the end of fetch_from_host, compare curr_service_in_use, delete the key and key#version of services that are no longer in use. The next _M.nodes call will not find the version number and will fall back to returning nil. LRU's own TTL: ttl = 300 (5 minutes), count = 1024, acts as a fallback eviction mechanism. Normally, version number changes trigger invalidation earlier. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
