Хранить и пересылать HTTP-запросы с повторениями?

Question

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

Я хотел бы каким-то образом для неосновных:

1. запросов магазина в резервном URL
2. Replay запросы к нескольким иному URL на первичном сервере
3. Retry # 2, пока успех , затем удалить запрос из очереди/базы данных

Есть ли какой-нибудь существующий программный продукт, который может это сделать? Я могу построить что-то само собой, если понадобится, я просто подумал, что это было бы что-то, что кто-то уже сделал бы. Я недостаточно разбираюсь в HTTP и окружающих инструментах (прокси, обратные прокси и т. Д.), Чтобы знать правильное словечко для поиска.

Answer 1

Есть несколько возможностей.

Одним из вариантов является использование протокола Common Address Redundancy Protocol или carp. Ниже приводится краткое описание с man-страницы.

«carp позволяет нескольким хостам в одной локальной сети совместно использовать набор IP-адресов. Его основная цель - обеспечить, чтобы эти адреса всегда были доступны, но в некоторых конфигурациях карп также может обеспечивать функциональность балансировки нагрузки».

Должно быть возможным настроить балансировку IP-адресов таким образом, чтобы при сбое первичной или основной http-службы вторичная или резервная служба HTTP становилась ведущей. carp ориентирован на хозяина, а не на обслуживание приложений. Поэтому, когда служба http идет вниз, она также должна удалить сетевой интерфейс для карпа, чтобы сделать свою работу. Это означает, что для входа в систему и проведения технического обслуживания вам потребуется более одного IP-адреса. Вам понадобится сценарий для выполнения последующих действий после того, как исходная служба снова появится в сети.

Второй вариант - использовать nginx. Это, вероятно, лучше подходит для того, что вы пытаетесь сделать.

Много лет назад мне было нужно что-то похожее на то, что пытались сделать, и я в конечном итоге взломал что-то, что это сделало. По сути, это был переключатель. Когда «A» выходит из строя, переключитесь на «B». Процесс повторной синхронизации состоял в том, чтобы брать журналы с отметками времени с «B» и воспроизводить их обратно до «A», как только «A» снова был в сети.