Повторы HAProxy: retry-on и redispatch меняют разные части сценария
Прокси способен повторить обращение без отдельного решения клиента. Поэтому для значимых операций нужно понимать условия автоматического повтора. Недополученный ответ не всегда означает, что backend не успел выполнить изменение.
По умолчанию retries HAProxy относится к новым попыткам соединения. Retry-on может расширить причины, включая определённые проблемы ответа. Это уже не та же ситуация, что отказ до отправки запроса. Для выбранных условий нужно оценить, могла ли операция быть принята и обработана сервером.
Redispatch допускает переход к другому подходящему серверу при повторах, в том числе с нарушением прежней cookie-привязки. Это помогает доступности только тогда, когда приложение и данные позволяют такой переход. Другой backend не обязательно знает о частично выполненном действии предыдущего участника.
В приёмке на стенде проверяют отказ до передачи, разрыв после приёма запроса и задержку ответа уже выполненной операции. Сверяют фактическое число прикладных эффектов и выбранные серверы. Политику повторов связывают с договорённостью приложения о безопасном повторении и идентификации операций. Исчезновение клиентской ошибки само по себе не доказывает отсутствие дублирующего действия.
Основание — Official HAProxy3.2 text references, Configuration Manual dated2026/10/14; separate PROXY protocol1/2 specification, разделы retries; retry-on; option redispatch. Сохранён текст публичной справочной публикации; конкретная реализация может поддерживать только часть возможностей. Основание — официальные текстовые справочники ветки HAProxy 3.2. Configuration Manual имеет дату 2026/10/14; номер patch из другого HTML-конвертера на эти файлы не переносится. Установленные сборка, конфигурация и backend не проверялись; изменений не выполнялось.
