Фоновый рабочий процесс с WCF (кэширование)

Question

Мне поручено построить процесс, который будет компенсировать задержки репликации в нашей системе LDAP. В настоящее время существует один сервер записи и 4 сервера чтения. После записи записи на сервер записи в системе может возникнуть задержка до 4 секунд, прежде чем запись будет реплицирована на серверы чтения. Поэтому, если я вызову службу «A», которая обновляет запись, а затем сразу же после этого нажмет на службу «B», которая должна прочитать эту запись, данные будут устаревшими.

Чтобы решить эту проблему, я планировал создать кэширующие веб-сервисы, чтобы никакие приложения не взаимодействовали напрямую с базой данных, а только через сервис кэширования. Служба будет хранить все создания, обновления и удаления в кэше (предположительно, List<ModelObject>). Записи CRUD-R должны оставаться в кэше не менее четырех секунд. Затем, когда служба «B» пытается прочитать, служба кэширования проверяет кэш перед выполнением операции чтения в базе данных.

Итак, мой вопрос состоит из двух частей. 1) Является ли это возможным решением, и если нет, какие проблемы вы видите? 2) Как бы я сделал обслуживание кеша в службе WCF. Другими словами, есть ли способ инициировать фоновый рабочий поток, который очищает записи из кэша, возраст которых составляет 4 секунды?

Answer 1

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

Звучит как правильное решение для меня.

.NET включает в себя несколько библиотек кэширования, чтобы вам было проще.Вот мои любимые:

http://www.infoq.com/news/2010/05/Runtime.Caching http://msdn.microsoft.com/en-us/library/system.web.caching.cache.aspx

Другими словами, есть ли способ инициировать фоновый рабочий поток, который очищает записи из кэша, которые4 секунды?

Вам не нужно.Просто установите expirationTime (сейчас + 4 секунды), когда вы добавляете элемент в кеш.

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

Answer 2

Что касается # 1, я бы сказал, что это возможно, хотя создание собственного слоя кэширования может иметь свои трудности и подводные камни. Вдобавок ко всему, я не могу думать ни о чем, кроме того, что вы размещаете всю нагрузку только на одном сервере кэширования (в отличие от 4 распределенных серверов LDAP, которые могут обрабатывать нагрузку запроса).

Что касается # 2, я бы порекомендовал вам проверить Блок приложения для кэширования корпоративной библиотеки , я полагаю, что он обладает всеми необходимыми вам функциями, включая очистку, основанную на времени, продолжительности и т. Д.