Redis Connections

{
  "name": "redis-connections",
  "version": "1.0.0",
  "description": "Redis client and connection guidance — pooling, multiplexing, pipelining, client-side caching, timeouts, slow commands.",
  "author": {
    "name": "Redis",
    "email": "support@redis.com"
  },
  "homepage": "https://redis.io",
  "repository": "https://github.com/redis/agent-skills",
  "license": "MIT",
  "keywords": ["redis", "performance", "connections", "pooling", "pipelining", "client-side-cache"]
}


# Avoid Slow Commands in Production

Some Redis commands are slow because they scan large datasets. Use incremental alternatives to avoid blocking the server.

| Avoid | Use Instead |
|-------|-------------|
| `KEYS *` | `SCAN` with cursor |
| `SMEMBERS` on large sets | `SSCAN` |
| `HGETALL` on large hashes | `HSCAN` |
| `LRANGE 0 -1` on large lists | Paginate with `LRANGE 0 100` |

**Correct:** Use SCAN for iteration.

**Python** (redis-py):
```python
# Good: Non-blocking iteration
cursor = 0
while True:
    cursor, keys = redis.scan(cursor, match="user:*", count=100)
    for key in keys:
        process(key)
    if cursor == 0:
        break
```

**Java** (Jedis):
```java
import redis.clients.jedis.ScanIteration;
import redis.clients.jedis.UnifiedJedis;
import java.util.List;

try (UnifiedJedis jedis = new UnifiedJedis("redis://localhost:6379")) {
    // ScanIteration manages the cursor automatically
    ScanIteration scan = jedis.scanIteration(10, "user:*", "hash");

    while (!scan.isIterationCompleted()) {
        List<String> result = scan.nextBatch().getResult();
        for (String key : result) {
            process(key);
        }
    }
}
```

**Incorrect:** Using KEYS in production.

**Python** (redis-py):
```python
# Bad: Scans all keys, slow on large datasets
keys = redis.keys("user:*")
```

**Java** (Jedis):
```java
// Bad: Scans all keys, blocks the server
Set<String> result = jedis.keys("*");
```

**Note:** Truly blocking commands (like `BLPOP`, `BRPOP`, `BLMOVE`) that wait indefinitely for data are appropriate for some use cases like job queues, but should be used with timeouts.

```python
# Blocking pop with timeout - appropriate for queue consumers
result = redis.blpop("task_queue", timeout=5)
```

Reference: [Redis SCAN](https://redis.io/docs/latest/commands/scan/)


# Use Client-Side Caching for Frequently Read Data

Use a connection with client-side caching enabled for any data that will be read frequently but written only occasionally. Client-side caching avoids contacting the server for repeated access to data that has recently been read, reducing network traffic and improving performance.

**Correct:** Enable client-side caching with RESP3 protocol for frequently accessed data.

**Python** (redis-py):
```python
import redis

# Enable client-side caching with RESP3
client = redis.Redis(
    host='localhost',
    port=6379,
    protocol=3,  # RESP3 required for client-side caching
    cache_config=redis.CacheConfig(max_size=1000)
)

# Cached reads avoid server round-trips
value = client.get("frequently:read:key")
```

**Java** (Jedis):
```java
import redis.clients.jedis.DefaultJedisClientConfig;
import redis.clients.jedis.UnifiedJedis;
import redis.clients.jedis.HostAndPort;
import redis.clients.jedis.CacheConfig;

HostAndPort endpoint = new HostAndPort("localhost", 6379);

DefaultJedisClientConfig config = DefaultJedisClientConfig
    .builder()
    .password("secretPassword")
    .protocol(RedisProtocol.RESP3)
    .build();

CacheConfig cacheConfig = CacheConfig.builder().maxSize(1000).build();

UnifiedJedis client = new UnifiedJedis(endpoint, config, cacheConfig);
```

**When to use:**
- Configuration data read frequently, updated rarely
- User session data accessed on every request
- Feature flags or settings checked repeatedly
- Any read-heavy workload with low write frequency

**When NOT needed:**
- Data that changes frequently (cache invalidation overhead outweighs benefits)
- Write-heavy workloads
- Simple applications wh