Commit protocol

Question

Я создаю веб-службу REST, которая получает запрос и должна возвращать «Ok», если операция была выполнена правильно. Как я могу разобраться с возможностью свободного соединения, возвращая это сообщение «Хорошо»?

Например, система, подобная Amazon SimpleDB.

1) Он получает запрос. 2) Обработать запрос (хранить и реплицировать содержимое). 3) Верните сообщение с подтверждением.

Если соединение было потеряно между этапами 2 и 3, клиент считает, что операция не была успешной, а затем отправляется снова.

Спасибо!

Answer 1

Система, которую я рассмотрел в начале этого года, имела процесс, подобный этому. Решение, которое они реализовали, состояло в том, чтобы клиент ответил на сообщение фиксации и очистил флаг в записи в этой точке. Был периодический процесс, который проверял каждые N минут, и если запись существовала, которая была завершена, но что клиент не подтвердил, эта транзакция была отменена. Это позволило клиенту перепроверить транзакцию, но не иметь 2 «реальных» записей, выполненных на стороне сервера.

Answer 2

В случае тайм-аута сценария, вы можете сделать следующее:

Отправить клиент генерируется уникальный идентификатор с первоначального запроса в заголовке.

Если клиент не получает ответа, он может отправить запрос с тем же идентификатором.

Сервер может поддерживать успешную обработку списка идентификаторов и возвращать OK, а не повторять действие.

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

Answer 3

В зависимости от типа веб-сервиса. Вся природа HTTP и REST заключается в том, что он в основном без гражданства.

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

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

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

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