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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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