Use key/map structure in redis to save the registration info:
Publish/Subscribe events in redis is leveraged for data change notification:
unregisterevents fired from the specified service.
psubscribe, then will receive all change notifications from all services.
unregister, it will fetch provider’s addresses from
unregister, it fetches provider’s addresses from
unsubscribe, it fetches consumer’s addresses from
<dubbo:registry address="redis://10.20.153.10:6379" />
<dubbo:registry address="redis://10.20.153.10:6379?backup=10.20.153.11:6379,10.20.153.12:6379" />
<dubbo:registry protocol="redis" address="10.20.153.10:6379" />
<dubbo:registry protocol="redis" address="10.20.153.10:6379,10.20.153.11:6379,10.20.153.12:6379" />
<dubbo:registry group="dubbo" />, the default value is
<dubbo:registry cluster="replicate" />, the default value is
failover: when read/write error happens, try another instance, require the cluster to support data replication.
replicate: client writes to all nodes of the cluster, but only peeks a random node for read. The cluster doesn’t need to take care of data replication, but may require more nodes and higher performance for each node, compared to option 1.
A home-brewed service registry server is used in Alibaba instead of redis server. Redis based registry center does not have long-run practice within Alibaba, therefore we cannot guarantee its reliability. This registry server implementation is provided for dubbo community, and its reliability relies on redis itself largely.
Pls. refer to redis install manual for how to install a redis based registry server. To set it up, specify
conf/dubbo.properties for both provider and consumer (you can refer to quick start) after install a redis server.
Was this page helpful?
Glad to hear it! Please tell us how we can improve.
Sorry to hear that. Please tell us how we can improve.