Redis 6.0 RC1: Multi-Threading, ACLs, and the End of Stunnel

Salvatore Sanfilippo (antirez) dropped a bomb on the database community yesterday, December 19th. Redis 6.0 Release Candidate 1 is officially out. For years, we have debated the single-threaded nature of Redis. We've optimized our sysctl.conf files, pinned processes to specific CPU cores, and run multiple instances on the same metal just to saturate the bus. The argument was always: "Redis is memory bound, not CPU bound."

That argument is dead. With 6.0, Redis acknowledges the reality of 2019: network I/O is the real bottleneck. While the core data manipulation remains single-threaded (preserving the atomic simplicity we love), the I/O handling is finally going multi-threaded.

I downloaded the source code to a fresh CoolVDS instance in Oslo this morning to see if the hype matches the latency graphs. Here is what you need to know before 2020 hits.

The Elephant in the Room: Threaded I/O

If you have ever managed a high-throughput cache for a Magento store or a real-time bidding system, you know the pain. You watch htop. One core is at 100%, screaming in agony, while the other 31 cores on your server are idling. The bottleneck isn't the complex set intersection you ran; it's the kernel shuffling packets.

Redis 6.0 delegates the reading and writing of client sockets to separate threads. This allows the main thread to focus strictly on memory manipulation.

Here is how you enable it in the new redis.conf. Note that by default, it is disabled because, as the comments warn, it is usually not needed unless you are pushing massive throughput.

# redis.conf excerpt for Redis 6.0-rc1

# defaults to disabled
io-threads 4

# If you want to use threads for both reading and writing
# (experimental, usually just writing is enough)
io-threads-do-reads yes

Pro Tip: Do not just set io-threads to match your CPU count. If you allocate too many threads on a standard VPS, the context switching overhead will actually degrade performance. On a CoolVDS High-Frequency compute instance, starting with 4 threads is the sweet spot for benchmarking.

The "Old Way" vs. The 6.0 Way

Previously, to utilize a multi-core server, we had to shard data manually or use Redis Cluster across different ports on the same machine. It was a maintenance nightmare.

Finally: Native ACLs (Access Control Lists)

For Norwegian enterprises dealing with GDPR and strict internal compliance (Datatilsynet requirements), Redis has historically been a weak point. You had one password. If a developer needed to flush the cache, you gave them the password. That same password allowed them to run FLUSHALL or CONFIG SET.

Redis 6.0 introduces proper ACLs. You can now define users with granular permissions. You can restrict specific keys or specific commands.

# Create a user 'worker_app' that can only read/write to keys starting with 'queue:'
# and cannot use dangerous administrative commands.

ACL SETUSER worker_app on >complexpassword123 ~queue:* +get +set +rpush +lpop

This is massive for multi-tenant environments. If you are hosting multiple client projects on a single CoolVDS instance, you can now isolate their access logically without spinning up separate containers for every microservice.

Native SSL: Goodbye Spiped

Until now, securing Redis traffic across the public internet (or even across a private VLAN) required wrapping the connection in stunnel or spiped. It added latency and another point of failure.

Redis 6.0 supports SSL natively. To build it with TLS support, you need the OpenSSL development library installed (available in CentOS 7/8 and Debian 9/10).

# Installing dependencies on CentOS 7
yum install openssl-devel

# Building Redis 6.0 RC1 with TLS
make BUILD_TLS=yes

Configuring it is straightforward in redis.conf:

tls-port 6379
port 0
tls-cert-file /etc/ssl/redis/server.crt
tls-key-file /etc/ssl/redis/server.key
tls-ca-cert-file /etc/ssl/redis/ca.crt

The RESP3 Protocol

Less discussed but equally important is RESP3. The old protocol (RESP2) was semantic-poor. If you requested a map, Redis returned a flat array, and your client library had to know it was actually a map.

RESP3 allows Redis to return complex data types directly. This pushes more logic to the database and allows for "Client Side Caching." Imagine your application server (running in Oslo) caching hot keys locally, and Redis actively invalidating them only when they change. This eliminates the network round-trip entirely for read-heavy workloads.

Why Infrastructure Still Matters

Redis 6.0 is efficient, but it exposes hardware limitations more ruthlessly than before. When you enable threaded I/O, you are increasing the rate at which you hit the memory controller and the network interface.

If you run this on a standard VPS with "noisy neighbors" and shared CPU time, the context switching from the new threads will kill your latency. You might see high throughput, but your p99 latency will spike.

This is where CoolVDS architecture becomes relevant:

• NVMe Storage: Even though Redis is in-memory, AOF (Append Only File) persistence writes to disk constantly. Slow SATA SSDs will block the main thread during fsync. We use enterprise NVMe to ensure fsync is near-instant.
• Dedicated Resources: Redis 6.0 needs consistent CPU cycles for its I/O threads. Our KVM virtualization ensures no one steals your cycles.
• Network Latency: For our Norwegian clients, ping times to Oslo are critical. Client-side caching helps, but a 2ms physical latency beats a 30ms latency every time.

Conclusion: Don't Deploy (Yet)

Redis 6.0 RC1 is exciting, but it is a Release Candidate. Do not put this in your production docker-compose.yml today. However, the features are too significant to ignore.

Your immediate action plan:

1. Spin up a sandbox environment (a small CoolVDS instance is perfect for this).
2. Compile Redis 6.0 RC1 from source.
3. Test your application drivers. Many older PHP (Predis/PhpRedis) and Python libraries will need updates to support RESP3 and ACL auth flows.

The future of caching is multi-threaded. Get your benchmarks ready now so you can hit the ground running in 2020.