What Is New in Redis 2.0 (summary table)
Redis 2.0 introduces foundational features that shape its future as a versatile data structure server. The release focuses on expanding data types, improving persistence, and adding critical operational commands.
| Category | Key Changes |
|---|---|
| New Data Types | Lists, Hashes, Unsorted Sets |
| Persistence & Durability | Append-only file (AOF) persistence |
| Operational Commands | BGREWRITEAOF, MONITOR, SLOWLOG |
| Virtual Memory (Experimental) | Offloading rarely-used data to disk |
| Protocol & Client Handling | Binary-safe data, inline commands, client timeouts |
What new data structures does Redis 2.0 add?
Redis 2.0 moves beyond strings with three core data types. Lists support push/pop operations from both ends, enabling use cases like message queues or activity streams. Hashes store field-value pairs, perfect for representing objects.
Unsorted Sets provide collections of unique strings with fast membership testing, union, and intersection operations. This matters because it transforms Redis from a simple key-value store into a more capable structure server, reducing the need for client-side data processing.
How does the new Append-Only File (AOF) work?
AOF persistence logs every write operation received by the server. This log can be replayed on server startup to reconstruct the dataset. In practice, it offers a different durability trade-off compared to snapshot-based RDB persistence.
You can configure fsync policy (none, every second, always) to balance safety and performance. The
BGREWRITEAOF command rewrites the log in the background when it gets too large, a crucial
operational feature for long-running instances.
What operational visibility tools were introduced?
Two commands significantly improve debugging and monitoring. The MONITOR command streams all
commands processed by the server in real-time, which is invaluable for seeing what clients are doing.
The SLOWLOG records commands that exceed a specified execution time, helping identify performance
bottlenecks. These tools are classic Redis--simple, text-based, and immediately useful for developers
troubleshooting live systems.
Is Virtual Memory ready for production use?
Virtual Memory (VM) is marked as experimental in 2.0. Its goal is to transparently swap rarely-used values to disk while keeping keys and frequently-used data in memory. This attempts to solve the problem of large datasets with non-uniform access patterns.
In practice, the initial implementation had trade-offs and complexities. It's a sign of Redis exploring solutions for larger-than-memory workloads, but most production deployments at this stage relied on fitting the working set in RAM.
What changes were made to the protocol and client handling?
The protocol becomes fully binary-safe for all data types, not just keys. This means you can store any binary sequence as a value without issues. Support for inline commands simplifies manual telnet-style interaction.
New client timeout settings help clean up idle or misbehaving connections, protecting server resources. This reflects Redis's evolution to handle more diverse client environments and data payloads reliably.
FAQ
Should I use AOF or RDB persistence in Redis 2.0?
It depends on your durability needs. RDB
(snapshots) is faster and creates smaller files, but you may lose data since the last save. AOF logs every
write, offering better durability, but logs can grow large and replay can be slower on restart. Many run both
for a safety net.
Can I use the new List type as a queue?
Yes, this is a primary use case. Use
LPUSH/RPOP for a FIFO queue, or RPUSH/LPOP for another
ordering. Blocking variants like BRPOP allow workers to wait for items, making simple, reliable
message queues straightforward.
What does the experimental Virtual Memory status mean?
It means the feature is available to
test but may have stability or performance issues. The implementation involves swapping values to disk, which
can cause latency spikes. For production, it's generally advised to ensure your dataset fits in physical RAM.
How does the MONITOR command impact performance?MONITOR is a debugging command
that streams all commands. It adds overhead because every command must be copied to the monitor connection.
Don't leave it running on high-throughput production instances--use it briefly to sample traffic.
Are Hashes more efficient than storing serialized objects in a String?
Often, yes. Hashes
allow you to get, set, or update individual fields without transferring the entire object. This reduces network
overhead and is more atomic. For small objects, Hashes are a much more natural fit than JSON strings in a
standard key.