Struct fred::types::RedisConfig

pub struct RedisConfig {
    pub fail_fast: bool,
    pub blocking: Blocking,
    pub username: Option<String>,
    pub password: Option<String>,
    pub server: ServerConfig,
    pub version: RespVersion,
    pub database: Option<u8>,
    pub tls: Option<TlsConfig>,
    pub tracing: TracingConfig,
    pub mocks: Option<Arc<dyn Mocks>>,
}

Configuration options for a RedisClient.

Fields

fail_fast: bool

Whether the client should return an error if it cannot connect to the server the first time when being initialized. If false the client will run the reconnect logic if it cannot connect to the server the first time, but if true the client will return initial connection errors to the caller immediately.

Normally the reconnection logic only applies to connections that close unexpectedly, but this flag can apply the same logic to the first connection as it is being created.

Callers should use caution setting this to false since it can make debugging configuration issues more difficult.

Default: true

blocking: Blocking

The default behavior of the client when a command is sent while the connection is blocked on a blocking command.

Setting this to anything other than Blocking::Block incurs a small performance penalty.

Default: Blocking::Block

username: Option<String>

An optional ACL username for the client to use when authenticating. If ACL rules are not configured this should be None.

Default: None

password: Option<String>

An optional password for the client to use when authenticating.

Default: None

server: ServerConfig

Connection configuration for the server(s).

Default: Centralized(localhost, 6379)

version: RespVersion

The protocol version to use when communicating with the server(s).

If RESP3 is specified the client will automatically use HELLO when authenticating. This requires Redis >=6.0.0. If the HELLO command fails this will prevent the client from connecting. Callers should set this to RESP2 and use HELLO manually to fall back to RESP2 if needed.

Note: upgrading an existing codebase from RESP2 to RESP3 may require changing certain type signatures. RESP3 has a slightly different type system than RESP2.

Default: RESP2

database: Option<u8>

An optional database number that the client will automatically SELECT after connecting or reconnecting.

It is recommended that callers use this field instead of putting a select() call inside the on_reconnect block, if possible. Commands that were in-flight when the connection closed will retry before anything inside the on_reconnect block.

Default: None

tls: Option<TlsConfig>

Available on crate features enable-native-tls or enable-rustls only.

TLS configuration options.

Default: None

tracing: TracingConfig

Available on crate feature partial-tracing only.

Tracing configuration options.

mocks: Option<Arc<dyn Mocks>>

Available on crate feature mocks only.

An optional mocking layer to intercept and process commands.

Default: None

Implementations

impl RedisConfig

pub fn uses_tls(&self) -> bool

Whether the client uses TLS.

pub fn uses_native_tls(&self) -> bool

Whether the client uses a native-tls connector.

pub fn uses_rustls(&self) -> bool

Whether the client uses a rustls connector.

pub fn from_url(url: &str) -> Result<RedisConfig, RedisError>

Parse a URL string into a RedisConfig.

URL Syntax

Centralized

redis|rediss :// [[username:]password@] host [:port][/database]

Clustered

redis|rediss[-cluster] :// [[username:]password@] host [:port][?[node=host1:port1][&node=host2:port2][&node=hostN:portN]]

Sentinel

redis|rediss[-sentinel] :// [[username1:]password1@] host [:port][/database][?[node=host1:port1][&node=host2:port2][&node=hostN:portN]
                            [&sentinelServiceName=myservice][&sentinelUsername=username2][&sentinelPassword=password2]]

Schemes

This function will use the URL scheme to determine which server type the caller is using. Valid schemes include:

• redis - TCP connected to a centralized server.
• rediss - TLS connected to a centralized server.
• redis-cluster - TCP connected to a cluster.
• rediss-cluster - TLS connected to a cluster.
• redis-sentinel - TCP connected to a centralized server behind a sentinel layer.
• rediss-sentinel - TLS connected to a centralized server behind a sentinel layer.

The rediss scheme prefix requires the enable-native-tls or enable-rustls feature.

Query Parameters

In some cases it’s necessary to specify multiple node hostname/port tuples (with a cluster or sentinel layer for example). The following query parameters may also be used in their respective contexts:

• node - Specify another node in the topology. In a cluster this would refer to any other known cluster node. In the context of a Redis sentinel layer this refers to a known sentinel node. Multiple node parameters may be used in a URL.
• sentinelServiceName - Specify the name of the sentinel service. This is required when using the redis-sentinel scheme.
• sentinelUsername - Specify the username to use when connecting to a sentinel node. This requires the sentinel-auth feature and allows the caller to use different credentials for sentinel nodes vs the actual Redis server. The username part of the URL immediately following the scheme will refer to the username used when connecting to the backing Redis server.
• sentinelPassword - Specify the password to use when connecting to a sentinel node. This requires the sentinel-auth feature and allows the caller to use different credentials for sentinel nodes vs the actual Redis server. The password part of the URL immediately following the scheme will refer to the password used when connecting to the backing Redis server.

See the from_url_centralized, from_url_clustered, and from_url_sentinel for more information. Or see the RedisConfig unit tests for examples.

pub fn from_url_centralized(url: &str) -> Result<RedisConfig, RedisError>

Create a centralized RedisConfig struct from a URL.

redis://username:password@foo.com:6379/1
rediss://username:password@foo.com:6379/1
redis://foo.com:6379/1
redis://foo.com
// ... etc

This function is very similar to from_url, but it adds a layer of validation for configuration parameters that are only relevant to a centralized server.

For example:

• A database can be defined in the path section.
• The port field is optional in this context. If it is not specified then 6379 will be used.
• Any node or sentinel query parameters will be ignored.

pub fn from_url_clustered(url: &str) -> Result<RedisConfig, RedisError>

Create a clustered RedisConfig struct from a URL.

redis-cluster://username:password@foo.com:30001?node=bar.com:30002&node=baz.com:30003
rediss-cluster://username:password@foo.com:30001?node=bar.com:30002&node=baz.com:30003
rediss://foo.com:30001?node=bar.com:30002&node=baz.com:30003
redis://foo.com:30001
// ... etc

This function is very similar to from_url, but it adds a layer of validation for configuration parameters that are only relevant to a clustered deployment.

For example:

• The -cluster suffix in the scheme is optional when using this function directly.
• Any database defined in the path section will be ignored.
• The port field is required in this context alongside any hostname.
• Any node query parameters will be used to find other known cluster nodes.
• Any sentinel query parameters will be ignored.

pub fn from_url_sentinel(url: &str) -> Result<RedisConfig, RedisError>

Create a sentinel RedisConfig struct from a URL.

redis-sentinel://username:password@foo.com:6379/1?sentinelServiceName=fakename&node=foo.com:30001&node=bar.com:30002
rediss-sentinel://username:password@foo.com:6379/0?sentinelServiceName=fakename&node=foo.com:30001&node=bar.com:30002
redis://foo.com:6379?sentinelServiceName=fakename
rediss://foo.com:6379/1?sentinelServiceName=fakename
// ... etc

This function is very similar to from_url, but it adds a layer of validation for configuration parameters that are only relevant to a sentinel deployment.

For example:

• The -sentinel suffix in the scheme is optional when using this function directly.
• A database can be defined in the path section.
• The port field is optional following the first hostname (26379 will be used if undefined), but required within any node query parameters.
• Any node query parameters will be used to find other known sentinel nodes.
• The sentinelServiceName query parameter is required.
• Depending on the cargo features used other sentinel query parameters may be used.

This particular function is more complex than the others when the sentinel-auth feature is used. For example, to declare a config that uses different credentials for the sentinel nodes vs the backing Redis servers:

redis-sentinel://username1:password1@foo.com:26379/1?sentinelServiceName=fakename&sentinelUsername=username2&sentinelPassword=password2&node=bar.com:26379&node=baz.com:26380

The above example will use ("username1", "password1") when authenticating to the backing Redis servers, and ("username2", "password2") when initially connecting to the sentinel nodes. Additionally, all 3 addresses (foo.com:26379, bar.com:26379, baz.com:26380) specify known sentinel nodes.

Trait Implementations

impl Clone for RedisConfig

fn clone(&self) -> RedisConfig

Returns a copy of the value.

fn clone_from(&mut self, source: &Self)

Performs copy-assignment from source.

impl Debug for RedisConfig

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.

impl Default for RedisConfig

fn default() -> Self

Returns the “default value” for a type.

impl PartialEq for RedisConfig

fn eq(&self, other: &Self) -> bool

This method tests for self and other values to be equal, and is used by ==.

fn ne(&self, other: &Rhs) -> bool

This method tests for !=. The default implementation is almost always sufficient, and should not be overridden without very good reason.

impl Eq for RedisConfig