apache / apache/dubbo

When using the Redis registry and Redis Cluster, the first call is very slow

Open
#10,227 1 comment 0 reactions 0 assignees View on GitHub
type/enhancement
Dominant language
Java
Stars
41.6k
Forks
26.4k
Avg merge
15h 13m
Merged PRs (30d)
4

Description

使用redis注册中心,且redis集群是cluster模式时,泛化调用,第一次调用非常慢,都在5~10秒,当工程中有较多reference时,启动也很慢(redis 集群共6个实例)。
经过排查,时间主要花费在了redis 集群scan命令上:
org.apache.dubbo.registry.redis.RedisRegistry#doSubscribe 269行 `大部分时间都花费在了`redisClient.scan(service + PATH_SEPARATOR + ANY_VALUE)`这行代码上,进一步排查为scan命令耗时严重。

这一行代码的目的是查询出某个interface的provider和consumers key,是否可以通过组装查询是否存在来进行判断呢?代码如下:

```
Set keys = new HashSet<>();//redisClient.scan(service + PATH_SEPARATOR + ANY_VALUE);
String keyProviders = service + PATH_SEPARATOR + PROVIDERS_CATEGORY;
boolean existsProviders = redisClient.exists(keyProviders);
if (existsProviders) {
keys.add(keyProviders);
}
String keyConsumers = service + PATH_SEPARATOR + CONSUMERS_CATEGORY;
boolean existsConsumers = redisClient.exists(keyConsumers);
if (existsConsumers) {
keys.add(keyConsumers);
}
doNotify(keys, url, Collections.singletonList(listener));
```

### Environment

* Dubbo version: 2.7.15
* Operating System version: xxx
* Java version: xxx

Contributor guide

Open the contributing guide

Research direction

Start at org.apache.dubbo.registry.redis.RedisRegistry#doSubscribe around line 269 and inspect how the Redis Cluster scan finds provider and consumer keys. Compare the scan behavior with the proposed existence checks, then verify that notifications remain correct and that the slow first call and startup delay are addressed.

Written by the indexing model from the issue text.

Assessment

Tech stack
java, redis
Domain
databases, distributed-systems, performance
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
38/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.