Стратегии nHibernate в веб-ферме

Question

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

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

Некоторые сценарии, о которых я думал ...

1) Несколько серверов IIS, один сервер WCF. При такой настройке сервер WCF будет единственной точкой отказа, но не будет проблем с кэшированием nHibernate или параллелизмом базы данных.

2) Несколько серверов IIS, каждый со своим сервисом WCF. Это устраняет единственную точку отказа, но теперь nHibernate на одном компьютере не будет знать об изменениях базы данных, сделанных на другом компьютере.

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

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

Answer 1

Я бы предложил не делать кэширование, пока не станет проблемой кэширование.Ваша БД будет выполнять свое собственное кеширование, чтобы вы не раз искали одни и те же данные, поэтому единственное, о чем вам нужно беспокоиться, это данные по проводам.Судя по твоему описанию, проблем у тебя не будет.Если вы когда-нибудь попадете на этап, на котором вы это делаете, используйте распределенный кеш - если ваши серверы будут кешировать отдельно, это вызовет проблемы с данными при обновлении.

Answer 2

я что-то здесь упускаю, я не вижу проблемы с nhibernate на веб-серверах. Кэш приложения не будет проблемой, поскольку каждый ящик nhibernate будет хранить свой собственный кэш, который будет заполнен из хранилища данных. посмотрите на создание таблицы, которую можно отслеживать по причинам, связанным с обновлением кэша. мы делали это, используя класс CacheDependency в .net 2.0, который обнаруживал изменения в столбце и затем удалял соответствующий элемент из кэша. таким образом, если пользователь вставляет новый продукт, кэш будет отброшен, и следующий вызов для получения продуктов снова загрузит кэш. это старо, но проверьте: http://msdn.microsoft.com/en-us/magazine/cc163955.aspx#S2 для понятия. веселит