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

Question

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

Чтобы решить эту проблему, я планировал создание кэширующих веб-сервисов, чтобы приложения не связывались напрямую с базой данных, а скорее через службу кеширования. Служба будет хранить все создания, обновления и удаления в кеше (предположительно 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 значение (Now + 4 seconds), когда вы добавляете элемент в кеш.

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

Answer 2

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

Что касается # 2, я бы порекомендовал вам проверить Enterprise Library Caching Application Block, я считаю, что это имеет все необходимые функциональные возможности, что вам нужно, в том числе откачкой на основе времени, продолжительности и т.д.