Проблема балансировки нагрузки при реализации асинхронного HTTP с REST

Question

Я читал об асинхронных HTTP и REST и о том, как вы можете вернуть ресурс после POST-входа, чтобы инициировать долгосрочную задачу, а затем опросить этот ресурс, чтобы получить статус задачи.Интересно, что произойдет, если у меня есть две машины с балансировкой нагрузки, одна из которых получит начальный POST, а другая - последующий GET.Второй не будет знать о том, что запустил первый, если я не использую общее хранилище для сохранения состояния задачи.Как я могу предотвратить это, если я хочу сохранить состояние только на клиенте?

Answer 1

Когда вы выполнили процедуру POST, чтобы инициировать долгосрочную задачу, вы действительно должны вернуть URI в заголовке местоположения, чтобы указать на запущенную задачу. например,

POST /LongTasks
=>
201 Created
Location: /RunningTask/233


GET /RunningTask/233
=> 
Content-Type: text/plain

InProgress

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

Однако, если эти два сервера балансировки нагрузки доступны напрямую, вы можете сделать

POST http://example.org/LongTasks
=>
201 Created
Location: http://serverA.example.org/RunningTask/233


GET http://serverA.example.org/RunningTask/233
=> 
Content-Type: text/plain

InProgress

Answer 2

То, на что вы ссылаетесь, обычно называется привязанностью клиента. По сути, вы сохраняете cookie для клиента, чтобы балансировщик нагрузки знал, на какой сервер приложений фермы отправлять запрос. Так как get и post будут распространять cookie, запросы для одного пользователя всегда будут отправляться на один и тот же сервер. Вы можете узнать больше о некоторых конфигурациях (используя Apache в качестве обратного прокси-сервера для Tomcat) здесь: http://docs.codehaus.org/display/JETTY/Configuring+mod_proxy

Тем не менее, использование общего хранилища часто легче, если у вас нет значительной фермы бэкэнд-процессоров. Например, на нескольких машинах использование memcached в качестве упрощенного хранилища для информации о состоянии - неплохая идея, и я успешно использовал ее как для данных сеанса, так и для данных состояния.

Обратите внимание, что использование обратного прокси-сервера решает проблему SSL (где вы не можете увидеть куки с аппаратным балансировщиком нагрузки из-за шифрования). RP кодирует / декодирует и передает данные на внутренний сервер. Mod_proxy в Apache - это обычный выбор, хотя nginx готовится к работе. Вы также можете использовать IP-интерфейс. Однако однажды я понял, что это была плохая идея, когда я понял, что вся очень крупная городская школьная система читается как один IP из-за их системы фильтрации:)