Блог

Я пишу серверное приложение, скажем app1 , с помощью Spring-boot. Это app1 позволяет получить доступ к базе db1 данных на выделенном сервере БД. Чтобы ускорить доступ к БД, я пометил некоторые из своих хранилищ JpaRepository как @Cacheable(<some_cache_key) , со временем истечения, скажем, 1 час.

Проблема db1 в том, что он используется несколькими приложениями, каждое из которых может обновлять записи внутри него.

Вопрос: будет ли у меня прирост производительности app1 при использовании кэшей внутри моего приложения ( @Cacheable )? (Обратите внимание, что кэш находится внутри моего приложения, а не внутри базы данных, т.Е. Маскирует всю базу данных с помощью диспетчера кэша, такого как Redis)

Вот мои мысли:

1. Если другое приложение app2 изменяет запись в БД, как кэш внутри app1 узнает, что запись обновлена? Тогда мой app1 кэш устарел, не так ли? (пока оно не начнет обновляться после фиксированного цикла обновления 1 час)
2. если #1 верно, то означает ли это, что правильный способ настройки кэша должен маскировать всю базу данных каким-то менеджером кэша. Предназначен ли Redis для такого использования?

Итак, много вопросов.

Будет ли у меня прирост производительности в моем app1 за счет использования кэшей внутри моего приложения (@Cacheable)?

Вы всегда должны сравнивать его, но теоретически доступ к кэшу будет быстрее, чем к базе данных

Если другое приложение app2 изменяет запись в БД, как кэш внутри app1 узнает, что запись обновлена? Затем кэш моего app1 устарел, не так ли? (пока оно не начнет обновляться после фиксированного цикла обновления 1 час)

Он не будет обновляться, если вы не используете кластеризованный кэш. Ehcache, использующий кластер Terracotta, является таким кэшем. Но да, если вы используете базовый кеш приложения, он устареет.

если #1 верно, то означает ли это, что правильный способ настройки кэша должен маскировать всю базу данных каким-то менеджером кэша. Предназначен ли Redis для такого использования?

Теперь это становится незаметным. Я не эксперт по Redis. Но, насколько я знаю, Redis часто используется в качестве кэша, но на самом деле это база данных NoSQL. И это не будет впереди (опять же, насколько я знаю), это будет в стороне. Итак, вы сначала запросите Redis, чтобы узнать, есть ли там ваши данные, а затем вашу базу данных. Если доступ к вашей базе данных намного медленнее и у вас действительно хороший кэш, это повысит вашу производительность. Но, пожалуйста, проведите тест.

Реальные кэши (например, Ehcache) немного эффективнее. Они добавляют концепцию близкого кэширования. Таким образом, ваше приложение будет хранить записи кэша в памяти, а также на сервере кэша. Если запись обновлена, будет обновлен ближний кеш. Таким образом, вы получаете производительность кэша приложений, а также согласованность между серверами.