Page 2 - Redis

The Redis cache backend replaces Magento's default file based cache with an in memory store and removes one of the most common I/O bottlenecks in production shops. Understanding env.php, Cm_Cache_Backend_Redis and the related parameters for compression, database separation and cache tags lets you tune the cache backend for catalog size and traffic instead of relying on defaults.

Anyone planning a Redis high availability solution almost always faces the same fundamental choice: Redis Sentinel for automatic failover without sharding, or Redis Cluster for high availability with built in horizontal scaling. Both solve different problems, and picking the wrong one means either unnecessary operational complexity or an architecture that breaks down at the next growth ceiling.

Sorted Sets are usually seen as a tool for leaderboards, but they are one of the most versatile data structures in Redis. Backed by a score sorted skip list, Sorted Sets work equally well for time series data, delayed job execution and priority queues, often without any extra infrastructure beyond Redis itself.

Redis transactions queue commands with MULTI and execute them atomically with EXEC, without any other client interleaving its own commands. But anyone who assumes MULTI/EXEC behaves like a SQL transaction with rollback on runtime errors is working from a false assumption that can lead to inconsistent data in production.

The cache-aside pattern moves all caching logic into the application: it checks Redis, loads from the database on a miss, and fills the cache itself. Anyone who ignores error handling, TTL values and race conditions ends up with silent inconsistencies and unnecessary database load, even though Redis is supposed to prevent exactly that.

As soon as multiple processes access the same resource, a local mutex is no longer enough. Redis offers SET NX PX as a simple locking primitive and the Redlock algorithm as an approach for multiple independent instances, but Martin Kleppmann's well known critique clearly shows the limits of this technique and when simpler locks are actually sufficient.

Session storage looks trivial until an application scales across multiple servers and the first login vanishes right after a deploy. Redis as a centralized session store solves the scaling problem, but brings its own architecture decisions along with it, from serialization format through TTL strategy to the question of whether sticky sessions are even needed anymore.

Write-through writes synchronously into both cache and database, guaranteeing consistency at the cost of extra latency. Write-back only writes to the cache and delays the database write asynchronously, saving latency but creating a real risk of data loss if the cache server fails. Which strategy fits depends on the consistency requirements of the specific data.

Memory fragmentation occurs when the jemalloc allocator holds more physical memory than Redis actually needs for its data, and it can be measured precisely via mem_fragmentation_ratio. Anyone who understands how jemalloc manages memory blocks can configure Active Defrag deliberately and knows when a controlled restart is the better choice over live defragmentation.

RDB snapshots store the entire dataset of a Redis server as a compact binary file at fixed points in time. Anyone who understands save points, the BGSAVE fork mechanism, and copy-on-write can configure snapshot intervals so that data loss and latency spikes both stay under control, instead of relying on default values.