Page 7 - Redis

The INFO command delivers a wealth of raw data about a Redis instance, but as plain text output it is barely usable for systematic alerting. The Redis Exporter translates exactly this raw data into structured Prometheus metrics, extends it with custom check commands for key sizes and latencies, and only then makes it usable for dashboards and alerting rules. This article covers which metrics the exporter concretely provides, what sensible alerting rules for memory usage, connection count, and replication lag look like, and how to build a dashboard for daily operations from it that fires not only on an acute outage, but already at the first warning signs.

Running Redis on Kubernetes sounds at first like a simple deployment with an image and a service. In practice, Redis is a stateful service with replication, failover logic, and persistent data, and that does not fit neatly into Kubernetes' stateless default model. A Redis operator closes this gap by mapping Sentinel-based failover, pod identity, and storage management as declarative custom resources instead of rebuilding them by hand with YAML files and shell scripts. This article shows how an operator actually works, which StatefulSet specifics become relevant, and where the point sits at which a managed service is the more pragmatic choice.

Race conditions in distributed PHP applications lead to double bookings, corrupted data and bugs that are hard to reproduce. Symfony Lock with Redis solves this problem with a clean API for distributed locks, no manual SETNX scripts, no fragile database row locks, but a tested lock that expires automatically.

Count millions of unique visitors without storing millions of individual IDs: HyperLogLog estimates the cardinality of a set with a fixed memory footprint of only 12 kilobytes and a typical error of about 0.81 percent, regardless of whether the set contains a thousand or a billion elements.

Redis handles two fundamentally different jobs in Magento 2: write-heavy session storage and read-heavy caching, often on the same server without any clean separation. This article shows how to calculate the memory needs for Redis sessions, configure env.php and redis.conf for separate instances, and use monitoring to catch it early when Redis sizing hits its limits.

Redis is configured by default for maximum performance, not maximum security. Without authentication, with an open network bind and dangerous commands enabled, a production Redis instance becomes an easy target. This article shows the complete hardening process for Magento environments, from passwords and ACLs to TLS.

Redis and Varnish are often pitted against each other in Magento discussions, yet they solve fundamentally different problems. Redis is the cache and session backend for object cache and full page cache storage, Varnish is the HTTP layer in front that delivers whole pages before Magento even starts. This article explains the clean role split.

Redis replication looks simple at first glance: one command, one connection, data flows from master to replica. Underneath, though, the PSYNC protocol decides whether a brief network interruption costs only a few kilobytes or requires retransferring the entire dataset, and an incorrectly sized backlog regularly wipes out exactly that advantage in practice.

A misconfigured session backend is one of the most common yet hardest to diagnose causes of slow Magento shops. Session locking, timeout values and the break_after_frontend parameter decide whether parallel Ajax requests within a session block each other or run cleanly side by side. This article shows step by step how to correctly configure the Redis session backend.

Data loss in Redis rarely comes from a single obvious mistake, but from the interplay of fsync timing, replication lag and automatic failover under time pressure. Knowing the concrete scenarios under which Redis actually loses data lets you deliberately combine the right safeguards, instead of relying on a single feature.