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

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

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

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

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

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

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

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

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

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

17.08.2008 02:57:46
Привет, я знаю, что это старый пост, но я просто смотрю на очень похожий сценарий. Вы не возражаете, чтобы я спросил, какой вариант вы выбрали в конце? спасибо
Sean 11.11.2012 11:01:48
5 ОТВЕТОВ
РЕШЕНИЕ

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

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

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

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

  1. nServiceBus от Udi Dahan
  2. Общественный транспорт Дрю Селлерс и Криса Паттерсона

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

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

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

20
23.05.2017 12:00:17

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

0
17.08.2008 04:07:34

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

1
21.08.2008 11:52:50

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

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

Это сильно недоразвитая часть SQL Server, которую стоит посмотреть.

1
2.09.2008 08:20:54

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

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

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

3
17.09.2008 01:53:31