Кэширование данных и уведомление клиентов об изменениях данных в ASP.NET

Question

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

Изменение, на которое я ссылаюсь в этом сообщении, выглядит следующим образом:

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

Это означает, что, если у клиентов будет свой собственный локальный кэш, они должны будут каким-либо образом уведомляться (и сначала регистрироваться для уведомлений). В противном случае они всегда будут получать данные от службы GlobalServices.

Мне нужен ваш образованный совет, ребята:

1) Is it a good idea to keep a local cache on the clients to begin with?
2) If we do decide to keep a local cache on the clients, would you use
   SqlCacheDependency to notify the clients, or would you use WCF for 
   notifications (each might have its cons and pros)

Большое спасибо,

Avi

Answer 1

Мне нравится звук вашей SqlCacheDependency, но я отвечу на это с другой точки зрения, так как я работал с командой над похожим сценарием. Мы создали базу данных master и использовали триггеры для создания XML-представлений данных, которые были изменены в master, и сохранили их в таблице TransactionQueue с небольшим количеством метаданных о том, что изменилось, когда и кто их изменил. Клиентские базы данных будут периодически проверять очередь на предмет интересующих ее элементов, обрабатывать XML и обновлять собственные таблицы по мере необходимости.

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

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

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

Удачи! Тим