Redis Factory

Purpose and Scope

The RedisFactory class is responsible for creating and managing RedisProxy instances for named connection pools. It reads the Redis configuration during construction and eagerly instantiates a proxy for each configured pool, making them available for retrieval throughout the application lifecycle.

For information about the proxies created by this factory, see Redis Proxy. For details on the underlying connection pooling mechanism, see Connection Pooling.

Sources: src/RedisFactory.php1-38

Overview

The RedisFactory serves as a simple but essential component in the connection management architecture. Rather than creating connections directly, it creates RedisProxy instances that act as pool-specific facades to the underlying Redis class.

Key Responsibilities

Responsibility	Description
Configuration Reading	Reads redis configuration array to determine available pools
Eager Instantiation	Creates all RedisProxy instances during factory construction
Proxy Storage	Maintains an internal array of proxies indexed by pool name
Proxy Retrieval	Provides get() method to retrieve proxies with validation
Error Handling	Throws InvalidRedisProxyException for non-existent pools

Sources: src/RedisFactory.php12-37

Class Structure

Sources: src/RedisFactory.php12-37

Initialization Flow

The factory initializes during application bootstrap when the dependency injection container instantiates it. The initialization is configuration-driven and happens once per application lifecycle.

Sources: src/RedisFactory.php19-26

Constructor Implementation

The constructor follows a simple pattern: iterate through the Redis configuration and create a RedisProxy for each defined pool.

Constructor process:
1. Inject ConfigInterface dependency
2. Retrieve 'redis' configuration array
3. Iterate through each pool name in the configuration
4. Use make() helper to instantiate RedisProxy with pool name
5. Store proxy in internal array indexed by pool name

Configuration Format

The factory expects the Redis configuration to be an associative array where keys are pool names:

Sources: src/RedisFactory.php19-26

Proxy Retrieval

The get() method provides type-safe access to stored proxies with validation.

Method Signature

public function get(string $poolName): RedisProxy

Parameters:

• $poolName - The name of the configured pool to retrieve

Returns:

• RedisProxy instance associated with the pool name

Throws:

• InvalidRedisProxyException if the pool name doesn't exist or proxy is invalid

Sources: src/RedisFactory.php28-36

Storage Mechanism

The factory uses a simple associative array for proxy storage:

Field	Type	Visibility	Purpose
proxies	array	protected	Stores RedisProxy instances indexed by pool name

The @var RedisProxy[] annotation at src/RedisFactory.php15 documents the expected type, though PHP's array typing doesn't enforce this at runtime.

Sources: src/RedisFactory.php14-17

Integration with Other Components

Sources: src/RedisFactory.php1-38

Usage Examples

Retrieving a Proxy

To use the factory in application code, resolve it from the container and call get() with the desired pool name:

Example usage pattern:

1. Inject RedisFactory into service constructor
2. Call factory->get('poolName') to retrieve proxy
3. Use proxy methods to execute Redis commands

The factory is typically used by:

• DurationLimiter - Rate limiting service that needs specific Redis pools
• Custom Services - Application services requiring dedicated connection pools
• Direct Usage - When fine-grained pool control is needed

Sources: src/RedisFactory.php28-36

Exception Handling

The factory throws a single exception type for error conditions:

InvalidRedisProxyException

Thrown by get() when:

• The requested pool name doesn't exist in configuration
• The internal proxy storage contains an invalid value (non-RedisProxy instance)

This exception originates from the Hyperf framework (Hyperf\Redis\Exception\InvalidRedisProxyException) and indicates a configuration error or internal state corruption.

Sources: src/RedisFactory.php28-36

Design Considerations

Eager vs Lazy Initialization

The factory uses eager initialization - all proxies are created during construction rather than on-demand. This design choice:

Advantages:

• Fails fast if configuration is invalid
• No synchronization needed for lazy creation
• Consistent performance (no first-access penalty)
• Simple implementation

Trade-offs:

• Creates proxies for pools that may never be used
• Slightly longer bootstrap time
• Memory allocated for unused proxies

Given that RedisProxy instances are lightweight (they don't hold connections), eager initialization is appropriate for this use case.

Sources: src/RedisFactory.php19-26

Make Helper Usage

The factory uses Hyperf's make() helper at src/RedisFactory.php24 rather than direct instantiation (new RedisProxy()). This allows:

• Dependency Injection - The container can inject dependencies into RedisProxy
• Constructor Parameters - The ['pool' => $poolName] array passes constructor arguments
• Lifecycle Management - Container controls proxy instantiation and lifecycle

Sources: src/RedisFactory.php10 src/RedisFactory.php24

Configuration Contract

The factory relies on the following configuration structure:

Expected config structure:
{
 'redis' => [
 'poolName1' => [pool configuration],
 'poolName2' => [pool configuration],
 ...
 ]
}

Each key in the redis array becomes a named pool with an associated RedisProxy. The factory doesn't validate the pool configuration itself - it only creates proxies. Configuration validation happens when connections are actually established through the pool.

For details on pool configuration options, see Multi-Pool Configuration.

Sources: src/RedisFactory.php21-25