ฉันสงสัยว่าจะเกิดอะไรขึ้นถ้าเราใช้ HAProxy Load Balancer กับการคงอยู่ (เซสชันที่ติดขัด) และเซิร์ฟเวอร์หยุดทำงาน (หรือเราต้องการลดขนาด)
ตาม เอกสารของพวกเขา:
เมื่อทำการคงอยู่ หากเซิร์ฟเวอร์หยุดทำงาน HAProxy จะส่งผู้ใช้ไปยังเซิร์ฟเวอร์อื่นอีกครั้ง
ปัญหาของฉันอยู่ที่คำจำกัดความของ "ลง" ที่นี่หากเราใช้งานสิ่งนี้บน Kubernetes การ "หยุดทำงาน" หมายความว่าพ็อดไม่ตอบสนองอีกต่อไปหรือไม่ดี (เช่นเดียวกับโพรบความสดที่ล้มเหลว) หรือหมายความว่าพ็อดไม่ทำงานอีกต่อไปและพ็อดใหม่ ถูกสร้างขึ้นแทนที่?
ฉันถามสิ่งนี้เพราะฉันกำลังพยายามหาวิธีที่ดีที่สุดในการรักษาการจัดส่งตามคำสั่งซื้ออย่างมีประสิทธิภาพ ดังนั้นลองพิจารณาตัวอย่างนี้:
- ไคลเอ็นต์ HTTP เข้าถึง Load Balancer ด้วยคำขอ HTTP (R1) และไม่มีเซสชัน
- ตัวจัดสรรภาระงานใช้ algo เพื่อกำหนดเซิร์ฟเวอร์ที่ดีที่สุด (S1) ส่ง R1 ไปยัง S1 และเพิ่มคุกกี้เมื่อได้รับการตอบกลับจากเซิร์ฟเวอร์ (S1)
- คำขอต่อไปนี้มีคุกกี้ ดังนั้น LB จึงรู้อยู่แล้วว่าเซิร์ฟเวอร์ใดควรได้รับคำขอ
- ตอนนี้ไคลเอนต์ส่งคำขออื่น (R2) แต่เซิร์ฟเวอร์ (S1) ไม่ตอบสนองทันเวลา (แต่พ็อดยังคงทำงานและพยายามเขียนคำขอนั้นลงในคาฟคาเป็นข้อความ)
- เนื่องจากไคลเอ็นต์ไม่ได้รับการตอบกลับทันเวลา จึงลอง R2 ใหม่อีกครั้ง แต่ LB เห็นว่า S1 ไม่ตอบสนอง ดังนั้นคราวนี้จะเลือกเซิร์ฟเวอร์ใหม่ (S2)
- คำขอ R2 สำเร็จแล้วเนื่องจาก S2 นั้นดีและสวยงาม
- ไคลเอ็นต์ส่ง R3 และสำเร็จเนื่องจาก S2 ไม่เป็นไร
- ในระหว่างนี้ S1 ได้กู้คืนแล้วและก่อนที่จะยุติก็จัดการเขียน R2 ลงใน Kafka ทำให้ยุ่งกับลำดับของข้อความ (เพราะตอนนี้เรามี R1, R2, R3, R2)
ดังนั้นคำถามของฉันข้างต้น มีอะไรที่สามารถทำได้แม้ว่าจะไม่ใช่ HAProxy หรือไม่ บางที Kubernetes Load Balancer? หรือฉันจะต้องเขียน Load Balancer แบบกำหนดเองที่จะต้องติดตามพ็อดและตรวจสอบว่าพ็อดไม่ตอบสนองหรือหายไปโดยสิ้นเชิงหรือไม่
FYI ฉันยอมสละความพร้อมใช้งานทั้งหมดที่นี่เพื่อความสอดคล้อง (ทฤษฎีบท CAP) และปฏิเสธคำขอ ฉันยังพยายามหลีกเลี่ยงการใช้เซิร์ฟเวอร์ในจำนวนที่แน่นอน เนื่องจากจะเป็นการดีที่จะปรับขนาดเซิร์ฟเวอร์ขึ้นและลงตามการรับส่งข้อมูลสิ่งสำคัญคือต้องไม่กำหนดเส้นทางคำขอหากเซิร์ฟเวอร์ที่เคยให้บริการไคลเอนต์นั้นยังคงห้อยอยู่ที่ใดที่หนึ่งเพื่อหลีกเลี่ยงการยุ่งเหยิงกับลำดับของข้อความ
ความคิดใด ๆ ที่จะได้รับการต้อนรับ