2016-09-08 6 views
0

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

Для передней части я использую fullcalendar, а бэкэнд выполнен с использованием Struts2 (контроллеров) + пружина (впрыск зависимостей) + спящий режим (DAO).

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

Мои вопросы:

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

Образец подходит для модели программирования Spring Cache. Перед началом кэширования вы должны выполнить тесты производительности, чтобы выяснить, является ли Кэширование решением или симптомом. Вы должны убедиться, что ваши объекты сериализуемы - вы не хотите кэшировать прокси-серверы JPA, а данные внутри модели данных. Что касается генераторов ключей: это зависит. Укажите выражение SpEL для создания неконфликтных ключей и посмотрите, подходит ли это. – mp911de

ответ

0

Что я понял отсюда, что у вас есть отдельные данные из назначений и доступности, которые вы хотите кэшировать в redis, чтобы избежать ненужного вызова db и повысить производительность.

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

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

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

Смежные вопросы