Кэширующие решения для конфигурации с несколькими веб-серверами?

В службе конфигурации используется модель распределенного кэширования, которая является частью .NET. Образец приложения Stocktrader. Это фреймворк, который позволяет запускать несколько узлов с централизованным управлением конфигурацией, балансировкой нагрузки и распределенным кэшированием. Вы можете реализовать сервис конфигурации как есть или просмотреть код и выбрать то, что вам подходит. Стоит посмотреть.

Когда я прослушал подкаст-интервью Скотта Хансельмана с командой StackOverflow, у меня осталось впечатление, что a. они использовали какое-то кэширование и б. они почти ничего не знали о том, что они делали в этом отношении, и повозились с несколькими вариантами, а затем написали один или два поста в блоге.

В настоящее время они, похоже, довольно нерешительно используют кэширование на стороне клиента (например, короткие сроки действия изображений), и я думаю, что они используют много кэширования пользовательского режима ASP.NET, и я не могу сказать, используют ли они IIS кэширование в режиме ядра. (Кажется, они тоже не смогли сказать об этом Скотту.)

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

Вы должны подумать, прежде чем использовать что-то вроде memcached.

• Кэширование может скрыть от вас проблемы с производительностью («у вас медленно выполняется запрос? просто закэшируйте его и не беспокойтесь об исправлении!»)
• Инвалидация устаревших данных — это кошмар.
• Вы можете провести дни в погоне за ошибками, которые будут устранены при очистке кеша, и это загрязнит вашу кодовую базу.

Я не говорю, что не надо этого делать, но ТЯЖЕЛО подумайте, прежде чем делать.

Если вы можете получить достаточную производительность, добавив пару * дополнительных машин (что, я думаю, может сделать stackoverflow), сделайте это и не беспокойтесь о кэшировании. В долгосрочной перспективе это будет намного дешевле.

* примечание Я не говорю 100 машин.