Java-решения для распределенных транзакций и/или данных, разделяемых в кластере

Question

Каковы наилучшие подходы к кластеризации/распространению приложения сервера Java? Я ищу подход, который позволяет масштабировать по горизонтали, добавляя больше серверов приложений и больше серверов баз данных.

• Какие технологии (технологии разработки программного обеспечения или конкретные технологии) вы предложили бы подходить к этой проблеме?
• Какие методы вы используете для создания слоя персистентности для масштабирования для многих читателей/писателей. Масштабировать транзакции приложений и масштабировать доступ к общим данным (наилучший подход - исключить общие данные, какие методы вы можете применить для устранения общих данных).
• Различные подходы, как представляется, необходимо в зависимости от того, для чтения или записи тяжелые ваши транзакции, но я чувствую, что если вы можете оптимизировать «написать» тяжелый приложение, которое будет также быть эффективным для «чтения»

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

В распределенной среде наиболее сложной проблемой всегда является использование нескольких транзакций для доступа к общим данным. Кажется, есть два общих подхода к параллельным транзакциям.

1. Explicit locks (который чрезвычайно подвержен ошибкам и медленным для координации между несколькими узлами в распределенной системе)
2. Software transactional memory (СТМ) АКА оптимистичный параллелизм, где выполняется откат транзакции во время фиксации, если он обнаруживает, что разделяет состояние (и транзакция позже может быть повторена). Какой подход лучше масштабируется и каковы компромиссы в распределенной системе?

Я исследовал масштабирование решений (и, в общих приложений, которые обеспечивают пример того, как в масштабе), таких как:

1. Terracotta - обеспечивает «прозрачный» масштабирование за счет расширения модели памяти Java на включают распределенную общую память с использованием механизма блокировки параллелизма Java (синхронизированный, ReentrantReadWriteLocks).
2. Google App Engine Java - Позволяет писать приложения на Java (или python), которые будут распределены между «облачными» серверами, на которых вы распространяете сервер, обрабатывающий транзакцию, и вы используете BigTable для хранения ваших постоянных данных (не знаете, как ваши транзакции, данных или обработчиков блокировок для эффективного масштабирования)
3. Darkstar MMO Server - Darkstar - это игровой сервер MMO с открытым исходным кодом с открытым исходным кодом Sun (массово многопользовательский онлайн), который они масштабируют транзакции в поточном транзакционном режиме, позволяя данной транзакции работать только на определенную сумму и и, если потребуется, он будет откатываться (вроде как транзакционная память программного обеспечения). Они занимались исследованиями в supporting a multi-node server setup для масштабирования.
4. Hibernate's optimistic locking - если вы используете Hibernate вы можете использовать их оптимистическую поддержку параллелизма для поддержки software transactional memory типа поведения
5. Apache CouchDB должен «масштаб» для многих чтения/записи децибел в конфигурации сетки естественно. (есть ли хороший пример того, как вы управляете блокировкой данных или обеспечиваете изоляцию транзакций?):
6. JCache - Масштабирование «чтения» тяжелых приложений путем кэширования результатов по общим запросам, которые вы можете использовать в приложении Google appengine для доступа к memcached и кэширования других часто читаемых данных.

Terracotta представляется наиболее полным решением в том, что вы можете «легко» изменить существующее серверное приложение для поддержки масштабирования (после определения объектов @Root и методов AutoLockRead/Write). Проблема состоит в том, чтобы действительно получить максимальную отдачу от распределенного приложения, оптимизация для распределенных систем на самом деле не такая мысль, которую вы, должно быть, должны ее проектировать, зная, что доступ к объектам потенциально может быть заблокирован сетевым вводом-выводом.

Для правильного масштабирования, кажется, что это всегда сводится к данным разделения и распределения нагрузки операций таким образом, что данное «исполнительный блок» (процессор ядро ​​-> Тема -> распределенная узел приложения -> DB мастер-узел)

Похоже, что для того, чтобы правильно распределить приложения, кластерирование должно быть в состоянии разделить ваши транзакции с точки зрения чтения/записи данных. Какие решения люди придумывают для распространения данных своих приложений (Oracle, Google BigTable, MySQL, хранилища данных) и вообще как вы управляете данными секционирования (многие мастера записи, с большим количеством прочитанных БД и т. Д.).

Что касается масштабирования уровня сохраняемости данных, то какой тип конфигурации масштабируется наилучшим образом с точки зрения разделения ваших данных на многие читатели/многие авторы (как правило, я разделял свои данные на основе данного пользователя (или любого другого основного объекта что обычно является вашей «корневой» объектной сущностью), принадлежащей одной основной БД)

Answer 1

Спасибо за красивое подведение итогов всех возможностей в одном месте.

Один способ здесь отсутствует. Это MapReduce-Hadoop. Если можно поставить проблему в парадигму MapReduce, это, пожалуй, наиболее широко доступное решение. Я также задаюсь вопросом, может ли шаблон Actionor Framework (JetLang, Kilim и т. Д.) Распространяться на кластер.

Answer 2

Не забывайте, что Erlang's Mnesia.

Mnesia предоставляет вам такие вещи, как транзакции, с которыми вы привыкли в обычной БД, но обеспечивает операции в реальном времени и отказоустойчивость. Кроме того, вы можете переконфигурировать вещи без простоя. Недостатком является то, что это резидентная база данных, поэтому вам нужно фрагментировать действительно большие таблицы. Самый большой размер стола - 4 ГБ.

Answer 3

• Не забудьте Coherence и GigaSpaces.

Answer 4

Возможно, это поможет slides. По нашему опыту я бы рекомендовал Oracle (Tangosol) Coherence и GigaSpaces как самую мощную инфраструктуру распространения данных и обработки там. В зависимости от точной природы проблемы может светиться один из них. Терракота также вполне применима для некоторых проблем.

Answer 5

Мысль я нашел большой Java кластеризация/Distributed платформу, хотел возобновить this-

Checkout http://www.hazelcast.com

Я запустил тестовые программы, это очень здорово, очень легкий и простой в использовании. Он автоматически обнаруживает членов кластера в конфигурации одноранговой сети. Возможности безграничны.

Answer 6

В то время как Oracle Coherence и многие другие предлагаемые решения хороши для обмена данными, вы указали только блокировку и STM как способы управления мутацией состояния в распределенной среде; те, как правило, довольно плохие способы масштабирования государственного управления. На другом сайте я недавно опубликовал следующее о том, как реализовать (например) счетчики последовательности:

Если вы смотрите на счетчик, то использование чего-то вроде Coherence EntryProcessor легко достигнет «один раз и только» -онсе "и HA для любого количества монотонно возрастающих последовательностей; вот вся реализация:

public class SequenceCounterProcessor 
     extends AbstractProcessor 
    { 
    public Object process(InvocableMap.Entry entry) 
     { 
     long l = entry.isPresent() ? (Long) entry.getValue() + 1 : 0; 
     entry.setValue(l); 
     return l; 
     } 
    } 

Yup. Вот и все. Автоматическая и бесшовная HA, динамическая масштабируемая эластичность, одноразовое поведение и т. Д. Выполнено.

EntryProcessor тип распределенного закрытия, что мы ввели в 2005 году

Как и в сторону, в Java 8 (пока не выпускают), проект Lambda представляет официальную поддержку закрытия в языке и стандартных библиотек.

В принципе, идея состоит в том, чтобы доставить закрытие на место «владельца» данных в распределенной среде. Когерентность динамически управляет владением данными, используя динамическое разбиение на разделы, позволяя распределенной системе загружать данные баланса на различные запущенные машины и узлы. Фактически, по умолчанию все это на 100% автоматизировано, поэтому вы никогда не говорите ему, куда помещать данные или сколько данных идет туда. Кроме того, имеются вторичные (и, возможно, третичные и т. Д.) Копии данных, управляемых другими узлами и другими физическими серверами, для обеспечения высокой доступности в случае сбоя процесса или смерти сервера. Опять же, управление этими резервными копиями по умолчанию полностью автоматическое и полностью синхронное, что означает, что по умолчанию система составляет 100% HA (т. Е. Без конфигурации).

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

несколько оптимизаций выше, включает добавление PortableObject интерфейсов ExternalizableLite & для оптимизированной сериализации и избежать сериализаций боксовых долго идя после «Сети готовы» форм данных непосредственно:

public Object process(InvocableMap.Entry entry) 
    { 
    try 
     { 
     BinaryEntry binentry = (BinaryEntry) entry; 
     long l = entry.isPresent() ? binentry.getBinaryValue() 
       .getBufferInput().readLong() + 1 : 0L; 
     BinaryWriteBuffer buf = new BinaryWriteBuffer(8); 
     buf.getBufferOutput().writeLong(l); 
     binentry.updateBinaryValue(buf.toBinary()); 
     return l; 
     } 
    catch (IOException e) 
     { 
     throw new RuntimeException(e); 
     } 
    } 

И так как он без гражданства, почему бы не получить один экземпляр, готовый пойти?

public static final SequenceCounterProcessor INSTANCE = 
     new SequenceCounterProcessor(); 

С его помощью из любой точки мира по сети так же просто, как одну строку кода:

long l = (Long) sequences.invoke(x, SequenceCounterProcessor.INSTANCE); 

Где «х» является любой объект или имя, которое идентифицирует конкретный счетчик последовательности вы хотите использовать , Для получения дополнительной информации см. Базу знаний Coherence по адресу: http://coherence.oracle.com/

Oracle Coherence - это распределенная система. Всякий раз, когда вы запускаете узел Coherence, он соединяется с другими узлами Coherence, которые уже запущены, и динамически формирует эластичный кластер. Этот кластер хранит данные в многораздельном, высокодоступном (HA) и транзакционно последовательном порядке, а хосты - операции (например, я показал выше), которые работают с этими данными один раз и только один раз.

Кроме того, в дополнение к возможности вызова любой из этих логических схем или доступа к любому из этих данных прозрачно из любого узла Coherence, вы также можете вызывать любую из этих логических схем или получать доступ к любой из этих данных прозрачно из любого процесса в сети (при условии аутентификации и авторизации, конечно). Таким образом, этот код будет работать с любым узлом кластера Coherence или с любого клиента (Java/C/C++/C#/.NET):

Ради полного раскрытия я работаю в Oracle. Мнения и мнения, выраженные в этом посте, являются моими собственными и не обязательно отражают мнения или мнения моего работодателя.