RedisClusterClient
Related Doc:
package redis
nodes used to fetch initial cluster state from. You don't need to list all cluster nodes, it is only required that at least one of the seed nodes is available during startup.
Returns currently known cluster state.
Executes a RedisBatch on a Redis Cluster deployment.
Executes a RedisBatch on a Redis Cluster deployment. In order to determine node on which each command must be
executed, every command or MULTI-EXEC transaction in the batch must contain at least one key.
Also, in the scope of a single command or transaction all keys must hash to the same slot.
However, each command or transaction in the batch may target different slot. RedisClusterClient automatically splits the original batch and creates smaller batches, one for every master node that needs to be contacted. In other words, commands and transactions from the original batch are automatically distributed over Redis Cluster master nodes, in parallel, using a scatter-gather like manner.
RedisClusterClient also automatically retries execution of commands that fail due to cluster redirections
(MOVED and ASK)
and cluster state changes. However, remember that multi-key commands may still fail with
TRYAGAIN error during resharding of the slot targeted by the multi-key operation.
(see Redis Cluster specification).
RedisClusterClient makes no attempt to recover from these errors. It would require waiting for an
indeterminate time until the migration is finished. The maximum number of consecutive retries caused by
redirections is configured by maxRedirections.
See Redis Cluster specification for
more detailed information on redirections.
In general, you can assume that if there are no redirections involved, commands executed on the same master node are executed in the same order as specified in the original batch.
Execution of each command in the batch or the whole batch may fail due to following reasons:
MOVED or ASK redirection too many times in a row. This might indicate
misconfiguration of the Redis Cluster deployment.
Waits until cluster state is known and RedisNodeClient for every master node is initialized.
Returns currently known cluster state, waiting for initialization if necessary.
Returns a RedisNodeClient internally used to connect to a master with given address.
Returns a RedisNodeClient internally used to connect to a master with given address. Note that the address may belong to a master that is not yet known to this cluster client. In such case, node client for this master will be created on demand. However, be aware that this temporary client will be immediately closed if it's master is not listed in next cluster state fetched by RedisClusterClient. Therefore, you can't use this method to obtain clients for arbitrary nodes - only for master nodes that this cluster client knows or is about to know upon next state refresh.
This method is primarily intended to be used when having to manually recover from a cluster redirection. If you want to obtain node client serving particular hash slot, get it from currentState.
nodes used to fetch initial cluster state from.
nodes used to fetch initial cluster state from. You don't need to list all cluster nodes, it is only required that at least one of the seed nodes is available during startup.
Sets a listener that is notified every time RedisClusterClient detects a change in cluster state (slot mapping).
Redis client implementation for Redis Cluster deployments. Internally, it uses single RedisNodeClient instance for every known master in the cluster plus a separate connection for monitoring of every known master. RedisNodeClient instances are dynamically created and destroyed as the cluster changes its state.
The cluster client is only able to execute commands or transactions containing keys which determine which master should be contacted. However, it's possible to gain access to RedisNodeClient instances that RedisClusterClient internally uses to connect to every master (see ClusterState and masterClient).
RedisClusterClient can directly execute only RedisBatches. It automatically distributes every batch over multiple cluster masters and handles cluster redirections if necessary. See executeBatch for more details.
RedisClusterClient cannot directly execute RedisOps (e.g.
WATCH-MULTI-EXECtransactions). You must manually access node client for appropriate master through currentState and execute the operation using it. However, be aware that you must manually handle cluster redirections and cluster state changes while doing so.