Добрый день .

До этого все приложения были не "кластерные" вопросов таких не было ... но появилась вот такая архитектура :


Фронтом идет nginx - за ним кластер из двух docker контейнеров в них jetty в нем webapp за ними кластер MariaDB

сессия пользователя хранится в базе так http://projects.spring.io/spring-session/



так вот смущает такой кейс :

nginx - отправляет запросы на ноды по принципу роундробина - с get запросами все ок (я не вижу подводных камней) !

вопрос с не идемпотентными запросами?

Вот пришел на node1 jetty1 post запрос и нода умерла в этот момент (2 вариант успела положить в сессию что то и не успелва)-

Этот запрос потерян или нет?

Сейчас пользователь в браузере висит и ничего не происходит ( в момент отправки POST / GET ) положили ноду ...

все что он делает это - жмет F5 - и продолжает работать - его даже не выбросит на логин итд ...


Вопросы :

1) чем потенциально опасна такая схема ?
2) Как ретраить не идемпотентные запросы ?
3) не лучше ли организовать stick на nginx ? - чтобы один пользователь работал с одной нодой - если она упадет перешел на другую
4) jetty - работают ничего не знаю о том что они в докере - Это не jetty cluster
5) proxy_next_upstream - спасение ?
6) http://nginx.org/ru/docs/http/ngx_http_upstream_module.html#sticky

Цель не потерять ни одной транзакции :)


ps

если сессия в базе это плохо - то будет кластер на Redis

BlazkowiczAtum1вопрос с не идемпотентными запросами?
Вопросительный знак есть, а вопроса нет.

Atum1Вот пришел на node1 jetty1 post запрос и нода умерла в этот момент (2 вариант успела положить в сессию что то и не успелва)-
Этот запрос потерян или нет?
Очень много размытой терминологии.
Если сессию реплицировать синхронно, то это капец как дорого.
Если сессию реплицировать асинхронно, то таки да, после положительного отклика, но до репликации можно потерять запрос.

Atum11) чем потенциально опасна такая схема ?
Проблемами с репликацией сессии, которая отъедает кучу ресурсов кластера.

Atum12) Как ретраить не идемпотентные запросы?
Повторять запросы может только клиент. Решения два вижу я. Либо коммитить транзакцию после сихронизации, либо валидировать транзакции дополнительными запросами.

Atum13) не лучше ли организовать stick на nginx ? - чтобы один пользователь работал с одной нодой - если она упадет перешел на другую
sticky session вполне себе нормальное решение. Никто особо не старается одного юзера раскидать на все ноды.

Atum14) jetty - работают ничего не знаю о том что они в докере - Это не jetty cluster

И вопрос в чем?

Ну якобы можно делать репликацию сессии средствами самого jetty

Atum1Цель не потерять ни одной транзакции :)

Мы за ценой не постоим? А цель кластера какая?

Atum1если сессия в базе это плохо - то будет кластер на Redis
Есть 100500 способов реплицировать сессию. Общая база, это таки single point of failure.

Спасибо

Да

один Post Запрос с транзакцией мы можем потерять видимо - это как раз и будет наше SLA 99.95

ибо шаг в 99.999 - где будет репликация всего и вся это стоимость решения вырастает на порядок или два.



Там более у нас фронтальная система - за ней по мимо базы еще стоит некоторый бэкенд на rest api



и с нашей системы есть определенны правила работы с этим бэкендом : не получив от него ответа (получив 500 )
мы ретраем пост запрос до него по оговоренной логике .

BlazkowiczЕсть 100500 способов реплицировать сессию. Общая база, это таки single point of failure.


там кластер ,но точка одна.

WGAAtum1Цель не потерять ни одной транзакции :)Предлагаю взглянуть на проблему с другой стороны.

Запись в сессию и в рабочую БД - это не одна транзакция. Как можно гарантировать, что выполняя две транзакции, данные не придут в несогласованное состояние? Ответ - никак.



Тут не понял . можно пояснить ?

Usman,

Добрый день .



Есть ещё вопрос : в классической схеме все вроде бы ясно:

Сессия в базе и таким образом запрос идёт из браузера на haproxy и может быть обработан любым аппсервером так как у него сессионный ключ в базе ( имеется кластер jetty docker контейнеров )


А как быть если клиент работает через websocket? В такой схеме соединение двухсторонне и постоянное через wss, нужно каким то образом его поддерживать ??? Или оно будет каждый раз перестанавливаться?

вадяAtum1А как быть если клиент работает через websocket? В такой схеме соединение двухсторонне и постоянное через wss, нужно каким то образом его поддерживать ??? Или оно будет каждый раз перестанавливаться?а можно и просто продлять сессию http. при каждом сообщении серверу.

Решение нужно для вебсокетов .

вадяAtum1,
тут есть ещё одна фишка с использование ws - возможность сервере вести "передачу по своей инициативе"
кода http сессия оканчивается -переводить клиента на страницу входа/авторизации
для этого достаточно отловить окончание сессии http и отправить клиенту нужное сообщение.
N секунд(минут,часов) бездействия (без обращения к серверу) и переход на страницу входа.


Не совсем понял , есть пример кода на github e ?