Синхронизация интрасети и веб-данных - PullRequest
Новая
       22

Синхронизация интрасети и веб-данных

0 голосов
/ 17 ноября 2009

Я только начинаю разбивать приложение .NET и его базу данных SQL Server на две системы - интрасеть и общедоступный веб-сайт.

Различные таблицы базы данных необходимо будет синхронизировать между двумя базами данных по-разному, например:

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

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

Я не совсем уверен, с чего начать все это, поскольку, похоже, существует много разных способов достижения этого. На какие технологии и стратегии мне стоит обратить внимание?

Какие-нибудь советы?

Ответы [ 2 ]

2 голосов
/ 17 ноября 2009

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

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

2 голосов
/ 17 ноября 2009

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

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

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

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

...