Спасибо! Интересное решение — а вы такой подход где-то пробовали уже?
Сравнение не делали, к сожалению. Решили, что когда на нагрузочном тестировании увидим, что упираемся именно в генерацию ID, тогда и вернемся к вопросу.
1) А вы подкладываете в Hazelcast свои jar-ы (domain-классы) для сериализации/десериализации/выборке по индексу? Удается ли в случае изменений в таких классах обновляться без остановки кластера?
У нас сейчас не получается подложить jar на каждую ноду по очереди (hazelcast начинает сыпать исключениями). Мы пробовали вместо jar-ов в classpath работать через Portable, но очень много однообразного кода readPortable/writePortable/portableFactory, вернулись на Java-сериализацию. Когда нужно переподложить jar-ы — останавливаем кластер. В 3.8 заявлено «User Code Deployment: Load your new classes to Hazelcast IMDG members dynamically without restarting all of them». Но интересно, как при таких высоких SLA как у Яндекс-денег, вы на 3.5 справляетесь с обновлениями этих jar-ов без остановки кластера? Или обходитесь стандартными Java-классами?
2) Как вы настроили параметры
hazelcast.client.max.no.heartbeat.seconds,
hazelcast.heartbeat.interval.seconds,
hazelcast.client.invocation.timeout.seconds
и другие таймауты
?
По дефолту они выставлены в довольно большие значения и при потере ноды hazelcast уходит в себя. В статье видел упоминания про 400 мс ограничение на клиенте. Получается, кластер у вас тормозит, когда нода выпадает, но со стороны клиента вы как-то в итоге повторяете ту же самую операцию?
3) Можете рассказать подробнее про потерю нод, датацентра? Как быстро кластер выкидывает ноду и продолжает работать? Как вы тестировали? (про потерю датацентра видел, но интересует с точки зрения простоев и SLA).
4) Сколько памяти вы даете каждой ноде? Где-то видел рекомендацию про не более 4Гб.
Сравнение не делали, к сожалению. Решили, что когда на нагрузочном тестировании увидим, что упираемся именно в генерацию ID, тогда и вернемся к вопросу.
1) А вы подкладываете в Hazelcast свои jar-ы (domain-классы) для сериализации/десериализации/выборке по индексу? Удается ли в случае изменений в таких классах обновляться без остановки кластера?
У нас сейчас не получается подложить jar на каждую ноду по очереди (hazelcast начинает сыпать исключениями). Мы пробовали вместо jar-ов в classpath работать через Portable, но очень много однообразного кода readPortable/writePortable/portableFactory, вернулись на Java-сериализацию. Когда нужно переподложить jar-ы — останавливаем кластер. В 3.8 заявлено «User Code Deployment: Load your new classes to Hazelcast IMDG members dynamically without restarting all of them». Но интересно, как при таких высоких SLA как у Яндекс-денег, вы на 3.5 справляетесь с обновлениями этих jar-ов без остановки кластера? Или обходитесь стандартными Java-классами?
2) Как вы настроили параметры
hazelcast.client.max.no.heartbeat.seconds,
hazelcast.heartbeat.interval.seconds,
hazelcast.client.invocation.timeout.seconds
и другие таймауты
?
По дефолту они выставлены в довольно большие значения и при потере ноды hazelcast уходит в себя. В статье видел упоминания про 400 мс ограничение на клиенте. Получается, кластер у вас тормозит, когда нода выпадает, но со стороны клиента вы как-то в итоге повторяете ту же самую операцию?
3) Можете рассказать подробнее про потерю нод, датацентра? Как быстро кластер выкидывает ноду и продолжает работать? Как вы тестировали? (про потерю датацентра видел, но интересует с точки зрения простоев и SLA).
4) Сколько памяти вы даете каждой ноде? Где-то видел рекомендацию про не более 4Гб.