Это 189-я оригинальная статья Вуконга.

Привет, я Вуконг.

фон

Недавно у меня появилось требование к проекту:

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

липкость сеанса

Согласно приведенным выше требованиям, это фактически способ реализации липкости сеанса.

липкость сеанса（Session Affinity): также называется сохранением сеанса (Session Персистентность) или персистентность сеанса (Session липкость) — это своего рода балансировка. стратегия нагрузки, при которой все запросы от одного и того же клиента направляются в одну и ту же обратную сторону. частьсервера. Целью этого является обеспечение согласованности данных или состояния сеанса пользователя на нескольких серверах. Обычно липкость Сеанс реализуется посредством идентификационной информации клиента. Наиболее распространенной идентификационной информацией является клиент. IP адрес или файл cookie.

Взаимодействие клиента и сервера показано на рисунке ниже:

План реализации

Nginx может маршрутизировать запросы на разные серверы на основе IP-адреса клиента. Как показано ниже:

У трех клиентов разные фиксированные IP-адреса. После того, как запрос клиента достигает Nginx, Nginx хеширует IP-адрес клиента, вычисляет хэш-значение и сопоставляет его с вышестоящим сервером.

Сервер сгенерирует и сохранит период действия сеанса, а затем вернет идентификатор сеанса клиенту. Клиент перенесет идентификатор сеанса в следующий раз, когда отправит запрос. Запрос по-прежнему будет отправлен на последний сервер, и сервер проверит, существует ли идентификатор сеанса клиента и находится ли он в пределах срока действия.

директива ip_hash

Вам нужно использовать его здесь директива ip_hash。

Давайте сначала посмотрим, как использовать ip_hash.

Syntax: ip_hash;
Default:
Context: upstream

Давайте посмотрим на объяснение официального сайта:

Specifies that a group should use a load balancing method where requests are distributed between servers based on client IP addresses. The first three octets of the client IPv4 address, or the entire IPv6 address, are used as a hashing key. The method ensures that requests from the same client will always be passed to the same server except when this server is unavailable. In the latter case client requests will be passed to another server. Most probably, it will always be the same server as well.

То, что мы перевели, означаетip_hashИспользуется для указания метода балансировки нагрузки, который должна использовать группа.,Какие запросы на основе клиента IP Адреса распределяются между серверами. клиент IPv4 адрес или весь IPv6 Первые три октета адреса используются в качестве хэш-ключа. Этот метод гарантирует, что запросы от одного и того же клиента всегда доставляются на один и тот же сервер, если только этот сервер не доступен. В последнем случае запрос клиента будет передан на другой сервер. Скорее всего, это тоже всегда будет один и тот же сервер.

Примечание 1. Адреса IPv6 поддерживаются, начиная с версий 1.3.2 и 1.2.2.

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

Примечание 2: В версии 1.3.1 и 1.2.2 До, ip_hash è Конфигурацию веса нельзя использовать вместе.

Пример использования

Пример конфигурации ip_hash выглядит следующим образом:

upstream backend {
    ip_hash;

    server backend1.example.com;
    server backend2.example.com;
    server backend3.example.com down;
    server backend4.example.com;
}

Вот подробное объяснение этой конфигурации:

• ip_hash：этоNginxинструкция,это говоритNginxиспользоватьклиентизIPадрес, чтобы решить, куда направить запросзадняя частьсервера. Это означает, что все запросы с одного и того же IP-адреса будут отправляться на один и тот же задний адрес. частьсервер。
• server：существовать upstream backend Внутри блока перечислены несколько задних частьсервера. В этом примере,Есть четыресервер：backend1.example.com、backend2.example.com、backend3.example.com и backend4.example.com。
• backend3.example.com down：这里из down Ключевое слово указывает на то, что backend3.example.com отмечен как «Вниз» означает временное отключение сервера и прекращение приема новых подключений. Это можно использовать для временного удаления определенного сервера из балансировки. нагрузка снята для технического обслуживания или ремонта.

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

Интересная проблема на Github

Я увидел интересную проблему на Github для ip_hash:

https://gist.github.com/banjin/cf8d890591aa6c16d09e4ebfa6471284

Привет. У меня есть вопрос. После того как IP-адрес хеширован и назначен машине A, если машина A помечена, будет ли этот IP-адрес назначен другой машине, например машине B? Если машина A восстановится позже, будет ли этот IP-адрес возвращен машине A с машины B? Эквивалентно ли это обмену данными между A и B? Предположим, что IP-адрес клиента — 192.168.1.10.

Результаты моего теста следующие:

• Сервис -> down после, 192.168.1.10 Отправленные запросы будут закреплены за B。
• Сервис-> удалять После падения 192.168.1.10 Отправленные запросы будут перераспределены A справиться.

Каковы подводные камни ip_hash?

1. 不适用于负载不均衡из情况：ip_hash主要用于существовать多个задняя между частями серверов реализуется липкость сеанса,Но он не будет учитывать нагрузку на сервер. Если нагрузка не сбалансирована между серверами,Определенный сервер может обрабатывать больше запросов.,При этом другой сервер может простаивать. Это может привести к неравномерному использованию ресурсов.

2. Ограниченная балансировка нагрузкиспособность：ip_hash并不是一个全功能избалансировка решение по нагрузке. Он полагается исключительно на IP-адреса клиентов без учета работоспособности или производительности сервера. Если вам нужна более сложная балансировка нагрузки Стратегия,Возможно, потребуется рассмотреть другие модули Nginx.,нравитьсяleast_connилиngx_http_upstream_module,Либо используйте специализированное устройство балансировки нагрузки.

3. Может привести к напрасной трате ресурсов. Если IP-адрес клиента имеет очень высокую частоту запросов в течение определенного периода времени, все его запросы будут перенаправлены на один и тот же внутренний сервер. Это может привести к тому, что некоторые серверы будут сильно загружены, а другие — слабо, что приведет к пустой трате ресурсов.

4. Не применимо к динамическому выделению IP-адресов: если клиент использует динамические IP-адреса.,И IP-адреса могут измениться в течение короткого периода времени (например,,через DHCP),Такip_hashможет не применяться,Потому что IP-адрес дляклиента может меняться во время сеанса.,Приводит к потере состояния сеанса.

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

Подвести итог

ip_hash В решении проблемы липкости может творить чудеса в сценах сеанса, но ip_hash Также возникнут некоторые проблемы, например, дисбаланс нагрузки.

- END -