Какие проблемы возникают при кешировании связанных данных в нескольких независимых кешах?

Question

Какие проблемы возникают при кешировании связанных данных в нескольких независимых кешах?

Тип вопроса: Архитектура Вероятность: 10% Категория: Golang Разработчик

Ответ

Основная проблема — несогласованность данных (data inconsistency), которая возникает, когда связанные сущности хранятся в разных, несинхронизированных кешах.

Представим, что у нас есть кеш для пользователей и отдельный кеш для их заказов. Если мы обновим данные пользователя (например, имя), но забудем инвалидировать или обновить кеш заказов, то в кеше заказов останутся устаревшие данные о пользователе.

Пример на Go:

// Определим структуры для примера
type User struct {
    ID   int
    Name string
}
type Order struct {
    ID       int
    UserID   int
    UserName string // Дублируем имя для примера
}

var userCache = make(map[int]User)
var ordersCache = make(map[int]Order)

// Функция обновляет пользователя, но забывает обновить связанные данные
func updateUser(user User) {
    // 1. Обновляем данные в базе данных
    // db.UpdateUser(user)

    // 2. Инвалидируем кеш самого пользователя
    delete(userCache, user.ID)

    // 3. ОШИБКА: Мы не инвалидировали кеш заказов.
    // Теперь ordersCache может содержать заказы с устаревшим UserName.
}

Ключевые последствия:

Проблема инвалидации кеша: Это самая сложная часть. Нужно разработать надёжную стратегию для одновременного обновления всех связанных кешей.
Устаревшие данные (Stale Data): Пользователи видят неактуальную информацию, что может привести к ошибкам в бизнес-логике.
Сложность синхронизации: В многопоточных системах проблема усугубляется из-за состояний гонки при обновлении разных кешей.
Избыточность данных: Дублирование данных (как UserName в примере) увеличивает потребление памяти.

Возможные решения:

Централизованный кеш: Использовать единое хранилище для связанных данных.
Событийная инвалидация: Использовать шину сообщений (например, RabbitMQ, Kafka) для рассылки событий об изменении данных. Все заинтересованные сервисы подписываются на события и инвалидируют свои локальные кеши.
Продуманная структура ключей: Использовать ключи, которые позволяют легко находить и инвалидировать все связанные данные (например, user:123:profile, user:123:orders).

Ответ 18+ 🔞

А, ну это же классика, блядь! Сейчас объясню на пальцах, а то ты, сука, опять в коде накосячишь.

Смотри, представь себе, что у тебя в холодильнике лежит колбаса, а в хлебнице — хлеб. Ты решил, что колбаса говно, и выкинул её в мусорку. Но забыл, блядь, сказать об этом своему сожителю, который через час пришёл и намазал на хлеб эту самую, уже выброшенную, колбасу. Вот тебе и несогласованность данных, ёпта! В рот меня чих-пых!

Один кеш про пользователя, другой — про его заказы. Обновил юзера, а в заказах-то его старое имя так и осталось висеть, как сопля на рукаве. И сидит потом клиент, смотрит в свой заказ и думает: «Я вроде Петя, а тут написано „Вася“, я что, ебанутый?»

Вот смотри, как это в коде выглядит, сука:

// Определим структуры для примера
type User struct {
    ID   int
    Name string
}
type Order struct {
    ID       int
    UserID   int
    UserName string // А вот и дубликат, на котором всё и посыпется!
}

var userCache = make(map[int]User)
var ordersCache = make(map[int]Order)

// Функция обновляет пользователя, но забывает обновить связанные данные
func updateUser(user User) {
    // 1. Обновляем данные в базе данных (ну, типа обновили)
    // db.UpdateUser(user)

    // 2. Инвалидируем кеш самого пользователя (выкинули колбасу из холодильника)
    delete(userCache, user.ID)

    // 3. ОШИБКА, ПИЗДЕЦ И АПОКАЛИПСИС!
    // Мы не тронули кеш заказов. А там лежит бутерброд с тухлой колбасой.
    // Теперь ordersCache содержит заказы с устаревшим UserName.
    // И кто-то этим нахуй отравится!
}

И что в итоге, блядь?

Инвалидация — это пиздец. Нужно быть семи пядей во лбу, чтобы не забыть обновить ВСЁ, что связано. А связанного может быть овердохуища.
Данные врут. Люди видят какую-то хуйню вместо правды, и вся бизнес-логика летит в тартарары.
Синхронизировать — это ад. Особенно когда двадцать потоков одновременно пытаются и обновить, и прочитать. Состояние гонки, ёбаный насос!
Память жрётся. Хранить одно и то же в десяти местах — это, блядь, нерационально. Компьютер не резиновый, в конце концов!

Ну и как с этим бороться, хитрая жопа?

Один большой кеш. Сложить всё в одну кучу, как в общий шкаф. Но тогда, если шкаф сломается — всё пропало. Рискованно.
Кричать на всю деревню. Использовать какую-нибудь очередь (типа Кафки) и орать на всех: «Эй, пидарасы, Петя теперь не Вася! Кто хранит данные Пети — обновите!». Все подписываются и сами следят за своими тараканами.
Умные ключи. Делать ключи по шаблону, чтобы потом всех их разом найти и выпороть. Типа user:123:* — и бац, все ключи, начинающиеся с этого, нахуй удаляются.

Короче, думай головой, когда кешируешь связанные штуки. А то получишь волшебную систему, где данные живут своей отдельной, блядь, жизнью.