Кратко: Heartbeat для клиентов, кластеризация сессий для Tomcat 6 и 7, новая Replicated Map, улучшенная WAN Replication, улучшенный Data Aggregation, функциональность EvictAll и LoadAll для IMap.
Продолжаем тестировать Hazelcast. В предыдущем посте мы познакомились с его очередями. А в этом мы более внимательно взглянем на его возможность распределенного выполнения задач.
Работать с данными гораздо эффективнее как можно ближе к ним, а не выкачивать «к себе», потом считать и\или изменять и отправлять обратно в распределенное хранилище. Именно такую возможность нам предоставляет Hazelcast в виде распределенной реализации ExecutorService. Можно управлять и тем, на каких серверах хранить данные, группируя их по общему ключу, и запускать задачи на нужных серверах, используя тот-же ключ.
Мы попытаемся выяснить — так ли это и есть ли какие подводные камни?
Многие из нас слышали о Hazelcast. Это удобный продукт, который реализует различные распределенные объекты. В частности: key-value хранилища, очереди, блокировки и т.д. К нему в целом применяются утверждения о распределенности, масштабируемости, отказоустойчивости и другие положительные свойства.
Так ли это применительно к его реализации очередей? Где границы их использования? Это мы и попытаемся выяснить.
Есть у нас задача связывать различные сервисы и существующие системы в управляемые процессы. Скорость нужна не космическая (т.е. не по биржевым котировкам отклик создавать), но зато процессов много и компонент (систем) которые нужно использовать тоже порядочно вырисовывается. Не хочется делать p2p связывание. Хочется чего-то красивого и управляемого.
Просмотрев рынок, было принято решение сделать реплику по мотивам Amazon Simple Workflow, так как использовать его напрямую мы не можем. Свойства фреймворка которые нам подходят:
