Синхронизация данных в сети - PullRequest
2 голосов
/ 14 ноября 2011

Мы разработали приложение C # WinForms, работающее на MS SQL Server. До сегодняшнего дня мы использовали очень простой самодельный OR-Mapper (использующий Reflection) с дешевым механизмом кэширования, реализованным с использованием шаблона синглтона. Пользователь запускает функцию «сброса». Архитектура представляет собой простой двухуровневый (клиент, сервер) три уровня (представление и логика на клиенте, MS SQL в качестве уровня данных на сервере).

Обычно мы загружаем около 300 строк и около 30 столбцов, которые меняются довольно часто (и некоторые другие таблицы, которые меняются редко). Различные экземпляры этого приложения работают на разных клиентских компьютерах, загружены одинаковые 300 строк и изменяют данные в случайной строке. Приложение обновит данные немедленно в базе данных. Прежде чем они это сделают, проверяется целостность, поэтому пользователь получает обратную связь, если что-то не так. Но для некоторых строк пользователь видит старые значения на экране, он должен вручную сбросить кэш, когда он хочет быть уверен, что обновленные данные.

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

Решения, которые я имею в виду:

  1. Использование OR-Mapper с общим кешем (например, NHibernate с кластерным кешем)
    • Открытые вопросы: созданы ли эти кеши L2 для клиентских приложений? Могу ли я запускать обновления пользовательского интерфейса, когда происходят изменения в кэше? Другие решения на базе OR-Mapper?
  2. Реализация другого уровня с использованием сервера приложений, перемещение логики на этот сервер приложений. Запустите только один экземпляр, который кэширует данные и отправляет события на объекты логики, которые уведомляют других клиентов об обновленных данных. Не кэшируйте какие-либо данные о клиентах.
    • Открытые вопросы: загрузка на сервер приложений? Накладные расходы на связь с сервером приложений? Объем работы по перемещению логической библиотеки DLL на сервер приложений ..? Источник данных для отчетов (напрямую / сервер приложений)?
    • Примерно так считает этот пользователь: https://stackoverflow.com/questions/7593884/what-technology-to-use-for-data-persistence-cache-and-synchronization-in-n-tier
  3. Добавить какие-то уведомления об изменениях данных на логическом уровне (широковещательное уведомление ...)
    • Открытые вопросы: Существующие библиотеки? Загрузить на SQL Server?
  4. Полностью другое решение?

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

Ответы [ 3 ]

3 голосов
/ 14 ноября 2011

Я хотел бы поделиться своим опытом здесь. По аналогичному сценарию, когда все клиенты были в одной корпоративной локальной сети. Я реализовал UDP-клиент (отправитель / получатель) в своем клиентском приложении, которое передавало «DataRefreshMessage» по адресу Network BroadCast всякий раз, когда клиент обновлял данные. И все другие клиенты обновляли свои представления после получения «DataRefreshMessage».

Я знаю, что UDP не является надежным, но был достаточно надежным для моих требований, и мое решение работает отлично.

1 голос
/ 14 ноября 2011

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

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

0 голосов
/ 14 ноября 2011

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

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

...