Ответ
Я разрабатывал систему кэширования с инвалидацией по времени (TTL) и событию для обеспечения консистентности данных при высокой нагрузке.
Архитектура решения (двухуровневый кэш):
- Локальный кэш (Caffeine) – для сверхбыстрого доступа в пределах одного экземпляра приложения.
- Распределенный кэш (Redis) – выступает в роли централизованного хранилища и шины событий для синхронизации между всеми инстансами.
Процесс обновления данных и инвалидации кэша:
public void updateItem(Item item) {
// 1. Атомарное обновление в основной базе данных
itemRepository.save(item);
// 2. Немедленная инвалидация в локальном кэше текущего инстанса
localCache.invalidate(item.getId());
// 3. Публикация события в Redis для уведомления всех других инстансов
redisTemplate.convertAndSend("cache:invalidate", item.getId());
}Все инстансы приложения подписаны на канал cache:invalidate и инвалидируют свой локальный кэш при получении события. TTL в Redis выступает как fallback-механизм на случай сбоев. В результате система сочетает высокую скорость локального кэша с консистентностью распределенной системы.
Ответ 18+ 🔞
А, ну вот, разработка системы кэширования, классика жанра! Сидишь такой, думаешь: «Сейчас я тут накэширую всё, как бог, производительность взлетит до небес!». А потом бац — и данные в кэше как говно собачье, устаревшие, потому что кто-то в другом месте их уже поменял. И клиенты орут: «Почему у меня старая цена, ёпта?!». Волнение ебать, терпения ноль.
Так вот, чтобы не было этого пиздеца, я запилил систему с двухуровневым кэшем. Слушай, как я изголялся.
Архитектура, блядь, или как не обосраться:
- Кэш локальный, прямо в памяти приложения (Caffeine). Это, сука, как личный сейф под подушкой — открыл мгновенно, взял что надо. Скорость — овердохуища. Но только для этого одного экземпляра твоего сервиса.
- Кэш распределённый (Redis). Это уже общая касса, до которой все могут дотянуться. И заодно — громкая связь, чтобы все орущие в один рупор услышали.
А теперь магия, как всё обновляется без пиздеца:
public void updateItem(Item item) {
// 1. Сначала честно, как мальчик, пишем в главную базу. Это наш источник правды, ёпта.
itemRepository.save(item);
// 2. Тут же, не откладывая в долгий ящик, выкидываем старые данные ИЗ СВОЕГО локального кэша. Чтобы самому себе не навредить.
localCache.invalidate(item.getId());
// 3. А вот это ключевой момент, блядь! Кричим на всю деревню, в Redis-канал: «Эй, пидары! Объект с таким-то ID — теперь говно! Удаляйте его у себя!».
redisTemplate.convertAndSend("cache:invalidate", item.getId());
}И все остальные инстансы, которые сидят и слушают этот канал cache:invalidate, как только слышат крик — тут же вышвыривают эту хуйню из своих локальных сейфов. Красота!
А TTL в Redis — это такая подстраховка, мудя. На случай, если событие потерялось, или какой-то инстанс в этот момент был в отключке. Через заданное время Redis сам почистит застоявшиеся данные, как надёжный уборщик.
Итог: скорость — как от локального кэша, а консистентность — почти как у распределённого. Не идеально, конечно, но для большинства сценариев — просто ебать как хорошо работает. Главное — вовремя орать во всеуслышание, когда что-то поменял.