Spring + Redis + Mysql: стратегия кэширования

Я разрабатываю веб-приложение для медицинских целей, где пользователи могут записаться на прием к конкретному пациенту, врачу и учреждению. В каждом медицинском учреждении может быть N врачей, и календарь будет заполнен N приемами на каждого врача, а также будет отображаться доступность каждого врача (например, «Доктор Кто» работает по средам с 9:00 до 12:00 и с 15:00 до 18:00).

Для внешнего интерфейса я использую fullcalendar, а для внутреннего интерфейса используется Struts2 (контроллеры) + Spring (внедрение зависимостей ) + Спящий режим (ДАО).

Поскольку пользователь (обычно) должен загружать встречи с этой недели на месяц или два в будущем, и может быть от одного до N пользователей для каждого объекта, которые будут использовать это представление в течение длительного времени, я хотел бы кешировать встречи + доступность с помощью Redis, и я добавил в свой проект файл Spring data redis с Lettuce клиент. Идея состоит в том, чтобы использовать аннотации @Cacheable, @CachePut и @CacheEvict для методов DAO, обрабатывать действия пользователей, такие как список, создавать и обновлять встречи, избегая конфликтов между данными Redis и данными базы данных и других проблем параллелизма.

Мои вопросы:

  1. Это правильная стратегия?
  2. Должен ли я реализовать собственный генератор ключей, чтобы кэшировать встречи, связанные с идентификаторами учреждения и врача?

mysql java spring redis spring-data-redis
person IlGala    schedule 08.09.2016    source источник
comment
Шаблон соответствует модели программирования Spring Cache. Прежде чем приступить к кэшированию, вы должны запустить тесты производительности, чтобы выяснить, является ли кэширование решением или симптомом. Вы должны убедиться, что ваши объекты сериализуемы - вы не хотите кэшировать прокси-серверы JPA, а данные внутри модели данных. Что касается генераторов ключей: это зависит. Укажите выражение SpEL для создания неконфликтующих ключей и посмотрите, подходит ли оно.   -  person mp911de    schedule 08.09.2016

Ответы (1)


arrow_upward
0
arrow_downward

Отсюда я понял, что у вас есть отдельные данные о встречах и доступности, которые вы хотите кэшировать в Redis, чтобы можно было избежать ненужного вызова БД и повысить производительность.

У меня тут несколько моментов:

  1. Если у вас меньше данных, это не улучшит производительность, так как я предполагаю, что сервер Redis будет размещен удаленно, и у него также будут накладные расходы на сеть. Таким образом, вы можете выбрать любой кэш InMemory в качестве кеша Guava.

  2. Если есть интенсивное использование данных, тогда ваш redis будет полезен. Теперь я подхожу к первому пункту: правильная ли это стратегия? Я скажу да. Во-вторых, нужно ли вам реализовать собственный генератор ключей или нет, зависит от того, как вы храните данные в Redis уникальным образом. Redis - это (ключ, значение) хранилище. Поэтому я думаю, что встречи будут однозначно идентифицированы из (учреждения + идентификаторы врачей), которые вам нужны для реализации CustomKeyGenerator.

person Umesh    schedule 10.10.2016