Как синхронизировать две связанные, но отдельные системы друг с другом?

Question

Мой текущий проект разработки имеет два аспекта.Во-первых, существует общедоступный веб-сайт, на котором внешние пользователи могут отправлять и обновлять информацию для различных целей.Затем эта информация сохраняется на локальном SQL-сервере в центре colo.

Второй аспект - это внутреннее приложение, которое сотрудники используют для управления теми же записями (концептуально) и предоставления обновлений статуса, утверждений и т.д.Это приложение размещено в корпоративном брандмауэре с собственной локальной базой данных SQL Server.

Две сети соединены аппаратным VPN-решением, которое является приличным, но, очевидно, не самым быстрым в мире.

Две базы данных похожи и используют множество одинаковых таблиц, но они не совпадают на 100%.Многие таблицы с обеих сторон очень специфичны как для внутреннего, так и для внешнего применения.

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

Стоит отметить, что чем чаще происходят эти обновления в режиме "реального времени", тем лучше.Не то чтобы это должно быть мгновенно, просто достаточно быстро.

До сих пор я думал об использовании следующих типов подходов:

1. Двунаправленная репликация
2. Интерфейсы веб-служб с обеих сторон снабжены кодом для синхронизации изменений по мере их внесения (в режиме реального времени).
3. Веб-сервис взаимодействует с обеих сторон с кодом для асинхронной синхронизации изменений (используя механизм организации очередей).

Есть какой-нибудь совет?Кто-нибудь сталкивался с этой проблемой раньше?Нашли ли вы решение, которое хорошо сработало для вас?

Answer 1

Я полагаю, что это довольно распространенный сценарий интеграции.Лично я считаю, что решение для асинхронного обмена сообщениями с использованием очереди идеально.

Вы должны быть в состоянии обеспечить синхронизацию почти в реальном времени без накладных расходов или сложности чего-то вроде репликации.

Синхронные веб-службы не идеальны, потому что ваш код должен быть очень сложным, чтобы обрабатывать сценарии сбоев.Что происходит, когда одна система перезапускается, в то время как другая продолжает публиковать изменения?Получает ли отправляющая система тайм-ауты?Что он с ними делает?Если вы не готовы потерять данные, вам понадобится какая-то транзакционная очередь (например, MSMQ) для получения уведомлений об изменениях и обеспечения того, чтобы они попадали в другую систему.Если какая-либо из систем не работает, изменения (передаваемые в виде сообщений) будут просто накапливаться, и как только соединение будет установлено, перезапускаемый сервер обработает все сообщения, находящиеся в очереди, и догонит их, что значительно упростит достижение целостности системы.

Есть несколько инструментов с открытым исходным кодом, которые действительно могут упростить вам задачу, если вы используете .NET (особенно если вы хотите использовать MSMQ).

1. Nсервисный автобус автор : Уди Дахан
2. Общественный транспорт авторы : Дрю Селлерс и Крис Паттерсон

Существуют также коммерческие продукты, и если вы рассматриваете коммерческий вариант, смотрите здесь смотрите список опций в .NET.Конечно, WCF может выполнять асинхронный обмен сообщениями с использованием привязок MSMQ, но такой инструмент, как NServiceBus или MassTransit, предоставит вам очень простой API отправки / получения или Pub / Sub, который сделает выполнение ваших требований очень простым.

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

Возможно, вы также захотите рассмотреть возможность чтения Уди Дахан'веду свой блог, слушаю некоторые из его подкастов.Вот такие еще несколько хороших ресурсов чтобы вы начали.

Answer 2

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

Во-первых, вам нужно отслеживать изменения, если вы можете использовать SQL 2008 (даже экспресс-версии достаточно, если ограничение в 2 ГБ не является проблемой), это значительно облегчит проблему, просто включите отслеживание изменений в базе данных и каждой таблице.Мы используем SQL Server 2008 в головном офисе с расширенной схемой и SQL Express 2008 на каждом сайте с подмножеством данных и ограниченной схемой.

Во-вторых, вам нужно отслеживать свои изменения, Службы синхронизации отлично справляется с этой задачей и поддерживает использование шлюза WCF для доступа к основной базе данных.В этом примере вам нужно будет использовать Синхронизация с помощью клиента SQL Express пример в качестве отправной точки обратите внимание, что он основан на SQL 2005, поэтому вам нужно будет обновить его, чтобы воспользоваться преимуществами функций отслеживания изменений в 2008 году.По умолчанию службы синхронизации используют SQL CE на клиентах, чего, я уверен, в вашем случае недостаточно.Вам понадобится служба, работающая на вашем веб-сервере, которая периодически (при желании, может быть, каждые 10 секунд) запускает метод Synchronize().Это сообщит вашей основной базе данных об изменениях, внесенных локально, а затем запросит у сервера все внесенные там изменения.Вы можете настроить код get и apply SQL для вызова хранимых процедур, а также добавить обработчики событий для обработки конфликтов (напримерОбновление клиента против обновления сервера) и разрешайте их соответствующим образом на каждом конце.

Answer 3

У нас есть магазин в качестве клиента, с тремя магазинами, подключенными к одному и тому же VPN
В двух магазинах есть компьютер, работающий в качестве "сервера" для этого магазина, а в третьем есть "главная база данных".
Чтобы синхронизировать все с мастером, у нас нет лучшего решения, но оно работает:на выделенном компьютере запущено приложение, которое проверяет временную метку каждой записи в каждой таблице двух хранилищ, и если она отличается от той, что была при последней синхронизации, оно копирует результаты
Обратите внимание, что это работает в обоих направлениях.То есть.если вы обновите продукт в основной базе данных, это изменение распространится на два других магазина.Если у вас есть новый заказ в одном из магазинов, он будет передан "мастеру".
С помощью некоторой оптимизации вы можете синхронизировать все магазины примерно за 20 минут

Answer 4

Недавно я добился большого успеха с SQL Server Service Broker, который предлагает надежные, устойчивые асинхронные обмены сообщениями "из коробки" с очень небольшими затратами на реализацию.

• Его быстро настроить, и по мере того, как вы узнаете больше, вы сможете использовать некоторые из более продвинутых функций.
• Неизвестный большинству, он также входит в состав настольных версий, поэтому его можно использовать как систему обмена сообщениями на рабочей станции
• Если у вас уже есть навыки работы с T-SQL, их можно использовать, поскольку весь код для чтения и записи сообщений выполнен на SQL
• Это происходит ослепительно быстро

Это сильно недооцененная часть SQL Server, и на нее стоит обратить внимание.

Answer 5

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