Проблема прямого обновления в БД:
Таблица
posts имеет колонку likes_count. Каждый лайк выполняет UPDATE posts SET likes_count = likes_count + 1 WHERE id = ?. Это вызывает блокировку строки (row lock) на время обновления, а при тысячах лайков в секунду — конкуренцию и падение пропускной способности.Как решает Redis:
Redis хранит счётчики в памяти:
INCR post:123:likes. Операция атомарная и очень быстрая (микросекунды).Отдельный фоновый процесс (воркер) каждые N секунд (например, 10) читает текущие значения из Redis и обновляет БД:
UPDATE posts SET likes_count = current_value WHERE id = ?.При падении Redis счётчики можно восстановить из БД (если сохранять периодически) или из логов событий (Kafka).
Допустима ли eventual consistency?
Да. Пользователь видит, что лайк добавился, но в БД он может отразиться с задержкой в несколько секунд. Для лайков это приемлемо.
Реальный пример: Twitter и Instagram используют подобную архитектуру: лайки, ретвиты, подписки сначала идут в Redis, затем асинхронно записываются в основное хранилище.
Вывод: Аналитик, проектируя высоконагруженный счётчик, должен заложить требование: «Использовать Redis как временный счётчик с асинхронной записью в БД, согласованность — в конечном итоге (eventual consistency)».