Выбор распределенного решения для общей памяти
У меня есть задача создать прототип для в широком масштабе масштабируемого приложения для распределенной общей памяти (DSM). Прототип только служил бы подтверждением концепции, но я хочу провести свое время наиболее эффективно путем выбора компонентов, которые использовались бы в действительном решении позже.
Цель этого решения состоит в том, чтобы взять ввод данных из внешнего источника, взболтать его и сделать результат доступным для многих frontends. Те "frontends" просто взяли бы данные из кэша и служили бы ему без дополнительной обработки. Объем хитов frontend на этих данных может буквально быть миллионами в секунду.
Сами данные очень энергозависимы; это может (и делать) изменение вполне быстро. Однако frontends должен видеть "старые" данные, пока новейшее не обрабатывалось и кэшировалось. Обработка и запись сделаны единственным (избыточным) узлом, в то время как другие узлы только считывают данные. Другими словами: никакое поведение читки.
Я изучал решения как memcached однако, этот конкретный не выполняет все наши требования, которые упоминаются ниже:
- Решение должно, по крайней мере, иметь клиент Java API, который обоснованно хорошо сохраняется, поскольку остальная часть приложения записана в Java, и мы - закаленные Java-разработчики;
- Решение должно быть полностью эластичным: должно быть возможно добавить новые узлы, не перезапуская другие узлы в кластере;
- Решение должно смочь обработать обработку отказа. Да, я понимаю, что это означает немного служебные, но полный подаваемый размер данных не является большим (1G макс.), таким образом, это не должно быть проблемой. "Обработкой отказа" я имею в виду бесшовное выполнение без IP-адреса (IP-адресов) сервера жесткого кодирования/изменения как в memcached клиентах, когда узел понижается;
- Идеально должно быть возможно указать степень наложения данных (например, сколько копий тех же данных должно быть сохранено в кластере DSM);
- Нет никакой потребности постоянно хранить все данные, но могла бы быть потребность последующей обработки некоторых данных (например, сериализация к DB).
- Цена. Очевидно, мы предпочитаем свободный/с открытым исходным кодом, но мы рады заплатить разумную сумму, если решение стоит того. Всегда, заплаченный 24hr/day контракт на поддержку необходимость.
- Все это должно быть размещено в наших дата-центрах, таким образом, предложения SaaS как Amazon SimpleDB вне объема. Мы только рассмотрели бы это, если никакие другие опции не будут доступны.
- Идеально решение было бы строго единым (как в ОГРАНИЧЕНИИ); однако, возможную последовательность можно рассмотреть как опцию.
Заранее спасибо за любые идеи.
5 ответов
Взгляните на Hazelcast . Это чистая Java, продукт с открытым исходным кодом (лицензия Apache), хорошо масштабируемый в оперативной памяти. Он предлагает поддержку 7X24. И он действительно решает все ваши проблемы. Я попытался объяснить каждую из них ниже:
- У него есть собственный Java-клиент.
- Это 100% динамика. Добавляйте и удаляйте узлы динамически. Не нужно ничего менять.
- Опять же, все динамично.
- Вы можете настроить количество резервных узлов.
- Hazelcast поддерживает настойчивость.
- Все, что предлагает Hazelcast, бесплатно (с открытым исходным кодом) и предлагает поддержку корпоративного уровня.
- Hazelcast - это одиночный jar-файл. супер проста в использовании. Просто добавьте jar в свой путь к классам. Посмотрите на экран на главной странице.
- Hazelcast строго согласован. Вы никогда не сможете прочитать устаревшие данные.
Взгляните на кластеризацию JVM Terracotta, это OpenSource;) У него нет API, хотя он работает эффективно на уровне JVM, когда вы сохраняете значение в реплицированном объекте, оно отправляется на все другие узлы. Даже блокировка и все эти вещи работают прозрачно и без добавления нового кода.
Возможно, вы захотите ознакомиться с Java-специфичными решениями, такими как Coherence: http://www.oracle.com/global/ru/products/middleware/coherence/index.html
Однако я считаю такие решения слишком сложными и предпочитаю использовать решения типа memcached. Большим недостатком memcached для вашей цели является отсутствие блокировки записей, как кажется, и нет встроенного способа репликации данных для отказоустойчивости. Именно поэтому я бы рассмотрел хранилища данных типа "ключ-значение". Многие из них полностью удовлетворят ваши потребности.
Вот список хранилищ данных типа "ключ-значение", которые могут помочь вам в решении вашей задачи: http://www.metabrew.com/article/anti-rdbms-a-list-of-distributed-key-value-stores. Просто выберите то, с которым вам удобно работать.
Задумывались ли вы об использовании стандартного решения для обмена сообщениями, такого как rabbitmq ? RabbitMQ - это реализация протокола AMQP с открытым исходным кодом.
Ваше приложение более или менее похоже на систему публикации / подписки. Узел Publisher выполняет обработку и помещает сообщения (обработанные данные) в очередь на серверах. Подписчики могут получать сообщения с сервера различными способами. AMQP разделяет производителя и потребителя сообщений и очень гибок в том, как вы можете комбинировать две стороны.
Я делаю аналогичный проект, но вместо этого нацелен на платформу .NET. Помимо уже упомянутых решений, я думаю, вам стоит взглянуть на ScaleOut StateServer и Alachisoft NCache . Боюсь, что ни одна из этих альтернатив не является дешевой, но, по моему мнению, они более безопасны, чем открытый исходный код для коммерческих решений.
- Оба предоставляют клиентские API Java, хотя я только экспериментировал с API .NET.
- StateServer поддерживает автоматическое обнаружение новых узлов кэша, а NCache имеет консоль управления, куда можно добавлять новые узлы кэша.
- Оба должны иметь возможность беспрепятственно обрабатывать отработку отказа.
- StateServer может иметь 1 или 2 пассивные копии данных. NCache предлагает больше топологий кэширования на выбор.
- Если вы имеете в виду сквозную / обратную запись в базу данных, которая доступна в обоих.
- Я понятия не имею, сколько кеш-серверов вы планируете использовать, но вот полные ценовые характеристики: ScaleOut StateServer Alachisoft NCache
- Оба устанавливаются и настраиваются локально на вашем сервере, и у них обоих есть управление графическим интерфейсом.
- Я не уверен, что именно включает в себя строго согласованное, поэтому оставлю это вам для исследования.
В целом, StateServer - лучший вариант, если вы хотите пропустить настройку каждой мелочи в кластере кеша, в то время как NCache предлагает на выбор очень много функций и топологий кеширования.
В зависимости от поведения данных по отношению к клиентам (если данные читаются много раз одним и тем же клиентом), может быть хорошей идеей смешать локальное кэширование на клиентах с распределенным кэшированием в кластере (доступно как для NCache и StateServer), просто мысль.