Mă întreb ce s-ar întâmpla dacă, să zicem, folosim un HAProxy Load Balancer cu persistență (sesiuni sticky) și un server se defectează (sau vrem să reducem scala).
Conform documentele lor:
Când faceți persistență, dacă un server se defectează, atunci HAProxy va retrimite utilizatorul către un alt server.
Problema mea este cu definiția „jos” aici.Dacă rulăm acest lucru pe Kubernetes, „în jos” înseamnă că podul nu mai răspunde sau pur și simplu nu este sănătos (ca în eșecul probei de liveness) sau înseamnă că podul nu mai rulează și unul nou? a fost creat în locul ei?
Întreb acest lucru pentru că încerc să găsesc cea mai bună modalitate de a menține livrarea în comandă într-un mod eficient, așa că luați în considerare acest exemplu:
- Clientul HTTP accesează Load Balancer cu o solicitare HTTP (R1) și nu are nicio sesiune
- Load balancer folosește un algo pentru a determina cel mai bun server (S1), trimite R1 la S1 și adaugă cookie-ul când primește răspunsul înapoi de la server (S1)
- Următoarele solicitări au cookie-ul, astfel încât LB să știe deja ce server ar trebui să primească cererea
- Acum clientul trimite o altă solicitare (R2), dar serverul (S1) nu răspunde la timp (dar podul încă rulează și încearcă să scrie acea cerere în Kafka ca mesaj)
- Deoarece clientul nu a primit un răspuns la timp, va reîncerca R2 din nou, dar LB a văzut că S1 nu răspunde, așa că de data aceasta va alege un nou server (S2)
- Solicitarea R2 acum reușește deoarece S2 a fost bine și dandy
- Clientul trimite R3 și reușește pentru că din nou S2 este bine
- Între timp, acum S1 și-a revenit și înainte de a se termina reușește să scrie R2 în Kafka încurcându-se cu ordinea mesajelor (pentru că acum avem R1, R2, R3, R2)
De aici întrebările mele de mai sus. Există ceva, chiar dacă nu HAProxy, care poate realiza acest lucru? Poate un Kubernetes Load Balancer? Sau va trebui să scriu un Load Balancer personalizat care va trebui să țină evidența podurilor și să verifice dacă pur și simplu nu răspund sau dispărură complet?
FYI Sunt foarte bine să sacrific disponibilitatea aici de dragul coerenței (teorema CAP) și să refuz o cerere. Încerc, de asemenea, să evit să folosesc un număr fix de servere, deoarece ar fi ideal să le creez și să scadă în funcție de trafic.Principalul lucru ar fi să NU direcționați o solicitare în cazul în care serverul care deservește anterior acel client încă atârnă undeva pentru a evita greșelile cu ordinea mesajelor.
Orice idei ar fi binevenite.
