Какой опыт работы с кэшированием в Java-приложениях?

А, ну кэширование, блядь! Это ж святое, ёпта! Как без него? Ты представь, каждый раз, когда юзер твой тупорылый на кнопку жмёт, ты лезешь в базу, как последний долбоёб, и тащишь одно и то же по десять раз нахуй. А потом удивляешься, что приложение твоё еле ползает, как мартышлюшка с похмелья.

Вот смотри, как я это обычно делаю, чтобы не обосраться со скоростью.

Первое, что под руку попадётся — кэш прямо в памяти приложения.
Берёшь, например, Caffeine — штука быстрая, как хуй с горы. Или Ehcache, если старый пердун. А чтобы не париться с ручным управлением, оборачиваешь всё в Spring Cache — навесил аннотацию и похуй, работает.

Вот, глянь, как это выглядит, когда ты не хочешь, чтобы твой сервис каждый раз лез в БД, как маньяк в окно:

@Configuration
@EnableCaching
public class CacheConfig {
    @Bean
    public CacheManager cacheManager() {
        CaffeineCacheManager cacheManager = new CaffeineCacheManager("users", "products");
        cacheManager.setCaffeine(Caffeine.newBuilder()
                .expireAfterWrite(10, TimeUnit.MINUTES)
                .maximumSize(1000));
        return cacheManager;
    }
}

@Service
public class UserService {
    @Cacheable(value = "users", key = "#id", unless = "#result == null")
    public User getUserById(Long id) {
        // Дорогой запрос к БД
        return userRepository.findById(id).orElse(null);
    }

    @CacheEvict(value = "users", key = "#user.id")
    public User updateUser(User user) {
        return userRepository.save(user);
    }

    @CachePut(value = "users", key = "#user.id")
    public User createUser(User user) {
        return userRepository.save(user);
    }
}

Видишь? @Cacheable — это типа "сходи один раз, запомни, и потом просто отдавай из памяти, не еби мозг". @CacheEvict — это "ой, данные поменялись, старый кэш нахуй, выкидывай". А @CachePut — "сохранил новое — сразу же в кэш его, чтобы потом не искать". Красота, блядь!

А если приложение у тебя не одно, а целая орава инстансов?
Тогда локальный кэш — это пиздец, а не решение. Один инстанс обновил юзера, а остальные десять сидят и отдают старые данные из своего кэша, как идиоты. Вот тут на сцену выходит Redis или Hazelcast. Это распределённый кэш, где все твои сервисы смотрят в одну точку. Обновили данные в одном месте — везде подхватили. Магия, сука!

Но тут, конечно, свои подводные ебланы есть:

• Что выкидывать из кэша, когда он полный? LRU (то, чем давно не пользовались) или LFU (то, чем редко пользовались)? Выбирай по паттерну доступа, а то выкинешь не то и опять полезешь в базу, как в говно.
• Согласованность — это вообще пиздец тема. Обновил запись в БД, а кэш про это не знает и отдаёт старьё. Аннотации @CacheEvict спасают, но если запросов овердохуища, может случиться cache stampede — все одновременно полезли в базу, потому что кэш протух. Лечится блокировками или рандомным TTL, чтобы не все сразу, блядь.
• Сериализация в распределённом кэше. Нельзя тупо Java-объект сунуть в Redis. Нужно его во что-то превратить — JSON (Jackson), Protobuf, что угодно, лишь бы быстро и компактно.
• Мониторить надо, а то словишь сюрприз. Смотри hit/miss ratio: если miss-ов много — кэш хуйовый, настроить надо. Смотри размер и latency — если всё плохо, значит, опять где-то накосячил.

В общем, применяй это всё для тяжёлых вычислений, запросов к базе, ответов от внешних API (которые отвечают по полчаса, пидарасы) и сессий пользователей. Главное — не перестарайся, а то закэшируешь всё подряд и потом будешь искать, почему данные не обновляются. Чистая магия, но с подвохом, ёпта!