репликация данных между сайтами в приложении j2ee

Question

у нас есть приложение J2EE, над которым мы все еще работаем. Он работает на базе данных Oracle. бизнес-уровень закодирован с помощью EJB 2.0 с расширенным клиентским интерфейсом.

Теперь приложение будет развернуто на нескольких сайтах. и каждый сайт будет создавать новые элементы (новые контракты и т. д.).

что мы хотим реализовать, это продублировать все новые элементы, добавленные в центральную БД, используя ту же схему БД, что и локальные.

Как вы думаете, что является наиболее эффективным способом для достижения этой цели?

Я думал о сериализации всех созданных новых элементов и отправке их на удаленный сайт для интеграции через очередь Java Message Service. этот подход хорош?

и также будут внесены некоторые изменения, которые будут скопированы обратно на спутники.

Answer 1

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

Таким образом, простой случай заключается в том, что просто используйте сообщения JMS из каждого места в центр.

Хорошая вещь в этом приборе состоит в том, что спутникам даже не нужно знать о структуре базы данных в центре, она может быть спроектирована совершенно разумно.

Вещи становятся более интересными, если вам также нужно копировать изменения обратно из центра в спутники. Большой вопрос, можем ли мы получить конфликты между изменениями в центре и изменениями на спутнике.

Простой случай: у любого элемента данных есть один «домашний». Например, исходный спутник - это место, где вносятся изменения. Или после создания центр - единственное место, где можно внести изменения. В этом случае мы можем рассматривать центр как «концентратор», он может распространять изменения на спутники. Простой JMS отлично подойдет для этого.

Случай немного сложнее: изменения могут быть сделаны где угодно, но только в одном месте за раз. Следовательно, мы можем ввести сомне-вид схемы блокировки. Я бы хотел иметь Центр в качестве владельца и использовать синхронные веб-сервисы для блокировки и обновления данных. Теперь мы связаны, но это необходимо, если мы хотим иметь окончательного владельца.

Довольно сложный случай: любой может изменить что угодно в любом месте без блокировки. Это что-то вроде «Действуй сначала, извинись позже» подход. Мы придерживаемся оптимистичного подхода, чтобы изменения не противоречили друг другу. Мы можем отправить изменения на утверждение в центр, и центр может либо использовать оптимистическую блокировку, либо объединить подход, не противоречащий изменениям. Я хотел бы сделать это, помещая в очередь изменения в инициаторе, но фактически обрабатывая их синхронными вызовами. Так что развязка спецификации изменений от наличия центра. Некоторые более сложные базы данных имеют возможности сравнения / слияния, которые могут помочь с этим.

Большие вопросы - это степень, в которой вы хотите быть связаны с доступностью центра и вероятностью конфликтующих изменений. Очень часто хитрый дизайн приложения может значительно снизить вероятность конфликта.