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

Question

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

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

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

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

1. Решение должно по крайней мере иметь клиентский API Java , который достаточно хорошо поддерживается, так как остальная часть приложения написана на Java, и мы являемся опытными разработчиками Java;
2. Решение должно быть полностью эластичным : должна быть возможность добавлять новые узлы без перезапуска других узлов в кластере;
3. Решение должно иметь возможность обрабатывать аварийное переключение .Да, я понимаю, что это означает некоторые накладные расходы, но общий размер обслуживаемых данных невелик (максимум 1 ГБ), поэтому это не должно быть проблемой.Под «отказоустойчивостью» я подразумеваю бесшовное выполнение без жесткого кодирования / изменения IP-адреса (ов) сервера, как в клиентах memcached, когда узел выходит из строя;
4. В идеале должна быть возможность указать степень перекрытия данных (например, сколькокопии одних и тех же данных должны храниться в кластере DSM);
5. Нет необходимости постоянно хранить все данные, но может потребоваться постобработка некоторых данных (например, сериализация вDB).
6. Цена .Очевидно, что мы предпочитаем бесплатный / открытый исходный код, но мы рады заплатить разумную сумму, если решение того стоит.В любом случае, платный 24-часовой контракт на поддержку является обязательным.
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-файлом.супер прост в использовании.Просто добавьте банку в ваш путь к классам.Взгляните на экран на главной странице.
8. Hazelcast строго соответствует.Вы никогда не сможете прочитать устаревшие данные.

Answer 2

Я предлагаю вам использовать 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 сервера!Он поддерживает режимы главный / подчиненный, часовой и кластерный сервер.Также поддерживается автоматическое обнаружение топологии кластерных / сторожевых серверов.Эта библиотека бесплатна и имеет открытый исходный код.

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

Answer 3

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

Answer 4

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

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

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

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

Answer 5

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

Answer 6

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

Answer 7

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

Answer 8

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

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