Кэш уровня кластера для хранения ответов службы REST с синхронизацией
Я знаю, что это не очень конкретно, но я был бы благодарен за любые предложения.
Согласно руководству системного администратора, ClaimCenter полностью использует механизм кэширования, если пользователь возвращается к одному и тому же экземпляру сервера через разные HTTP-запросы, но для этого требуется, чтобы балансировщик нагрузки всегда направлял запросы на один и тот же сервер ClaimCenter, и только это обеспечивает настоящую горизонтальную масштабируемость.
Можно ли настроить кеш уровня кластера для временного хранения ответов службы REST и сделать его полностью синхронизированным? То есть можно ли определить глобальный кеш, который будет использоваться всеми серверами в кластере, и чтобы серверы рассылали все новые ответы другим членам кластера сразу после их вычисления?
Если нет, то будет ли достаточно кэша типа LoadingCache<K,V>, специфичного для экземпляра?
Ответы 2
Я считаю, что кэширование, выполняемое каждым отдельным узлом (сервером), - это кэширование только объектных компонентов, полученных из БД, а не ответов REST. Каждый узел имеет кеш bean-компонентов, которые либо удаляются при обновлении этого bean-компонента (любым узлом существует связь между узлами для удаления bean-компонентов, когда один узел обновляет объект), либо примерно через 30 минут, когда bean-компонент становится устаревшим (я думаю время настраивается).
Раньше я видел этот вопрос пару раз у клиентов, и проблема обычно заключается в том, что портал ClaimCenter вызывает API REST ClaimCenter. Обычно происходит одно из двух:
- В балансировщике нагрузки не включен закрепленный сеанс, поэтому каждый вызов API направляется на случайный узел, который, возможно, ранее не загружал bean-компоненты в кеш, поскольку предыдущий вызов API был направлен на другой узел.
- В балансировщике нагрузки включен закрепленный сеанс, но он может видеть только пользователя интеграции, используемого порталом для вызова REST API ClaimCenter (балансировщик нагрузки не может видеть учетные данные пользователя портала). В результате каждый вызов с портала направляется балансировщиком нагрузки на один узел. Это также не идеально, поскольку может привести к перегрузке одного узла.
Решение обычно состоит в том, чтобы включить закрепленный сеанс на балансировщике нагрузки и обеспечить разделение трафика в соответствии с учетными данными пользователя портала, а не пользователя интеграции, который используется для аутентификации между порталом и ClaimCenter.
Я думаю, что, безусловно, возможно создать какой-то глобальный кеш, в котором будут храниться ответы REST, но я бы не рекомендовал это. Почти наверняка Guidewire отметит это как несоответствие и технический долг.
Надеюсь, это поможет. Если что-то неприменимо к вашей ситуации, обновите свой вопрос, и я буду рад обновить свой ответ.
Я также должен добавить, что хранение ответов REST API в кеше кажется простым, но открывает множество проблем с параллелизмом. Что, если сущность (или сущности), из которой ответ JSON извлекает данные, обновится? Собираетесь ли вы затем искать в кеше каждого узла недействительные ответы API и удалять эти ответы? Это может показаться очень неэффективным дополнением к каждой отдельной транзакции пакета для ClaimCenter. Определенно лучше всего настроить балансировщик нагрузки так, чтобы он мог наиболее эффективно направлять вызовы API и использовать преимущества кэширования объектов OOTB.
Все это имеет смысл, но применимо ли это и к запросам строк?
Ах да, запросы строк не будут храниться в кеше приложения. См. эту документацию (docs.guidewire.com/self-managed/cc/1023/integration/integration/…). Что на самом деле делает этот API, вызывающий проблемы с производительностью? Это API, который выполняет поиск на основе некоторых критериев ввода? Раньше мне приходилось возвращать ошибку «слишком много результатов» обратно в приложение-потребитель и заставлять разработчиков портала отображать сообщение о том, что было возвращено слишком много результатов. Буду рад помочь, если вы предоставите более подробную информацию.
По сути, API предназначен для того, чтобы предоставить системе-потребителю доступ к данным заявок, но результаты должны быть выведены на страницы (подумайте о больше ). Проблема в том, что некоторые критерии поиска на самом деле нельзя интерпретировать как есть, потому что внешняя система — это та же самая система, о которой я упоминал здесь. То есть две системы используют совершенно разные модели данных, и это очень усложняет запрос.
Да, кажется, я понимаю. Вызывает ли приложение-потребитель API ClaimCenter каждый раз, когда пользователь запрашивает следующую «страницу» результатов? Вероятно, было бы лучше получить полные результаты из API ClaimCenter, а затем сохранить результаты в памяти приложения-потребителя, чтобы при запросе следующей страницы результатов не было повторного вызова ClaimCenter. Кроме того, я понимаю, что это не по теме, но, вероятно, также следует обсудить, как отменить старые системы претензий. Похоже, что ИТ-организация тратит много ресурсов на поддержание работы этих старых систем.
Да, каждая страница извлекается посредством отдельного вызова службы.
Если вы пишете «болтливый» API, Guidewire рекомендует использовать привязку сеансов или закрепленные сеансы, чтобы повысить эффективность кэша базы данных. Guidewire Cloud уже делает это для порталов.
Фактически, если вы выполняете обновления связанных объектов и не включаете закрепленные сеансы, у вас, скорее всего, возникнут исключения одновременного изменения данных, поскольку обновления кэша базы данных не происходят мгновенно.
Спасибо, но это самоуправляемая реализация. Извините, я не упомянул об этом в вопросе.
Кроме того, я думаю, что параллелизм здесь не является проблемой, поскольку обработчик никогда не обновляет какие-либо объекты.
То, что вы описываете во втором абзаце, — это то, что делает ClaimCenter. Раньше он транслировался по сети каждые несколько секунд. Теперь он обновляет таблицу базы данных узлов, обновленную с момента последней трансляции. Проблема в сетевом трафике и времени. Сделать это в режиме реального времени невозможно из-за задержки в сети. Существуют некоторые инструменты кэширования, но как только вы выходите за пределы кластера, у вас возникают другие сложности.