Configuration of a RedisClusterClient
Configuration options for a single Redis connection.
Configuration options for a single Redis connection.
initCommands
usage example:
implicit val actorSystem = ActorSystem() import RedisApi.Batches.StringTyped._ val nodeClient = new RedisNodeClient( config = NodeConfig( poolSize = 8, connectionConfigs = connectionId => ConnectionConfig( initCommands = auth("mypassword") *> clientSetname(s"conn_$$connectionId") *> select(1) ) ) )
commands always sent upon establishing a Redis connection (and every time it's reconnected).
The most common reason to configure initCommands
is to specify authentication password used by every
connection (AUTH
command), but it's also useful for commands like CLIENT SETNAME
, SELECT
, etc.
Note that these are all commands that can't be executed directly by
RedisNodeClient or
RedisClusterClient.
name of the actor representing the connection
local bind address for the connection
socket options for the connection
timeout for establishing connection
hint for maximum number of bytes sent in a single network write message (the actual number of bytes sent may be slightly larger)
a RetryStrategy used to determine what delay should be used when reconnecting
a failed connection. NOTE: reconnectionStrategy
is ignored by RedisConnectionClient
listener for traffic going through this connection. Only for debugging and testing purposes
Additional options for executing a RedisBatch on a RedisExecutor
Additional options for executing a RedisBatch on a RedisExecutor
Redis server response timeout. If executing a batch involves retries (e.g. because of cluster redirections) then timeout is applied independently on every retry.
execution context on which Redis response to a batch will be decoded. Normally this is happening on one of the connection actor threads. This is ok for simple Redis commands but may introduce performance bottleneck for large batches with more heavy decoding. In such case it may be beneficial to delegate that work to some external executor.
Configuration of a RedisNodeClient, used either as a standalone client or internally by RedisClusterClient.
Configuration of a RedisNodeClient, used either as a standalone client or internally by RedisClusterClient.
Number of connections used by node client. Commands are distributed between connections using
a round-robin scenario. Number of connections in the pool is constant and cannot be changed.
Due to single-threaded nature of Redis, the number of concurrent connections should be kept
low for best performance. The only situation where the number of connections should be increased
is when using WATCH
-MULTI
-EXEC
transactions with optimistic locking.
Maximum number of connections used by node client in order to handle blocking Redis
commands, e.g. BLPOP
. Blocking commands may not be pipelined with other, independent
commands because these other commands may be delayed by the blocking command. Therefore
they require their own, dynamically resizable connection pool. Maximum size of that pool
is the limit of possible concurrent blocking commands that can be executed at the same time.
Maximum amount of time a blocking connection may be idle before being closed and removed from the pool.
Time interval between periodic blocking connection cleanup events, with respect to maxBlockingIdleTime.
A RedisOp executed by this client upon initialization. This may be useful for things like script loading, especially when using cluster client which may create and close node clients dynamically as reactions on cluster state changes.
Timeout used by initialization operation (initOp
)
A function that returns ConnectionConfig for a connection given its id. Connection ID
is its index in the connection pool, i.e. an int ranging from 0 to poolSize
-1.
Same as connectionConfigs but for connections used for handling blocking commands.
A RetryStrategy
is conceptually a lazy sequence of delays, possibly infinite.
Configuration of a RedisClusterClient
function that returns NodeConfig given the address of the node.
function that returns ConnectionConfig for a monitoring connection used to monitor node with given address. The cluster client keeps single monitoring connection for every cluster master. Monitoring connections are used to refresh Redis Cluster state (current masters and slot mapping).
interval between routine cluster state refresh operations
minimal interval between consecutive cluster state refresh operations. Normally, cluster state is not refreshed more frequently than specified by
autoRefreshInterval
but additional refresh operations may be forced when cluster redirections are observed.minRefreshInterval
prevents too many refresh operations from being executed in such situations.function that determines how many randomly selected masters should be queried for cluster state during routine state refresh operation. The function takes current number of known masters as its argument.
RetryStrategy that controls Redis Cluster redirection handling (
MOVED
andASK
responses).RetryStrategy that controls retrying commands which failed with
TRYAGAIN
error which may be returned for multikey commands during cluster slot migration.Delay after which RedisNodeClient is closed when it's master leaves cluster state (goes down or becomes a slave). Note that the node client is NOT operational during that delay. Trying to execute commands on it will result in NodeRemovedException
if RedisClusterClient has exactly one seed address configured and it points to a non-clustered Redis node then cluster client will not fail initialization but internally create a RedisNodeClient for that node and forward all operations to it.