bzp2010 commented on code in PR #13066:
URL: https://github.com/apache/apisix/pull/13066#discussion_r2923099333
##########
apisix/discovery/consul/init.lua:
##########
@@ -66,53 +73,85 @@ local _M = {
}
-local function discovery_consul_callback(data, event, source, pid)
- all_services = data
- log.notice("update local variable all_services, event is: ", event,
- "source: ", source, "server pid:", pid,
- ", all services: ", json_delay_encode(all_services, true))
-end
-
-
function _M.all_nodes()
- return all_services
+ local keys = consul_dict:get_keys(0)
+ local services = core.table.new(0, #keys)
+ for i, key in ipairs(keys) do
+ local value = consul_dict:get(key)
+ if value then
+ local nodes, err = core.json.decode(value)
+ if nodes then
+ services[key] = nodes
+ else
+ log.error("failed to decode nodes for service: ", key, ",
error: ", err)
+ end
+ end
+
+ if i % 100 == 0 then
+ ngx.sleep(0)
+ end
+ end
+ return services
end
function _M.nodes(service_name)
- if not all_services then
- log.error("all_services is nil, failed to fetch nodes for : ",
service_name)
- return
+ local value = consul_dict:get(service_name)
+ if not value then
Review Comment:
What I'm referring to is a unidirectional process where each layer relies on
its own TTL to control data expiration. Lower levels (privileged process,
shdict) do not proactively invalidate higher-level (lrucache) caches. As long
as the TTL is sufficiently small, changes take effect quickly. This process is
entirely controlled by hard-coded values or configuration settings.
On the fast path, JSON decoding never occurs because we never fetch the raw
JSON-encoded text from the shdict each time. We always use the already-cached
table.
If we set the lrucache TTL to 1s, service node updates will take effect
within 1 second. During this 1-second cache period, shdict is not read,
eliminating lock contention. Moreover, since the data is read and parsed from
shdict only once, JSON decoding does not occur (this is also an advantage of
the worker-level LRU cache, whose scope is confined to a single worker.
Consequently, there is no concurrency in populating the LRU cache, thereby
saving the decoding overhead for each service_name). Of course, we can also set
it to 0.1 seconds or 60 seconds—it's a balance between response speed and
overhead.
Therefore, I have never considered JSON decoding to be an issue.
--
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]
