Выбор решения распределенной общей памяти

У меня есть задача создать прототип для масштабируемого масштабируемого приложения с распределенной общей памятью (DSM). Прототип будет служить только доказательством концепции, но я хочу потратить свое время наиболее эффективно, выбрав компоненты, которые будут использоваться в реальном решении позже.

Цель этого решения - взять данные из внешнего источника, отбросить его и сделать доступным результат для ряда интерфейсов. Эти "интерфейсы" просто берут данные из кеша и обслуживают его без дополнительной обработки. Количество обращений к этим данным в реальном времени может составлять миллионы в секунду.

Сами данные очень нестабильны; он может (и делает) меняться довольно быстро. Однако интерфейсы должны видеть "старые" данные до тех пор, пока новейшие не будут обработаны и не будут кэшированы. Обработка и запись выполняются одним (избыточным) node, в то время как другие узлы только считывают данные. Другими словами: без чтения.

Я искал такие решения, как memcached, однако этот конкретный не выполняет все наши требования, которые перечислены ниже:

  • Решение должно по крайней мере иметь API-интерфейс Java, который достаточно хорошо поддерживается, поскольку остальное приложение написано на Java, и мы являемся опытными разработчиками Java;
  • Решение должно быть полностью эластичным: должно быть возможно добавлять новые узлы без перезапуска других узлов в кластере;
  • Решение должно иметь возможность обрабатывать failover. Да, я понимаю, что это означает некоторые накладные расходы, но общий размер данных для обслуживания невелик (максимум 1G), поэтому это не должно быть проблемой. Под "отказоустойчивостью" я подразумеваю бесшовное выполнение без жесткого кодирования/изменения IP-адресов (серверов) сервера, как в memcached-клиентах, когда node опускается;
  • В идеале должно быть возможно указать степень перекрытия данных (например, сколько копий одних и тех же данных должно храниться в кластере DSM);
  • Нет необходимости постоянно хранить все данные, но может потребоваться постобработка некоторых данных (например, сериализация в БД).
  • Цена. Очевидно, что мы предпочитаем бесплатный/открытый источник, но мы счастливы заплатить разумную сумму, если решение того стоит. В любом случае, оплачиваемый контракт на 24 часа в сутки является обязательным.
  • Все это должно быть размещено в наших центрах обработки данных, поэтому предложения SaaS, такие как Amazon SimpleDB, недоступны. Мы бы рассматривали это только в том случае, если бы не было других вариантов.
  • В идеале решение будет строго последовательным (как в CAP); однако возможная консистенция может рассматриваться как вариант.

Заранее благодарим за любые идеи.

Ответы

Ответ 1

Посмотрите Hazelcast. Это чистая Java-версия с открытым исходным кодом (лицензия Apache), масштабируемая в сетях с данными в памяти. Он предлагает поддержку 7X24. И он решает все ваши проблемы, которые я попытался объяснить каждому из них ниже:

  • Он имеет собственный Java-клиент.
  • Это 100% динамический. Добавление и удаление узлов динамически. Не нужно ничего менять.
  • Снова все динамично.
  • Вы можете настроить количество резервных узлов.
  • Поддержка поддержки Hazelcast.
  • Все, что предлагает Hazelcast, бесплатное (с открытым исходным кодом), и оно предлагает поддержку уровня предприятия.
  • Hazelcast - это один файл jar. супер легкий в использовании. Просто добавьте jar в свой путь к классам. Посмотрите на экранную трансляцию на главной странице.
  • Hazelcast строго согласован. Вы никогда не сможете читать устаревшие данные.

Ответ 2

Я предлагаю вам использовать Redisson - Redis, основанный на данных Data Grid для Java. Реализует (BitSet, BloomFilter, Set, SortedSet, Map, ConcurrentMap, List, Queue, Deque, BlockingQueue, BlockingDeque, ReadWriteLock, Semaphore, Lock, AtomicLong, CountDownLatch, Publish / Subscribe, RemoteService, ExecutorService, LiveObjectService, SchedulerService) поверх Redis сервер! Он поддерживает режимы master/slave, sentinel и cluster server. Также поддерживается обнаружение топологии серверов кластера/дозорных серверов. Этот lib является бесплатным и открытым исходным кодом.

Прекрасно работает в облаке благодаря поддержке AWS Elasticache

Ответ 3

В зависимости от того, что вы предпочитаете, я непременно последую за другими, предлагая Hazelcast, если вы находитесь в AP из теоремы CAP, но если вам нужен CP, я бы выбрал Redis

Ответ 4

Возможно, вы захотите проверить решения, специфичные для 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 Просто выберите тот, который вам удобнее.

Ответ 5

Взгляните на кластеризацию Terracotta JVM, это OpenSource;) Он не имеет API, хотя он работает на уровне JVM, когда вы сохраняете значение в реплицированном объекте, оно отправляется на все остальные узлы. Даже блокировка и все эти вещи работают прозрачно и без добавления нового кода.

Ответ 6

Я делаю аналогичный проект, но вместо этого настраиваю платформу .NET. Помимо уже упомянутых решений, я думаю, вы должны взглянуть на ScaleOut StateServer и Alachisoft NCache. Я боюсь, что ни одна из этих альтернатив не будет дешевой, но они более безопасны, чем открытый источник для коммерческих решений, согласно моему мнению.

  • Оба предоставляют API-интерфейсы Java, хотя я только играл с .NET API.
  • В StateServer реализовано самообнаружение новых узлов кэша, а у NCache есть консоль управления, в которую могут быть добавлены новые узлы кеша.
  • Оба должны иметь возможность легко обрабатывать отказоустойчивость.
  • StateServer может иметь 1 или 2 пассивных копии данных. NCache имеет больше кеширующих топологий для выбора.
  • Если вы имеете в виду write-through/write-behind для базы данных, доступной в обоих.
  • Я понятия не имею, сколько серверов кешей вы планируете использовать, но вот полные спецификации цены: ScaleOut StateServer Alachisoft NCache
  • Оба устанавливаются и настраиваются локально на вашем сервере, и оба они имеют управление графическим интерфейсом.
  • Я не уверен, что именно строго соответствует, поэтому я оставлю это для вас, чтобы расследовать..

В целом, StateServer - лучший вариант, если вы хотите пропустить настройку каждой мелочи в кластере кэша, в то время как NCache имеет очень много функций и кеширование топологий на выбор.

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

Ответ 7

Указанный пример использования подходит для Netflix Hollow. Это реплицированный кэш только для чтения с одним производителем и несколькими потребителями.

Ответ 8

Не могли бы вы использовать стандартное решение для обмена сообщениями, например rabbitmq? RabbitMQ - это реализация с открытым исходным кодом AMQP protocol.

Ваше приложение кажется более или менее похожим на систему публикации/подписки. Издатель node - это тот, который выполняет обработку и помещает сообщения (обработанные данные) в очередь на серверах. Подписчики могут получать сообщения с сервера различными способами. AMQP отделяет производителя и потребителя от сообщений и очень гибко в том, как вы можете объединить обе стороны.