Блог

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

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

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

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

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