Как сохранить пользовательские запросы на том же сервере при использовании IIS NLB?
Одним из возможных решений является использование функции normalize-space() (работает даже в XSLT 1.0 ).
Он делает еще больше, то есть заменяет несколько белых символов внутри на одиночное пространство.
Чтобы применить его ко всем текстовым узлам, добавьте такой шаблон:
<xsl:template match="text)">
<xsl:value-of select="normalize-space()"/>
</xsl:template>
Но если у вас есть также шаблон идентификации , вышеуказанный шаблон должен быть в вашем сценарии ] после шаблон идентичности .
6 ответов
Думаю, вы ищете закрепленные сеансы. Однако липкие сеансы реализуются вашим балансировщиком нагрузки. Возможно, вам потребуется настроить внешний балансировщик нагрузки (BIG-IP, HAProxy и т. Д.), Который может выполнять липкие сеансы.
Нашел это и решил поделиться с другими:
Используйте функцию привязки клиентов. Когда привязка клиентов включена, балансировка сетевой нагрузки направляет все TCP-подключения на один и тот же узел кластера. Это позволяет поддерживать состояние сеанса в памяти хоста. Вы можете включить привязку клиентов в диалоговом окне «Добавить / изменить правила порта» в диспетчере балансировки сетевой нагрузки. Выберите привязку Single или Class C, чтобы гарантировать, что только один узел кластера будет обрабатывать все подключения, которые являются частью одного и того же клиентского сеанса. Это важно, если серверное приложение, работающее на узле кластера, поддерживает состояние сеанса (например, файлы cookie сервера) между подключениями. Для получения дополнительных сведений о привязке балансировки сетевой нагрузки см. Справку в оснастке «Балансировка сетевой нагрузки».
Вы можете легко это сделать, если ни один из ваших клиентов не использует распределенную прокси-систему:
В protieries кластера NLB на вкладке «правила порта» вы можете выбрать «фильтрация» режим "и близость: Вы не можете выбрать «нет», потому что у вас нет центральных сессий. Но «простой» будет перенаправлять каждого пользователя на один и тот же сервер, пока IP остается неизменным. Если вы, например, защищаете прокси-серверы AOL, то "класс C" может быть безопасным выбором (хотя, возможно, немного снижает балансировку нагрузки), потому что та же сеть класса C идет на тот же сервер.
Я думаю, что это легко реализовать от MS таким образом, что оба хоста знают, какой ip четный или нечетный, или какой триплет сети класса C четный или нечетный, и всегда распределяют нагрузку одинаково в зависимости от IP-адреса
Зачем вам это нужно? Если это связано с состоянием сеанса, вам следует настроить базу данных или внепроцессный сервер в общем месте, и все узлы должны ссылаться на него.
Я бы рассмотрел обратный прокси-сервер, который находится перед любым сервером и запоминает, какие внешние пользователи какие серверы используются.
Я знаю (используя его таким образом) Cherokee поддерживает проксирование IPHash, но уверен, что их гораздо больше.
Чтобы добавить к ответу Ллойда, вам все равно следует избегать использования сеанса в среде с балансировкой нагрузки. Вся цель использования сеанса - избежать вызовов базы данных; если вы в конечном итоге сохраняете данные сеанса обратно в базу данных, вы обычно ничего не получаете.
Причина в том, что 1. теперь вам нужно сделать 2 вызова базы данных для каждой загрузки страницы (получение и сохранение) и 2. эти данные теперь должны пройти через границы сериализации / десериализации. В большинстве случаев это оказывается более дорогостоящей операцией, чем просто получение данных, с которых вы хотели начать.
Теперь, к вашему собственному вопросу. У вас есть возможность сохранить данные сеанса в состоянии просмотра. При желании вы можете отказаться от сеанса и вместо этого использовать файлы cookie. Если вы пойдете по этому маршруту, обязательно зашифруйте их на выходе и расшифруйте при получении.