Допустим, у меня есть простая архитектура, в которой сеансы будут передаваться через базу данных, с несколькими внешними интерфейсами (скажем, F1 и F2), обращающимися к одному и тому же внутреннему интерфейсу.
Моя проблема заключается в том, что оба интерфейса будут получатьзапрос, соответствующий тому же сеансу: наивная реализация заставила бы сеанс перезаписывать друг друга (я смотрел на django, который, кажется, попадает в этот случай).Я мог бы попытаться спроектировать бэкэнд так, чтобы он гарантировал, что с данным сеансом может работать не более одного веб-интерфейса, но это кажется трудным сделать правильно, особенно если я хочу обрабатывать сбои веб-интерфейса.
Я могу 'Это не помогает, но я думаю, что дело в первую очередь патологическое (не должно быть более одного запроса на данный сеанс в любое время) и не стоит того, чтобы с ним разбираться, но у меня мало опыта в веб-разработке, поэтомуможет быть, я что-то упустил.Как обычно поступают с этим делом?
Возможные решения, которых я бы хотел избежать:
- Sticky session: это решение, которое я использую в настоящее время, и его трудно поддерживать, если у вас есть несколько балансировщиков нагрузки, и, что еще важнее, оно выходит из строя.в первую очередь против духа балансировки нагрузки.
- Размещение данных в cookie: по техническим причинам вне моего контроля я не могу использовать cookie.