Przechowuj i prześlij żądania HTTP z ponownymi próbami?

Question

Twilio i inne usługi internetowe oparte na protokole HTTP mają koncepcję fallback URL, w której usługi WWW wysyłają GET lub POST do wybranego adresu URL, jeśli główny URL przekroczy limit czasu lub w inny sposób zakończy się niepowodzeniem. W przypadku Twilio nie będą ponawiać próśb, jeśli awaryjny adres URL również zawiedzie. Chciałbym, aby awaryjny adres URL był hostowany na oddzielnym komputerze, aby błąd nie zagubił się w eterze, jeśli serwer główny jest nieczynny lub nieosiągalny.

Chciałbym jakiś sposób za wtórne do:

1. wniosków sklepu do adresu URL awaryjnej
2. Powtórka wnioski do nieco innego adresu URL na serwerze podstawowym
3. Retry nr 2 aż do sukcesu , a następnie usunąć żądanie z kolejki/bazy danych

Czy istnieje jakiś program, który może to zrobić? Mogę zbudować coś sam, jeśli to konieczne, po prostu pomyślałem, że to coś, co ktoś by już zrobił. Nie jestem wystarczająco zaznajomiony z protokołem HTTP i otaczającymi go narzędziami (serwery proxy, odwrotne proxy itp.), Aby znać odpowiednie hasło do wyszukiwania.

Answer 1

Istnieje kilka możliwości.

Jedną z opcji jest użycie Common Address Redundancy Protocol lub carp. Krótki opis ze strony podręcznika.

"Karp pozwala wielu hostom w tej samej sieci lokalnej na współdzielenie zestawu adresów IP, a jego głównym celem jest zapewnienie, że adresy te są zawsze dostępne, ale w niektórych konfiguracjach karp może również zapewniać funkcję równoważenia obciążenia."

Powinno być możliwe skonfigurowanie równoważenia IP tak, aby w przypadku niepowodzenia podstawowej lub głównej usługi http, pomocnicza lub zapasowa usługa http stała się wzorcem. karp jest zorientowany na hosta, a nie na usługi aplikacji. Tak więc, gdy usługa http ulegnie awarii, powinna również usunąć interfejs sieciowy dla karpia, aby zrobić to samo. Oznacza to, że potrzebujesz więcej niż jednego adresu IP, aby zalogować się do urządzenia i wykonać konserwację. Potrzebny byłby skrypt do wykonania dalszych działań po przywróceniu pierwotnej usługi online.

Drugą opcją jest użycie nginx. Jest to prawdopodobnie lepiej dopasowane do tego, co próbujesz zrobić.

Wiele lat temu potrzebowałem czegoś podobnego do tego, co próbuję zrobić, a skończyłem na tym, że zhakowałem razem coś, co to zrobiło. Zasadniczo był to przełącznik. Kiedy "A" się nie powiedzie, przełącz na "B". Proces ponownego zsynchronizowania polegał na zapisaniu znaczników czasu z "B" i odtworzeniu ich z powrotem do "A", gdy "A" powróciło do trybu online.