NoSQL: Redis as Cache and Session Store

NoSQL databases are still a controversial topic in the enterprise world in 2012. Oracle and PostgreSQL have reigned for decades and nobody is keen to take risks. But Redis — a key-value store running entirely in memory — has found a place even in the most conservative architectures. Not as a replacement for a relational DB, but as a perfect complement.

What Redis Is and Why We’re Talking About It¶

Redis (Remote Dictionary Server) is an open-source in-memory data structure store. Unlike a classical database, it keeps all data in RAM, giving it response times in the range of microseconds. It supports strings, hashes, lists, sets, sorted sets, and pub/sub messaging. Version 2.6, the current latest, added Lua scripting.

Important: Redis is not a replacement for Oracle. It has no SQL, no transactions in the traditional sense, no joins. It’s a specialized tool for specific use cases — and it excels at them.

Use Case #1: Cache Layer in Front of the Database¶

A typical enterprise system has a problem: the database is a bottleneck. Hundreds of users call the same queries — a product list, configuration parameters, lookup tables. Every query goes to Oracle even though the data changes once an hour.

Redis solves this problem elegantly. You serialize the SQL query result (JSON or Java serialization) and store it in Redis with a TTL (time to live). The next request reads from Redis — the response arrives in 0.1 ms instead of 50 ms from the database.

// Simple caching with the Jedis client
Jedis jedis = new Jedis("redis-server", 6379);
String cached = jedis.get("products:all");
if (cached == null) {
  List<Product> products = dao.findAll();
  cached = gson.toJson(products);
  jedis.setex("products:all", 3600, cached); // TTL 1h
}
return gson.fromJson(cached, productListType);

In our project for an insurance company, this approach reduced the load on Oracle by 70%. API response time dropped from an average of 200 ms to 15 ms for cached endpoints.

Use Case #2: Session Store for Clustered Applications¶

Java EE application servers (WebSphere, JBoss, WebLogic) store HTTP sessions in server memory by default. The problem arises when you have a cluster — two or more servers behind a load balancer. A user logs in on server A, the next request goes to server B, and the session isn’t there.

Solution one is sticky sessions (the load balancer always sends a user to the same server). But that means uneven load distribution and a problem when a server fails — the session is lost.

Solution two is session replication (servers copy sessions between themselves). This works for 2–3 servers, but scales poorly and consumes network capacity.

Solution three — and the one we recommend — is an externalized session in Redis. All servers in the cluster read and write sessions to a single Redis instance. Response is under 1 ms, sessions survive a restart of any application server, and the system scales linearly.

Spring Session (Prototype Approach)¶

Spring Framework doesn’t yet have official Redis session management (that will come with the Spring Session project in a few years), but implementing a custom HttpSessionListener that serializes sessions to Redis is an afternoon’s work. Alternatively, there’s the tomcat-redis-session-manager library for Tomcat that handles it transparently.

Persistence and Data Safety¶

“Data in RAM? What happens when the server crashes?” — a legitimate question. Redis offers two persistence mechanisms: RDB snapshots (a periodic dump of the entire database to disk) and AOF (append-only file, logging every write operation).

For cache, persistence is unnecessary — data can always be regenerated from the primary database. For session storage, we recommend AOF with fsync every second — you lose at most one second of data, which is an acceptable trade-off.

For high availability in production, we use Redis Sentinel — automatic failover with master-slave replication. The slave continuously copies data from the master, and on failure it is automatically promoted to the new master. Failover typically takes 5–15 seconds.

Redis vs. Memcached¶

Memcached is an older and simpler alternative. For pure key-value caching it performs comparably. But Redis has significant advantages:

• Data structures — lists, sets, and sorted sets enable operations that in Memcached require read-modify-write cycles
• Persistence — Memcached loses all data on restart
• Pub/Sub — Redis also works as a lightweight message broker
• Atomic operations — INCR, LPUSH, SADD are atomic without locks
• Replication — master-slave out of the box

The only area where Memcached wins is multithreading. Redis is single-threaded (uses one CPU core). In practice this is not a problem — a single core handles 100,000+ operations per second.

Operational Experience¶

We’ve been running Redis in production for a year. The memory footprint is surprisingly small — 100,000 session objects take around 2 GB of RAM. We monitor via redis-cli INFO and a custom Nagios check that tracks used_memory, connected_clients, and the keyspace hit ratio.

The biggest lesson: set maxmemory and an eviction policy. Without it, Redis grows until it consumes all server RAM and the OOM killer takes it down. For cache we use allkeys-lru (least recently used), for session storage noeviction (return an error rather than delete a session).

Summary¶

Redis is not a revolution that will replace your relational database. It’s a surgically precise tool for two key problems: caching and session management. Deployment is simple, operation is lightweight, and the performance gains are dramatic. If your system suffers from slow responses or issues with clustered sessions, Redis is the answer.