Производительность Ehcache на большом кластере - PullRequest
5 голосов
/ 29 июля 2009

Я хотел бы использовать реплицированный кэш Ehcache, сначала в качестве бэкэнда для кэша второго уровня Hibernate, затем в качестве кэша для любых данных.

Я знаю, как работает распределенный кеш, такой как memcached, и знаю, что он может масштабироваться до больших кластеров, но я не могу понять, как репликация Ehcache ведет себя на больших кластерах.

  • Есть ли у кого-то указатель на какую-то информацию или какой-то ориентир?

Я обнаружил, что можно использовать многие стратегии репликации, такие как RMI, JGroups, JMS или Terracotta, а RMI и Terracotta кажутся наиболее популярными.

  • Как они сравниваются на больших кластерах?

Будет ли репликация убивать мои исполнения, когда я добавлю много узлов (например, несколько десятков)?

Ответы [ 3 ]

4 голосов
/ 04 мая 2010

Полностью реплицированный кеш будет работать, только если ваше приложение в основном для чтения. Реплицируемый кеш не может масштабироваться; передача обновлений на другие узлы снизит вашу производительность. Вам нужен секционированный кеш с резервными копиями. Секционированные кэши будут линейно масштабироваться даже для приложений с интенсивной записью.

Попробуйте Hazelcast ! это решение с открытым исходным кодом (лицензия Apache), решение для многораздельного кэширования для Java. Он поставляется со спящим плагином второго уровня.

Несколько десятков? Нет проблем. Демонстрация кластера узлов Hazelcast 100 может быть найдена здесь .

3 голосов
/ 30 июля 2009

Хорошим решением проблемы масштабирования кластера является понятие «репликация собеседника», когда данные реплицируются только для соседей каждого узла (как вы это определяете), а не для всех узлов. Вы получаете отказоустойчивость без проблемы масштабирования.

Насколько мне известно, ehcache этого не делает. Тем не менее, JBossCache делает, и это также интегрируется с Hibernate так же, как это делает ehcache.

...