Является ли Memcached взаимозаменяемым с ASP.NET State Server?

Question

Я использую службы ASP.NET и WCF в среде веб-сервера с балансировкой нагрузки, используя Memcached на уровне служб.

Я также хотел заменить использование ASP.NET State Server (для Session State) на Memcached. Теперь я боюсь, что это не очень хорошая вещь, потому что из того, что я понимаю, Memcached - это кеш-сервер, а не сервер состояний, это правда?

Если я правильно понимаю, Memcached не распространяет данные на другие узлы в ферме Memcached. Вместо этого используется специальный алгоритм хеширования, чтобы определить, какой из узлов в ферме содержит данные запрошенного ключа. тогда как ASP.NET State Server распределяет данные как можно скорее, когда они были добавлены, чтобы предотвратить единую точку отказа.

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

Так я не могу полагаться на Memcached только для хранения данных о состоянии сеанса? Если я не могу, то я не понимаю, как часто Memcached сравнивают и рассматривают как альтернатива использованию ScaleOut StateServer и ASP.NET State Server, поскольку это действительно государственные серверы, это другое дело, верно?

Теперь я немного не уверен в том, что является лучшим подходом для высокопроизводительного распределенного состояния сеанса в ферме веб-серверов.

Спасибо

Answer 1

http://www.codeplex.com/memcachedproviders имеет поставщика состояния сеанса для asp.net, который хранит значения в memcached. Предоставляет возможность резервного копирования данных сеанса в SQL Server. Как сказал йогман, данные сеанса хранятся как одно значение. Если произойдет выселение, весь сеанс для этого пользователя будет потерян, и пользователь будет перенаправлен на экран входа в систему. Memcached не высвобождает никакие данные до истечения срока действия, если ему не хватает места для новых данных.

Answer 2

Memcached в настоящее время не поддерживает зеркалирование данных, он только дает возможность разделить ваши записи по нескольким серверам, чтобы попытаться предотвратить их переполнение. Это работает либо путем хеширования вашего ключа с адресом сервера, либо с помощью согласованного алгоритма хеширования (libketama).

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

Memcached определенно используется для кеширования, хотя об этом автор пишет в статье в Jinux Journal. Это действительно предназначено только для оптимизации операций чтения, в конце концов, любые данные, которые вас интересуют, должны храниться в базе данных.

Answer 3

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

А как насчет других, возьмем, например, stackoverflow, динамические данные на странице в зависимости от пользователя: ник пользователя, номер репутации, заработанные значки, разрешение оставлять комментарий. Они часто являются результатом нескольких JOIN для нескольких таблиц базы данных.

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

Конечно, любые записи в соответствующую информацию пользователя должны сделать недействительным соответствующий сеанс в memcached.