Java распределенные объекты с локальностью?

Question

Я оцениваю различные библиотеки распространения объектов Java (Terracotta, JCS, JBoss, Hazelcast ...) для сервера приложений, и у меня возникают проблемы с пониманием их поведения по различным осям.

Мои требования к распределенным объектам невелики - они сводятся к обмену сообщениями один-к-одному и один-ко-многим. Это еще не все, но в остальном мы просто используем JDBC, и я предполагаю, что я могу создать перед этим кеш, используя любую из доступных библиотек.

Я бы хотел систему, которая распределяет объекты и демонстрирует свойства локальности - иными словами, сервер, который захватывает объект, имеет тенденцию удерживать его без лишней связи с другими узлами. Hazelcast выглядит просто (и одноранговый это хорошо), но, похоже, требует равномерного распределения объектов по всем узлам.

Я бы хотел сохранить объекты, желательно прозрачно. Я планирую использовать EC2, поэтому у меня есть возможность временного, бесплатного, ограниченного локального хранилища (диска) и постоянного, несвободного, неограниченного хранилища (S3). Было бы здорово не беспокоиться об ошибках OutOfMemory.

Мне нравится простота и "магия" терракоты, но она пугает пчел из меня. Кроме того, чтобы по-настоящему масштабировать, вы должны тратить $$$$, в противном случае вы общаетесь с одним концентратором.

Я дешевый и хочу что-то не только бесплатное, но и зрелое, с большой базой пользователей.

Спасибо за любой вклад.

Answer 1

Терракота, кажется, идеально подходит для вашей ситуации.

• Его просто настроить
• его можно настроить на постоянство (используйте том EBS для EC2)
• он тесно интегрирован с Ehcache (фактически Терракота купила Ehcache) для высокой производительности распределенного кэширования
• бесплатное предложение отлично масштабируется для нескольких клиентов.

Просто начните играть с ним.Могу поспорить, вам понравится.Чтобы ослабить страх перед производительностью, просто запустите сквозной тест для передачи сообщений.Это не должно занимать больше, чем день вашего времени.

Я должен признать, что я не использовал терракоту в течение года, и что я не знаю других, которые вы предложили.

Answer 2

Да Hazelcast будет распределять ваши объекты по кластеру.Однако вы можете включить ближний кеш, если хотите снизить стоимость связи.http://www.hazelcast.com/documentation.jsp#MapNearCache

Answer 3

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

1) Терракота демонстрирует локальность - и, вероятно, является лучшей системой по сравнению с упомянутыми вами.Объекты доставляются в локальную JVM только по запросу.Блокировка для чтения или записи выполняется с использованием лизингового механизма.Это означает, что если вы демонстрируете идеальную локальность в вашей системе, то вы будете испытывать очень незначительную нагрузку на сеть.

2) Terracotta обеспечивает постоянное сохранение диска из коробки - в версии OSS (вам не нужно платить $$$$)

3) Почему это тебя так пугает?Просто используйте EHCache в качестве кэша или Hibernate 2-го уровня.Его невероятно легко настроить и использовать.

4) Да, Terracotta FX требует от вас оплаты (за серверы горизонтального масштабирования).Тем не менее, я хотел бы предположить, что если у вас есть система, которая в основном читается и демонстрирует истинную локальность, то я не думаю, что у вас возникнут проблемы с получением масштаба, который вы ищете.С Terracotta 3.2 производительность Hibernate 2-го уровня кэша составляет 100 000 операций в секунду при использовании 8 серверов приложений и одного сервера Terracotta при соотношении чтения / записи 100/0 и 12 000 операций в секунду при использовании той же конфигурации при отношении чтения / записи 95/5.

(я только что выступил с докладом для SD-форума Bay Area об этих числах, так что мне это пригодилось)

Answer 4

Кстати, неясно, что вы ищете (обмен сообщениями - это не то же самое, что кластеризация / распределенные объекты).

Если вы ищете обмен сообщениями в Java, я рекомендую вам взглянуть на RabbitMQ (он основан на Erlang, но это не имеет значения).