[Feature] Service Discovery support local cache when registry is unavailable

[AlbumenJ]

Pre-check

• I am sure that all the content I provide is in English.

Search before asking

• I had searched in the issues and found no similar feature requirement.

Apache Dubbo Component

Java SDK (apache/dubbo)

Descriptions

Service Discovery support local cache when registry is unavailable

Related issues

No response

Are you willing to submit a pull request to fix on your own?

• Yes I am willing to submit a pull request on my own!

Code of Conduct

• I agree to follow this project's Code of Conduct

[finefuture]

What scenarios need this feature? In general, the registry sdk already supports local cache.

[AlbumenJ]

What scenarios need this feature? In general, the registry sdk already supports local cache.

1. zookeeper not support
2. Nacos's local cache is not useful for Dubbo. Nacos will use local cache by highest priority, but Dubbo only want it as the fallback.

[FAWC438]

Hi, I am new to Dubbo community and willing to complete this task.

Is there any restriction on this issue? For example, in terms of completion time and code quality.

[AlbumenJ]

Hi, I am new to Dubbo community and willing to complete this task.

Is there any restriction on this issue? For example, in terms of completion time and code quality.

1. We have no completion time limitation
2. For code quality, we have add a lot of checkers in Github Actions and we will check it when pull request reviewing

[FAWC438]

Hi @AlbumenJ, I checked the relevant code and documentation, and I think the "local cache" mentioned in this issue actually refers to the consumer caching information such as the provider's ip:port obtained from the registry that is not down. Is that correct?

I did see the local caching function of metadata in the code, but as far as I know from reading the documentation, the metadata link maintained by Dubbo does not actually require the participation of the Service Discovery registry(Nacos or Zookeeper etc.), so does the work of this issue actually have nothing to do with metadata ?

And, regarding the implementation of local cache, since you mentioned that it will be used as a fallback solution, I think it only needs to be implemented in memory (for example, through a Map ) without the need to store it in the disk (like Nacos) , because it is a small probability event after all.

[AlbumenJ]

And, regarding the implementation of local cache, since you mentioned that it will be used as a fallback solution, I think it only needs to be implemented in memory (for example, through a Map ) without the need to store it in the disk (like Nacos) , because it is a small probability event after all.

The main purpose is to save in the disk. To prevent if registry crashed Dubbo cannot start.

[walkinggo]

And, regarding the implementation of local cache, since you mentioned that it will be used as a fallback solution, I think it only needs to be implemented in memory (for example, through a Map ) without the need to store it in the disk (like Nacos) , because it is a small probability event after all.

The main purpose is to save in the disk. To prevent if registry crashed Dubbo cannot start.

Indeed, you can use serialization interfaces to save information on the local disk. However, if users tamper with the files storing this information, it can lead to data security issues. Unauthorized changes might corrupt the data, introduce errors, or cause security vulnerabilities if sensitive data is exposed or manipulated.

[walkinggo]

Hey, I want to help too, can you provide more detailed information? For example, what is the local specific information storage location and storage form. @AlbumenJ