ключ — значение — эксплуатация в продеkey-value — running it in production
In-memory по умолчанию значит "данные исчезают при перезапуске", если не позаботиться об этом отдельно. Здесь — как реально переживают перезапуск, реплицируются между узлами, и какую службу выбрать под конкретные требования.In-memory by default means "data disappears on restart" unless handled separately. Here's how it actually survives a restart, replicates across nodes, and which service to pick for specific requirements.
RDB (snapshot) — периодический полный слепок всей памяти на диск (например, раз в 5 минут при N изменениях). Быстрое восстановление (просто загрузить один файл), компактный размер на диске, но потеря всех изменений между последним снапшотом и падением процесса — окно потери данных пропорционально интервалу снапшота.RDB (snapshot) — a periodic full memory snapshot written to disk (say, every 5 minutes if N changes occurred). Fast recovery (just load one file), a compact on-disk size, but every change between the last snapshot and the process crashing is lost — the data-loss window is proportional to the snapshot interval.
AOF (Append-Only File) — журналирование каждой операции записи по мере её выполнения, аналог WAL в реляционных БД. Настраиваемая частота `fsync` (`always`/`everysec`/`no`) напрямую определяет компромисс между надёжностью и скоростью записи: `everysec` — разумный дефолт (максимум секунда потерянных данных при крахе), `always` — почти без риска потери, но с заметной просадкой по скорости записи.AOF (Append-Only File) — logs every write operation as it happens, analogous to a WAL in relational DBs. The configurable `fsync` frequency (`always`/`everysec`/`no`) directly sets the trade-off between durability and write speed: `everysec` is a reasonable default (at most a second of lost data on crash), `always` carries almost no loss risk but a noticeable write-speed hit.
На практике часто комбинируют оба: RDB для быстрого полного восстановления и переноса данных между инстансами, AOF — для минимизации окна потери данных при обычном перезапуске. Полный отказ от персистентности (чистый in-memory без записи на диск) оправдан только для данных, потеря которых абсолютно приемлема — например, чистого кэша, восстановимого из основной БД.In practice both are often combined: RDB for fast full recovery and moving data between instances, AOF for minimizing the data-loss window on a routine restart. Disabling persistence entirely (pure in-memory, no disk writes at all) is only justified for data whose loss is fully acceptable — say, a pure cache recoverable from the primary DB.
Репликация (master-replica) даёт отказоустойчивость (replica может стать новым мастером при падении текущего, обычно через Sentinel в случае Redis) и горизонтальное масштабирование чтения — читающие запросы распределяются между репликами, пока запись остаётся только на мастере. Репликация асинхронна по умолчанию, что означает возможность потери самых свежих записей при внезапном failover мастера (окно репликационного лага).Replication (master-replica) provides fault tolerance (a replica can become the new master if the current one fails, typically via Sentinel for Redis) and horizontal read scaling — read requests spread across replicas while writes stay on the master alone. Replication is asynchronous by default, meaning the most recent writes can be lost on a sudden master failover (the replication-lag window).
Кластеризация (Redis Cluster) идёт дальше репликации — она шардирует само пространство ключей между несколькими независимыми master-узлами (по умолчанию 16384 хэш-слота, каждый ключ хэшируется в конкретный слот), позволяя масштабировать не только чтение, но и запись горизонтально. Каждый шард обычно имеет собственные реплики для отказоустойчивости внутри себя — кластеризация и репликация работают вместе, а не заменяют друг друга.Clustering (Redis Cluster) goes beyond replication — it shards the keyspace itself across several independent master nodes (16384 hash slots by default, each key hashes to a specific slot), scaling not just reads but writes horizontally too. Each shard typically has its own replicas for fault tolerance within itself — clustering and replication work together, not as substitutes for each other.
| службаservice | когда выбратьwhen to choose it |
|---|---|
| Redis | де-факто стандарт: широчайшая экосистема, богатые структуры данных (не только строки — хэши, множества, sorted sets, streams), Redis Cluster для масштабирования.the de-facto standard: the widest ecosystem, rich data structures (not just strings — hashes, sets, sorted sets, streams), Redis Cluster for scaling. |
| Valkey | открытый форк Redis (после смены лицензии Redis на не-OSS) — совместим по протоколу, выбор для тех, кому принципиальна открытая лицензия.an open-source fork of Redis (after Redis's license moved away from OSS) — protocol-compatible, chosen by those for whom an open license matters on principle. |
| Memcached | проще Redis, только строковый кэш без богатых структур и персистентности — оправдан, когда нужен исключительно multi-threaded чистый кэш и ничего больше.simpler than Redis, a plain string cache with no rich structures or persistence — justified when a purely multi-threaded cache is all that's needed, nothing more. |
| Amazon DynamoDB | managed-сервис без необходимости эксплуатировать инфраструктуру самому — выбор при работе в AWS-экосистеме и готовности платить за managed-удобство.a managed service with no infrastructure to operate yourself — chosen when working in the AWS ecosystem and willing to pay for managed convenience. |
Создание RDB-снапшота использует `fork()` для копирования памяти процесса через Copy-on-Write — на инстансах с большим объёмом памяти и высокой частотой записи (много CoW-копий страниц во время снапшота) сам `fork()` может занять заметное время, вызывая паузы в обслуживании запросов. Это тот же класс проблемы, что и AOF rewrite.Creating an RDB snapshot uses `fork()` to copy the process's memory via Copy-on-Write — on instances with a large memory footprint and high write frequency (many CoW page copies during the snapshot), `fork()` itself can take a noticeable amount of time, causing pauses in request handling. This is the same class of problem as an AOF rewrite.
Если мастер падает сразу после успешной записи, но до того, как она реплицировалась, эта запись теряется при повышении реплики до нового мастера — приложения, для которых это неприемлемо (не просто кэш, а, например, счётчик платежей), должны либо использовать синхронную репликацию (`WAIT` в Redis — с ценой в задержку), либо не полагаться на key-value хранилище как единственный источник истины для таких данных.If the master crashes right after a successful write but before it replicates, that write is lost when a replica is promoted to the new master — applications for which this is unacceptable (not just a cache, but say a payment counter) must either use synchronous replication (`WAIT` in Redis — at a latency cost) or not rely on the key-value store as the sole source of truth for that data.
Многоключевые операции (например, транзакция над несколькими ключами) в Redis Cluster работают только если все затронутые ключи попадают в один и тот же хэш-слот — то есть физически на одном узле. Хэш-теги (`{user:1042}:profile`, `{user:1042}:sessions` — фигурные скобки заставляют хэшироваться только содержимое внутри них) — механизм, гарантирующий совместное размещение связанных ключей на одном слоте.Multi-key operations (say, a transaction over several keys) in Redis Cluster only work if every key involved lands in the same hash slot — meaning physically on the same node. Hash tags (`{user:1042}:profile`, `{user:1042}:sessions` — curly braces force only their contents to be hashed) are the mechanism guaranteeing related keys co-locate on the same slot.