Не стоит ли скрывать Hazelcast / Redis за REST-контроллером?

Question

Мы используем хранилище данных в памяти, возможно, Hazecast или Redis (технология пока не определена). Преимущественно хранилище данных в памяти будет использоваться в качестве поставщика Cache, но также и в качестве вычислительной платформы для запуска некоторой аналитики. Hazelcast / Redis предоставляет свои собственные нативные клиенты, которые позволяют тонко манипулировать содержимым сетки. Было бы излишним оборачивать экземпляры hazelcast / redis в Jetty, предоставляя интерфейс rest, и не обеспечивает прямой доступ для клиентских приложений к Hazelcast / Redis? Ответственность контроллера REST будет заключаться в том, чтобы получить запись, применить фильтр и, в случае отсутствия кэша, получить запись из базы данных, например.

Функциональность, предоставляемая приложениям, будет «Только чтение» + некоторые задания, включающие более одного ключа (аналитика).

Таким образом, в основном клиентские приложения не должны напрямую обновлять содержимое сетки. Или, если это произойдет, это будет очень редко и, возможно, будет результатом задания, которое в любом случае будет выполняться на выбранном решении в памяти.

Answer 1

Это действительно зависит от варианта использования. Говоря с точки зрения Hazelcast, многие из реализаций, которые мы видим, используют решение в памяти, чтобы уменьшить задержку и улучшить пропускную способность. Много усилий направлено на уменьшение количества сетевых переходов (например, с помощью возможностей Smart Client, которые отправляют запросы непосредственно члену кластера, на котором размещаются данные, а не через балансировщик нагрузки или главный узел). Контроллер REST вводит еще один сетевой скачок, а также дополнительное время обработки. И еще одна потенциальная точка отказа.

Так что я бы сказал, что если первостепенное значение имеет низкая задержка / высокая пропускная способность, я бы не стал вводить уровень REST.