Интересно, что произойдет, если, скажем, мы используем балансировщик нагрузки HAProxy с сохранением (фиксированные сеансы), а сервер выйдет из строя (или мы захотим уменьшить масштаб).
Согласно с их документы:
При сохранении, если сервер выйдет из строя, HAProxy перенаправит пользователя на другой сервер.
Моя проблема с определением «внизу» здесь.Если мы запускаем это в Kubernetes, означает ли «вниз», что модуль больше не отвечает или просто не исправен (как при сбое на зонде живучести), или это означает, что модуль больше не работает и новый был создан вместо него?
Я спрашиваю об этом, потому что пытаюсь выяснить, как лучше всего поддерживать упорядоченную доставку эффективным способом, поэтому рассмотрим этот пример:
- HTTP-клиент обращается к балансировщику нагрузки с помощью HTTP-запроса (R1) и не имеет сеанса.
- Балансировщик нагрузки использует алгоритм для определения лучшего сервера (S1), отправляет R1 на S1 и добавляет файл cookie, когда получает ответ от сервера (S1).
- Следующие запросы имеют файл cookie, поэтому LB уже знает, какой сервер должен получить запрос.
- Теперь клиент отправляет другой запрос (R2), но сервер (S1) не отвечает вовремя (но модуль все еще работает и пытается записать этот запрос в Kafka в виде сообщения)
- Поскольку клиент не получил ответа вовремя, он собирается повторить попытку R2 еще раз, но LB увидел, что S1 не отвечает, поэтому на этот раз он выберет новый сервер (S2).
- Запрос R2 теперь выполняется успешно, потому что S2 был в порядке и денди
- Клиент отправляет R3, и это удается, потому что S2 снова в порядке.
- Тем временем теперь S1 восстановился и перед завершением успевает записать R2 в Kafka, нарушая порядок сообщений (потому что теперь у нас есть R1, R2, R3, R2)
Отсюда и мои вопросы выше. Есть ли что-нибудь, даже если не HAProxy, что может добиться этого? Возможно, балансировщик нагрузки Kubernetes? Или мне нужно будет написать собственный балансировщик нагрузки, который должен будет отслеживать модули и проверять, не отвечают ли они просто или полностью исчезли?
К вашему сведению, я совершенно согласен пожертвовать доступностью ради согласованности (теорема CAP) и отклонить запрос. Я также стараюсь избегать использования фиксированного количества серверов, поскольку было бы идеально, если бы они увеличивались и уменьшались в зависимости от трафика.Главное было бы НЕ маршрутизировать запрос, если сервер, который ранее обслуживал этого клиента, все еще где-то болтается, чтобы не нарушать порядок сообщений.
Любые идеи будут приветствоваться.
