Redis连接是否需复用？复用单连接与单请求单连接的性能对比

Great question—this is something I’ve hashed out with engineering teams and validated in production setups more than once. Let’s break this down clearly:

Short Answer #

Connection reuse (via a connection pool, not just a single connection) is almost always the better choice for performance. Using a separate connection per request introduces unnecessary overhead that kills throughput and increases latency, especially under load.

Why Reuse Wins on Performance #

Let’s dive into the key reasons:

1. TCP/TLS Connection Overhead is Non-Trivial #

Every new Redis connection requires a TCP three-way handshake (and TLS handshake if you’re using encrypted connections). Even if each handshake takes just 1-2ms, multiply that by thousands of requests per second, and you’re wasting a huge chunk of your application’s time on setup instead of actual work.

For example: If your app handles 1000 QPS, a 1ms handshake per request adds up to 1 full second of overhead every second—time that could be spent processing business logic or serving users. Reusing connections eliminates this entirely.

2. Redis’s Single-Threaded Execution Model Makes Multiple Connections Redundant #

Redis processes commands in a single thread (excluding background tasks like persistence or replication). Even if you spin up a new connection for every request, Redis can’t handle those commands in parallel—it just queues them up. All those extra connections do is force Redis to maintain more connection contexts, which eats into memory and CPU resources that could be used for processing your commands.

3. Connection Pools Strike the Perfect Balance #

I should clarify: I’m not advocating for a single connection for all requests (though that works for low-concurrency apps). Instead, use a connection pool (like JedisPool for Java, or redis-py’s connection pool for Python). A pool maintains a set of idle connections that your app can borrow, use, and return. This gives you:

• The performance benefits of connection reuse
• The ability to handle concurrent requests (including blocking commands like BLPOP or BRPOP, which would hang a single connection)
• Control over resource usage (you can limit the maximum number of connections to avoid overwhelming Redis)

When Might You Need Per-Request Connections? #

Honestly, this is a rare edge case. The only scenario where per-request connections make sense is if you’re using long-running blocking commands and can’t afford to tie up pool connections. Even then, most teams solve this by having a separate pool dedicated to blocking commands instead of using per-request connections.

Practical Recommendations #

• Always use a connection pool: Don’t roll your own—use the pool implementation provided by your Redis client library.
• Tune pool size: Start with a small number (e.g., 10-20 connections) and adjust based on your load. Too many connections waste Redis resources; too few cause connection wait times.
• Add connection health checks: Configure your pool to test connections before borrowing them (e.g., sending a PING command) to avoid using stale or dead connections.

内容的提问来源于stack exchange，提问作者Leonardo