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

Question

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

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

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

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

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

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

Answer 1

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

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

Answer 2

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

Answer 3

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

Answer 4

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

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

Answer 5

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

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

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

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

Answer 6

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

Answer 7

Я предлагаю вам использовать Redisson - На основе данных Redis на основе данных данных для 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

Answer 8

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