บทความ

ลองนึกภาพ: คุณเขียน client ที่ส่ง requests ไปยังเว็บไซต์ และทุกอย่างทำงานได้ดี จากนั้นจู่ๆ ก็มีข้อผิดพลาดถาโถม, workers ค้าง, และเซิร์ฟเวอร์ตอบกลับด้วยรหัส 429 ที่น่าสงสัย คุ้นไหม? ถ้าอย่างนั้นคู่มือนี้เหมาะสำหรับคุณ เราจะมาเรียนรู้วิธีสร้าง HTTP Client ที่ไม่ตื่นตระหนกเมื่อเจอปัญหาแรก แต่กลับวางตัวอย่างสุภาพและทนทาน

บทนำ: ทำไม 429 ไม่ใช่ข้อผิดพลาด แต่เป็นสัญญาณ

นักพัฒนาหลายคนเห็นรหัส 429 แล้วคิดว่า: พังแล้ว ความจริงแล้วเซิร์ฟเวอร์กำลังบอกคุณอย่างชัดเจนว่า: คุณส่งคำขอมากเกินไป กรุณาชะลอความเร็ว นี่ไม่ใช่การปฏิเสธหรือบล็อกถาวร แต่เป็นคำขอให้ลดจังหวะ และถ้าคุณฟังอย่างถูกต้อง client ของคุณจะเชื่อถือได้

สิ่งที่ผู้อ่านจะได้รับเมื่อจบ

เมื่อจบคู่มือนี้ คุณจะมี HTTP Client ที่ใช้งานได้จริง ซึ่งสามารถทำสิ่งสำคัญหลายอย่าง มันจัดการรหัส 429 อย่างถูกต้องและเคารพส่วนหัว Retry-After มันใช้ exponential backoff พร้อม jitter เพื่อไม่ให้เกิดพายุของการส่งซ้ำ มันจำกัด parallelism เพื่อไม่ให้เซิร์ฟเวอร์เป้าหมายล้น และมันไม่ค้างเพราะ timeout ที่ดี

คุณจะได้รับโค้ดสำเร็จรูปในสามภาษา: Python (ผ่านไลบรารี httpx และ urllib3 Retry), Node.js และ Go แต่ละส่วนสามารถนำไปแทรกในโปรเจกต์ของคุณและปรับแต่งตามความต้องการ

คู่มือนี้เหมาะสำหรับใคร

คู่มือนี้เหมาะสำหรับนักพัฒนามือใหม่ที่ทำ HTTP requests พื้นฐานได้แล้ว แต่ยังไม่เคยเจอภาระงานในระดับ production แต่ก็มีส่วนสำหรับผู้ที่ต้องการขั้นสูง: circuit breaker, metrics, การเสื่อมสภาพแบบควบคุมได้ ถ้าคุณเขียน parser, อินทิเกรตกับ API ของคนอื่น หรือบริการที่ต้องเชื่อมต่อกับทรัพยากรภายนอก เนื้อหานี้จะช่วยประหยัดเวลาการนอนไม่หลับหลายคืน

สิ่งที่ต้องรู้ล่วงหน้า

คุณแค่ต้องเข้าใจว่า HTTP request และ HTTP response คืออะไร ควรรู้จัก status codes เช่น 200 คือสำเร็จ, 404 คือไม่พบหน้า พื้นฐานภาษาใดภาษาหนึ่งก็พอ: Python, JavaScript หรือ Go ไม่ต้องมีความรู้เชิงลึกเกี่ยวกับเครือข่าย เราจะอธิบายด้วยภาษาง่ายๆ

ใช้เวลานานเท่าไหร่

อ่านและทำความเข้าใจทฤษฎี – ประมาณ 40 นาที การสร้าง client พื้นฐานทีละขั้น – ประมาณ 1 ชั่วโมง การใช้งานเต็มรูปแบบพร้อมการป้องกันทั้งหมด, metrics และการทดสอบ – ประมาณ 3 ชั่วโมง อย่ารีบ: ทำความเข้าใจแต่ละขั้นตอนช้าๆ ดีกว่าคัดลอกโค้ดที่คุณไม่เข้าใจ

คำแนะนำ: อ่านคู่มือโดยเปิด editor โค้ดไปด้วย ลองตัวอย่างกับ endpoint ทดสอบทันที อย่าใช้กับบริการ production จริง

การเตรียมความพร้อมเบื้องต้น

ก่อนเขียนโค้ด เรามาเตรียมสภาพแวดล้อมการทำงานก่อน ใช้เวลาไม่นาน แต่ช่วยลดความสับสนในภายหลัง

เครื่องมือที่จำเป็น

  • ภาษาใดภาษาหนึ่งและสภาพแวดล้อม: Python 3.11 หรือใหม่กว่า, Node.js 20 หรือใหม่กว่า, หรือ Go 1.22 หรือใหม่กว่า
  • Editor โค้ด – ใช้ตัวไหนก็ได้ เช่น VS Code
  • Terminal สำหรับรันสคริปต์
  • การเข้าถึงอินเทอร์เน็ตไปยังบริการ HTTP ทดสอบที่สามารถตอบกลับด้วยรหัสต่างๆ

สิ่งที่ต้องติดตั้งสำหรับ Python

  1. ตรวจสอบเวอร์ชัน Python ด้วยคำสั่งใน terminal: พิมพ์ python --version แล้วกด Enter
  2. สร้าง virtual environment ด้วยคำสั่ง python -m venv venv
  3. เปิดใช้งาน: บน Windows ใช้ venv\Scripts\activate, บน macOS และ Linux ใช้ source venv/bin/activate
  4. ติดตั้งไลบรารีด้วยคำสั่ง pip install httpx urllib3 requests

สิ่งที่ต้องติดตั้งสำหรับ Node.js

  1. ตรวจสอบเวอร์ชันด้วยคำสั่ง node --version
  2. สร้างโฟลเดอร์โปรเจกต์แล้วเข้าไป
  3. เริ่มต้นโปรเจกต์ด้วย npm init -y
  4. ตั้งแต่ Node.js 20 เป็นต้นไป fetch ในตัวมีให้ใช้แล้ว ไม่ต้องติดตั้งแพ็กเกจเพิ่มเติมสำหรับ client พื้นฐาน

สิ่งที่ต้องติดตั้งสำหรับ Go

  1. ตรวจสอบเวอร์ชันด้วยคำสั่ง go version
  2. สร้างโฟลเดอร์และเริ่มต้นโมดูลด้วย go mod init myclient
  3. ไลบรารีมาตรฐาน net/http ก็เพียงพอ ไม่จำเป็นต้องใช้แพ็กเกจภายนอก

การสำรองข้อมูลและความปลอดภัย

⚠️ คำเตือน: ห้ามทดสอบ client ใหม่กับบริการ production จริงทันที ให้ใช้ endpoint ทดสอบหรือเซิร์ฟเวอร์จำลองที่คุณควบคุมได้ก่อน มิฉะนั้น การส่งซ้ำแบบรุนแรงอาจเป็นอันตรายต่อบริการของผู้อื่นและนำไปสู่การบล็อกคุณ

ถ้าคุณกำลังปรับปรุงโปรเจกต์ที่มีอยู่ ให้สำเนาไฟล์หรือสร้าง branch แยกในระบบควบคุมเวอร์ชัน เพื่อให้สามารถย้อนกลับได้เสมอ

✅ ตรวจสอบ: คุณติดตั้งภาษาแล้ว สร้างโปรเจกต์ และมั่นใจว่าสคริปต์ทดสอบรันได้โดยไม่มีข้อผิดพลาด ตอนนี้พร้อมไปสู่ทฤษฎีแล้ว

แนวคิดพื้นฐานในภาษาง่ายๆ

เพื่อสร้าง client อย่างมั่นใจ คุณต้องเข้าใจคำศัพท์สำคัญสองสามคำ เราจะอธิบายโดยไม่ใช้คำยาก

รหัส 403, 407, 429 และ 503 หมายถึงอะไร

รหัสทั้งสี่นี้อาจสับสนได้ แต่มีพฤติกรรมต่างกัน และวิธีการแก้ไขก็ต่างกัน

  • รหัส 429 Too Many Requests – เซิร์ฟเวอร์บอกว่าคุณส่งคำขอเกินขีดจำกัด เป็นการชั่วคราว ต้องชะลอและลองใหม่ภายหลัง
  • รหัส 403 Forbidden – ไม่อนุญาตให้เข้าถึง มักไม่เกี่ยวกับความเร็ว แต่เกี่ยวกับสิทธิ์: คีย์ผิด, ไม่มี authentication, ข้อจำกัดตามภูมิภาค การส่งซ้ำโดยไม่เปลี่ยนแปลงมักไร้ประโยชน์
  • รหัส 503 Service Unavailable – เซิร์ฟเวอร์โหลดเกินหรือกำลังบำรุงรักษา เช่นเดียวกับ 429 เป็นการชั่วคราว และการลองทีหลังอาจช่วยได้
  • รหัส 407 Proxy Authentication Required – จุดสำคัญ: รหัสนี้ ไม่ได้มาจากเว็บไซต์เป้าหมาย แต่มาจาก proxy server หมายความว่า proxy ต้องการ authentication แต่คุณไม่ได้ส่งหรือส่งผิด

⚠️ คำเตือน: รหัส 407 ไม่สามารถแก้ไขได้ด้วยการเปลี่ยน IP หรือ backoff นี่เป็นข้อผิดพลาดในการตั้งค่า client โดยเฉพาะข้อมูลการรับรองความถูกต้องของ proxy ที่ไม่ถูกต้อง ตรวจสอบชื่อผู้ใช้ รหัสผ่าน และรูปแบบสตริงการเชื่อมต่อ การส่งซ้ำใดๆ จะไม่ช่วยจนกว่าคุณจะแก้ไข authentication

ความแตกต่างระหว่าง 429 และ 403

จำกฎง่ายๆ 429 เกี่ยวกับปริมาณ: คุณทำบ่อยเกินไป 403 เกี่ยวกับสิทธิ์: คุณไม่ได้รับอนุญาตเลย เมื่อ 429 การลองใหม่หลังจากหยุดพักจะแก้ปัญหาได้ เมื่อ 403 การลองใหม่โดยไม่เปลี่ยนเงื่อนไขจะไม่ช่วย – ต้องเปลี่ยนคีย์, headers หรือวิธีการ

ส่วนหัว Retry-After และ X-RateLimit

เซิร์ฟเวอร์ที่สุภาพจะบอกใบ้ว่าเมื่อใดควรกลับมา ส่วนหัว Retry-After บอกว่าควรลองอีกครั้งหลังจากกี่วินาที บางครั้งเป็นจำนวนวินาที บางครั้งเป็นวันที่แน่นอน client ของคุณต้องเคารพส่วนหัวนี้: ถ้าเซิร์ฟเวอร์บอกให้รอ 10 วินาที การลองซ้ำใน 1 วินาทีจะทำให้สถานการณ์แย่ลง

กลุ่มส่วนหัว X-RateLimit บอกขีดจำกัด: จำนวนคำขอที่คุณได้รับอนุญาต, เหลือเท่าไหร่, และเมื่อตัวนับจะถูกรีเซ็ต เช่น X-RateLimit-Remaining แสดงจำนวนที่เหลือ ถ้าใกล้ศูนย์ ควรลดความเร็วล่วงหน้าโดยไม่ต้องรอ 429

วิธีการนับขีดจำกัด: token bucket และ sliding window

เซิร์ฟเวอร์นับคำขอของคุณด้วยสองวิธีที่นิยม

Token bucket (ถังโทเค็น) ทำงานดังนี้: จินตนาการถึงถังที่มีโทเค็นหยดเข้ามาอย่างต่อเนื่องในอัตราคงที่ แต่ละคำขอใช้หนึ่งโทเค็น ถ้าไม่มีโทเค็น คำขอจะถูกปฏิเสธด้วยรหัส 429 วิธีนี้ยอมให้มีการระเบิดสั้นๆ: ถ้าคุณเงียบไปนาน ถังจะเต็ม และคุณสามารถส่งคำขอเป็นชุดได้ทันที

Sliding window (หน้าต่างเลื่อน) นับจำนวนคำขอในช่วงเวลาที่ผ่านมา เช่น ใน 1 นาที เมื่อคุณเกินขีดจำกัดในหน้าต่างนั้น คุณจะได้รับ 429 การระเบิดจะถูกลงโทษหนักกว่า

ทำไม parallelism ก็เป็นขีดจำกัดเช่นกัน

หลายคนลืม: ขีดจำกัดไม่ได้อยู่ที่ความถี่เท่านั้น แต่ยังรวมถึงจำนวนการเชื่อมต่อพร้อมกันด้วย ถ้าคุณเปิด 500 คำขอพร้อมกัน เซิร์ฟเวอร์อาจมองว่าเป็นการโจมตี แม้จำนวนรวมต่อนาทีจะไม่มาก ต้องจำกัด parallelism อย่างเคร่งครัดเท่ากับความถี่

คำแนะนำ: ก่อนสร้าง client ควรทราบขีดจำกัดของบริการเป้าหมายจากเอกสาร การรู้ตัวเลขอ้างอิงจะช่วยให้คุณไม่ต้องเดาและหลีกเลี่ยง 429 ที่ไม่จำเป็น

✅ ตรวจสอบ: คุณเข้าใจความแตกต่างระหว่าง 429, 403, 407 และ 503, รู้จัก Retry-After และเข้าใจว่าเซิร์ฟเวอร์นับคำขอของคุณอย่างไร เยี่ยม ไปยังภาคปฏิบัติกัน

ขั้นตอนที่ 1: ตั้งค่า timeout อย่างถูกต้อง

เป้าหมายของขั้นตอน: ทำให้ไม่มีคำขอใดค้างตลอดไปและบล็อก worker

ทำไม client ที่ไม่มี timeout จึงอันตราย

Client ที่ไม่มี timeout คือระเบิดเวลา ถ้าเซิร์ฟเวอร์หยุดตอบสนอง คำขอของคุณจะรอตลอดไป คำขอที่ค้างหนึ่งรายการยึด worker หนึ่งตัว สิบคำขอค้าง – พูล workers ทั้งหมดของคุณถูกครอบครอง งานใหม่ไม่ได้รับการประมวลผล บริการหยุดทำงาน Timeout คือแนวป้องกันแรกของคุณ

Timeout สี่ประเภท

Client ที่ถูกต้องควรแยก timeout หลายประเภท ไม่ใช่ตั้งค่ารวมเพียงค่าเดียว

  1. Connect timeout (การเชื่อมต่อ) – รอนานแค่ไหนในการสร้างการเชื่อมต่อกับเซิร์ฟเวอร์ ถ้าเซิร์ฟเวอร์ไม่สามารถเข้าถึงได้ คุณจะรู้ทันที
  2. Read timeout (การอ่าน) – รอข้อมูลหลังจากส่งคำขอ ป้องกันเซิร์ฟเวอร์ที่รับคำขอแล้วแต่นิ่ง
  3. Write timeout (การเขียน) – รอการส่งเนื้อหาคำขอ ใช้สำหรับอัปโหลดขนาดใหญ่
  4. Timeout รวม (total) – เวลาสูงสุดสำหรับคำขอทั้งหมดรวมทุกขั้นตอน

ค่าเริ่มต้นที่เหมาะสม

ไม่มีตัวเลขสากล แต่มีจุดเริ่มต้นที่สมเหตุสมผล สำหรับ connect ใช้ 3-5 วินาที: การเชื่อมต่อมักเกิดขึ้นเร็ว สำหรับ read ใช้ 10-30 วินาทีขึ้นอยู่กับความเร็วของบริการ Timeout รวมตั้งให้ครอบคลุมคำขอที่ช้าที่สุดที่สมเหตุสมผล เช่น 30-60 วินาที

⚠️ คำเตือน: อย่าตั้ง timeout ใหญ่เกินไป เช่น 300 วินาทีสำหรับทุกคำขอ เพราะจะซ่อนปัญหาและสร้างคิวงานที่ค้าง ดีกว่าที่จะล้มเร็วแล้วลองใหม่ ดีกว่ารอเปล่าๆ นาน

การตั้งค่าทีละขั้นตอน

  1. กำหนดว่าระยะเวลาเฉลี่ยของคำขอที่สำเร็จคือเท่าไหร่ วัดหลายครั้ง
  2. ตั้ง read timeout ประมาณสองเท่าของเวลาตอบสนองเฉลี่ย
  3. ตั้ง connect timeout ที่ 3-5 วินาที
  4. ตั้ง timeout รวมเป็นผลรวมของเฟสที่สมเหตุสมผลบวกส่วนเผื่อเล็กน้อย
  5. รันคำขอทดสอบและตรวจสอบว่าจบลง ไม่ค้าง

คำแนะนำ: ถ้าบริการของคุณบางครั้งส่งไฟล์ใหญ่ บางครั้งตอบกลับสั้น ให้ทำโปรไฟล์ timeout ต่างกันสำหรับประเภทคำขอ ขนาดเดียวใช้ไม่ได้กับทุกกรณี

ผลลัพธ์ที่คาดหวัง: เมื่อเข้าถึงที่อยู่ที่ช้าหรือไม่สามารถเข้าถึงได้ client ของคุณจะจบการพยายามภายในเวลาที่กำหนดพร้อมข้อผิดพลาด timeout ที่เข้าใจได้ ไม่ใช่ค้างตลอดไป

✅ ตรวจสอบ: ส่งคำขอไปยังที่อยู่ที่ไม่ตอบสนอง (เช่น พอร์ตที่ไม่มีอยู่) client ควรคืนข้อผิดพลาด timeout ภายในเวลาประมาณที่ตั้งไว้ ถ้าค้างนานกว่า แสดงว่าตั้งค่า timeout ไม่ถูกต้อง

ขั้นตอนที่ 2: สร้าง retries ด้วย exponential backoff และ jitter

เป้าหมายของขั้นตอน: สอน client ให้ส่งคำขอซ้ำอย่างชาญฉลาด โดยไม่ทำร้ายตัวเองและเซิร์ฟเวอร์

อะไรที่ส่งซ้ำได้: idempotency

ก่อนจะส่งซ้ำ ให้ถามตัวเองว่า: ปลอดภัยไหมที่จะทำคำขอซ้ำสองครั้ง? คุณสมบัตินี้เรียกว่า idempotency คำขอจะ idempotent ถ้าการทำซ้ำให้ผลลัพธ์เดียวกันและไม่มีผลข้างเคียง

  • GET, HEAD, PUT, DELETE โดยทั่วไป idempotent ส่งซ้ำได้ปลอดภัย
  • POST โดยทั่วไปไม่ idempotent การส่งซ้ำอาจสร้างรายการซ้ำ, การชำระเงินซ้ำ, เรกคอร์ดซ้ำ

⚠️ คำเตือน: อย่าส่งซ้ำ POST requests โดยไม่ยั้ง การส่งซ้ำคำขอที่ไม่ idempotent อาจทำให้ถูกหักเงินซ้ำหรือข้อมูลซ้ำซ้อน ถ้าต้องส่งซ้ำ POST ให้ใช้คีย์ idempotency (Idempotency-Key) ที่เซิร์ฟเวอร์เข้าใจและจะไม่ดำเนินการซ้ำ

ส่งซ้ำกี่ครั้ง

การส่งซ้ำไม่รู้จบคือความชั่วร้าย ขีดจำกัดที่สมเหตุสมผลคือ 3 ถึง 5 ครั้ง ถ้าหลังจากห้าครั้งคำขอยังไม่สำเร็จ แสดงว่าปัญหาร้ายแรงกว่าข้อผิดพลาดชั่วคราว และต้องบันทึกและจัดการแยกต่างหาก

exponential backoff คืออะไร

Backoff คือการหยุดระหว่างการส่งซ้ำ Exponential หมายถึงการหยุดเพิ่มขึ้นเป็นทวีคูณในแต่ละครั้ง เช่น หยุดครั้งแรก 1 วินาที ครั้งที่สอง 2 วินาที ครั้งที่สาม 4, ครั้งที่สี่ 8 สูตรง่ายๆ: ดีเลย์พื้นฐานคูณด้วยสองยกกำลังหมายเลขครั้งที่พยายาม

ทำไมต้องเป็นแบบนี้? ถ้าเซิร์ฟเวอร์โอเวอร์โหลด การส่งซ้ำถี่ๆ สั้นๆ จะยิ่งทำให้เซิร์ฟเวอร์แย่ลง การหยุดที่เพิ่มขึ้นช่วยให้เซิร์ฟเวอร์มีเวลาฟื้นตัว

ทำไมไม่มี jitter จะเกิดพายุส่งซ้ำ

ลองนึกภาพ client พันตัวได้รับ 429 พร้อมกัน ทุกตัวรอ 1 วินาทีพอดี, แล้ว 2, แล้ว 4 ทุกตัวส่งซ้ำในเวลาเดียวกัน เกิด พายุซิงโครนัส: เซิร์ฟเวอร์ได้รับคำขอพันรายการอีกครั้งและตอบ 429 อีกครั้ง ปัญหาไม่ได้รับการแก้ แต่กลับเป็นวงจร

ทางออกคือ jitter – การเพิ่มแบบสุ่มในการหยุด แทนที่จะหยุด 2 วินาทีเป๊ะ client หนึ่งรอ 1.7, อีกตัว 2.3, อีกตัว 1.9 การส่งซ้ำกระจายออกไปตามเวลา และเซิร์ฟเวอร์ได้พักผ่อนอย่างค่อยเป็นค่อยไป

วิธีเคารพ Retry-After

ถ้าเซิร์ฟเวอร์ส่งส่วนหัว Retry-After มา มันสำคัญกว่าสูตร backoff ของคุณ กฎง่ายๆ: ใช้ค่ามากที่สุดระหว่างการหยุดที่คำนวณได้กับค่า Retry-After อย่าส่งซ้ำเร็วกว่าที่เซิร์ฟเวอร์ขอ เพราะนั่นเป็นการไม่สุภาพอย่างร้ายแรง ซึ่งจะนำไปสู่ 429 อีกครั้ง

การใช้งานตรรกะ retries ทีละขั้น

  1. ตรวจสอบว่าคำขอ idempotent หรือไม่ ถ้าไม่ใช่และไม่มีคีย์ idempotency – อย่าส่งซ้ำ
  2. ตรวจสอบรหัสตอบกลับ ส่งซ้ำเฉพาะกับ 429, 503 และข้อผิดพลาดเครือข่าย (timeout, การตัดการเชื่อมต่อ)
  3. เพิ่มตัวนับครั้งที่พยายาม ถ้าเกินขีดจำกัด – หยุดและคืนข้อผิดพลาด
  4. คำนวณการหยุดพื้นฐานตามสูตร exponential growth
  5. เพิ่ม jitter สุ่มให้กับการหยุด
  6. ถ้ามี Retry-After ให้ใช้ค่าที่มากกว่าระหว่างสองค่านั้น
  7. รอตามเวลาที่คำนวณแล้วส่งคำขอซ้ำ

คำแนะนำ: จำกัดการหยุดสูงสุด เช่น 30 หรือ 60 วินาที มิฉะนั้นในการพยายามครั้งที่ 5 backoff อาจโตจนไร้เหตุผล และผู้ใช้จะรอเป็นเวลานานเกินไป

ผลลัพธ์ที่คาดหวัง: เมื่อได้รับรหัส 429 client จะหยุดชั่วคราว, ส่งซ้ำ, และการหยุดระหว่างการส่งซ้ำจะเพิ่มขึ้นและแตกต่างกันเล็กน้อยในแต่ละครั้ง

✅ ตรวจสอบ: ตั้งค่าเซิร์ฟเวอร์ทดสอบให้ตอบ 429 หลายครั้งติดต่อกัน จากนั้นตอบ 200 client ของคุณควรได้รับคำตอบสุดท้ายสำเร็จ และในล็อกคุณจะเห็นการหยุดที่เพิ่มขึ้นและมีความแปรปรวน

ขั้นตอนที่ 3: จำกัด parallelism

เป้าหมายของขั้นตอน: อย่าให้ client ท่วมเซิร์ฟเวอร์ด้วยคำขอพร้อมกันจำนวนมาก

semaphore คืออะไรในภาษาง่ายๆ

Semaphore คือตัวนับสิทธิ์ ลองนึกถึงตู้เสื้อผ้าที่มีตะขอจำกัด ถ้ามีตะขอว่าง คุณก็แขวนเสื้อ ถ้าตะขอหมด – รอจนกว่าจะมีคนเอาออก Semaphore อนุญาตให้มีงานพร้อมกันได้จำนวนจำกัด ส่วนที่เหลือรอในคิว

คิวงาน

คำขอทั้งหมดที่จะดำเนินการจะถูกใส่ในคิว Workers หยิบงานจากคิวตามลำดับเมื่อว่าง ซึ่งทำให้คุณควบคุมจังหวะได้เต็มที่: จำนวน workers = จำนวนคำขอพร้อมกันสูงสุด

ขีดจำกัดต่อโฮสต์

จุดสำคัญ: ควรตั้งขีดจำกัด แยกสำหรับแต่ละโฮสต์ ถ้าคุณทำงานกับหลายบริการ ขีดจำกัดรวมทั่วโลกอาจไม่เหมาะสม โฮสต์ที่ช้าไม่ควรบล็อกคำขอไปยังโฮสต์อื่น ตั้งขีดจำกัดเฉพาะสำหรับแต่ละโดเมน

พูลการเชื่อมต่อและ keep-alive

การเชื่อมต่อ TCP ใหม่แต่ละครั้งมีค่าใช้จ่าย: การจับมือ, การตั้งค่าช่องสัญญาณที่ปลอดภัย Keep-alive ช่วยให้ใช้การเชื่อมต่อเดิมซ้ำสำหรับหลายคำขอติดต่อกัน ประหยัดเวลาและทรัพยากรเซิร์ฟเวอร์ พูลการเชื่อมต่อเก็บการเชื่อมต่อที่เปิดไว้พร้อมใช้ ตั้งขนาดพูลให้สอดคล้องกับขีดจำกัด parallelism ของคุณ

⚠️ คำเตือน: อย่าสับสนระหว่างขนาดพูลการเชื่อมต่อกับขีดจำกัด parallelism พูลอาจใหญ่กว่าขีดจำกัดเล็กน้อยเพื่อสำรอง แต่ถ้าพูลใหญ่เกินไปและขีดจำกัดเล็ก คุณจะเก็บการเชื่อมต่อที่เปิดไว้โดยเปล่าประโยชน์ ให้รักษาสมดุลที่เหมาะสม

การตั้งค่าขีดจำกัดทีละขั้นตอน

  1. กำหนดจำนวนคำขอพร้อมกันที่ปลอดภัยต่อโฮสต์ เริ่มต้นน้อยๆ เช่น 5-10
  2. สร้าง semaphore ที่มีสิทธิ์ตามจำนวนนั้น
  3. ก่อนแต่ละคำขอ ขอสิทธิ์จาก semaphore
  4. หลังจบคำขอ ไม่ว่าจะสำเร็จหรือไม่ ให้ปล่อยสิทธิ์เสมอ
  5. ตั้งค่าพูลการเชื่อมต่อกับ keep-alive ในลำดับเดียวกัน
  6. ค่อยๆ เพิ่มขีดจำกัด โดยสังเกตสัดส่วนของ 429 เมื่อเริ่มเพิ่มขึ้น – คุณถึงเพดานแล้ว

คำแนะนำ: ปล่อยสิทธิ์ semaphore ในบล็อก finally หรือเทียบเท่า มิฉะนั้นเมื่อเกิดข้อผิดพลาด สิทธิ์จะไม่ถูกส่งคืน ตัวนับรั่ว และในที่สุด client จะหยุดทำงาน

ผลลัพธ์ที่คาดหวัง: ไม่ว่าคุณจะใส่กี่งานในคิว จำนวนคำขอพร้อมกันไปยังโฮสต์จะไม่เกินขีดจำกัดที่ตั้งไว้

✅ ตรวจสอบ: ใส่ 100 งานในคิวโดยมีขีดจำกัด 5 ในล็อกหรือมอนิเตอร์ คุณควรเห็นไม่เกิน 5 คำขอที่ทำงานพร้อมกันตลอดเวลา

ขั้นตอนที่ 4: ตอบสนองต่อรหัส 429 อย่างถูกต้อง

เป้าหมายของขั้นตอน: สร้างปฏิกิริยาที่ถูกต้องต่อสัญญาณโอเวอร์โหลด และเข้าใจว่าเมื่อใดเหมาะสมที่จะเปลี่ยน IP

สามการกระทำเมื่อเจอ 429

เมื่อได้รับ 429 คุณมีสามเครื่องมือ และควรใช้ร่วมกัน

  1. ชะลอความเร็ว – ลดจังหวะโดยรวมของคำขอ ไม่ใช่แค่หยุดชั่วคราวสำหรับคำขอเดียว นี่คือกุญแจสำคัญ: 429 คือสัญญาณว่าจังหวะโดยรวมของคุณสูงเกินไป
  2. เปลี่ยน IP – ถ้าคุณใช้การหมุนเวียน IP ที่อยู่ การเปลี่ยนที่อยู่อาจช่วยเมื่อขีดจำกัดผูกกับ IP แต่ไม่ใช่วิธีแก้ทุกอย่าง
  3. เลื่อนงาน – ส่งคำขอกลับไปยังคิวด้วยการหน่วงเวลา เพื่อดำเนินการภายหลังเมื่อขีดจำกัดฟื้นตัว

⚠️ คำเตือน: การเปลี่ยน IP ไม่ได้ยกเลิกความสุภาพ ถ้าขีดจำกัดไม่ได้อยู่ที่ IP แต่อยู่ที่บัญชีหรือคีย์ การเปลี่ยน IP จะไม่ช่วย – คุณยังคงเจอ 429 อย่าใช้การเปลี่ยน IP เป็นวิธีหลีกเลี่ยงกฎ: เคารพขีดจำกัดของบริการและ Retry-After เสมอ

เมทริกซ์การกระทำตามรหัสตอบกลับ

เก็บตารางง่ายๆ นี้ไว้ใกล้มือ

  • 200-299 สำเร็จ – ประมวลผลคำตอบ ปล่อยทรัพยากร รับงานถัดไป
  • 429 Too Many Requests – ชะลอจังหวะ เคารพ Retry-After, ส่งซ้ำด้วย backoff, ถ้าจำเป็นให้เลื่อนงานหรือเปลี่ยน IP
  • 503 Service Unavailable – ส่งซ้ำด้วย backoff, เคารพ Retry-After, แต่ไม่ต้องเปลี่ยน IP: ปัญหาอยู่ที่ฝั่งเซิร์ฟเวอร์
  • 403 Forbidden – อย่าส่งซ้ำโดยไม่คิด ตรวจสอบ authentication, headers, สิทธิ์ บันทึกเพื่อวิเคราะห์
  • 407 Proxy Authentication Required – แก้ไขข้อมูลรับรอง proxy อย่าส่งซ้ำหรือเปลี่ยน IP จนกว่าจะแก้ไขการตั้งค่า
  • 400, 404, 422 ข้อผิดพลาดฝั่ง client – อย่าส่งซ้ำ เป็นข้อผิดพลาดของคำขอคุณ การส่งซ้ำไม่ช่วย
  • 500, 502, 504 ข้อผิดพลาดฝั่งเซิร์ฟเวอร์ – ส่งซ้ำอย่างระมัดระวังด้วย backoff จำนวนเล็กน้อย
  • ข้อผิดพลาดเครือข่ายและ timeout – ส่งซ้ำด้วย backoff ถ้าคำขอ idempotent

การใช้งานปฏิกิริยาต่อ 429 ทีละขั้น

  1. เมื่อได้รับ 429 ให้หยุดเพิ่มจังหวะทันที
  2. อ่านส่วนหัว Retry-After ถ้ามี
  3. คำนวณการหยุดเป็นค่าสูงสุดระหว่าง backoff กับ Retry-After
  4. ถ้าขีดจำกัดน่าจะผูกกับ IP และคุณมีการหมุนเวียน ให้เปลี่ยนที่อยู่ก่อนส่งซ้ำ
  5. ถ้าหมดจำนวนครั้งที่พยายาม ให้เลื่อนงานกลับไปยังคิวด้วยการหน่วงเวลานาน
  6. ลดขีดจำกัด parallelism โดยรวมชั่วคราวเพื่อให้เซิร์ฟเวอร์ได้พัก

คำแนะนำ: เก็บตัวนับสัดส่วนของ 429 ในนาทีที่ผ่านมาแยกต่างหาก ถ้ามันเพิ่มขึ้น ให้ลดจังหวะโดยอัตโนมัติก่อนที่สถานการณ์จะวิกฤต สิ่งนี้เรียกว่า adaptive rate limiting

ผลลัพธ์ที่คาดหวัง: เมื่อเจอ 429 ต่อเนื่อง client จะลดจังหวะอย่างนุ่มนวล เคารพ Retry-After และสุดท้ายส่งคำขอสำเร็จโดยไม่สร้างพายุ

✅ ตรวจสอบ: จำลองการเพิ่มขึ้นของ 429 บนเซิร์ฟเวอร์ทดสอบ client ควรลดกิจกรรม ไม่ใช่เพิ่มการส่งซ้ำ สัดส่วนคำตอบสำเร็จหลังหยุดควรฟื้นตัว

ขั้นตอนที่ 5: เพิ่ม circuit breaker และการเสื่อมสภาพแบบควบคุมได้

เป้าหมายของขั้นตอน: ให้ client มีฟิวส์ป้องกันที่ปกป้องทั้งคุณและเซิร์ฟเวอร์เมื่อมีปัญหาที่ยืดเยื้อ

circuit breaker คืออะไร

Circuit breaker คือฟิวส์ป้องกัน เช่นในตู้ไฟฟ้า ถ้ามีข้อผิดพลาดเกิดขึ้นมากมาย มันจะตัดวงจร: หยุดส่งคำขอไปยังบริการที่มีปัญหาในช่วงเวลาหนึ่ง สิ่งนี้ปกป้องเซิร์ฟเวอร์จากการถูกโจมตีซ้ำ และปกป้อง client จากการใช้ทรัพยากรโดยเปล่าประโยชน์

สามสถานะของฟิวส์

  • Closed (ปิด) – ทำงานปกติ คำขอผ่านไปได้ client นับข้อผิดพลาด
  • Open (เปิด) – มีข้อผิดพลาดมากเกินไป คำขอถูกบล็อกทันทีโดยไม่ต้องไปถึงเซิร์ฟเวอร์ คงอยู่ตามเวลาที่กำหนด
  • Half-open (เปิดครึ่ง) – โหมดทดลอง client ส่งคำขอสองสามตัวเพื่อตรวจสอบว่าบริการฟื้นตัวหรือไม่ ถ้าฟื้น ก็กลับไปที่ closed ถ้าไม่ ก็กลับไปที่ open

การเสื่อมสภาพแบบควบคุมได้แทนการหยุดทั้งหมด

เมื่อบริการไม่พร้อมใช้งาน ไม่จำเป็นต้องล้มทุกอย่าง การเสื่อมสภาพแบบควบคุมได้ คือความสามารถในการทำงานได้แย่ลงแต่ยังคงทำงานต่อไป ตัวอย่าง: ส่งข้อมูลจากแคชแทนข้อมูลสด, แสดงผลลัพธ์ที่ลดทอน, เลื่อนงานที่ไม่จำเป็น, ส่งคืนข้อความสำรองที่เข้าใจได้แทนข้อผิดพลาด

คำแนะนำ: คิดเสมอว่าจะแสดงอะไรให้ผู้ใช้หรือระบบเมื่อบริการภายนอกล้ม ข้อความสำรองที่มีความหมายดีกว่าการค้างหรือ stack trace

การตั้งค่า circuit breaker ทีละขั้น

  1. กำหนดเกณฑ์ข้อผิดพลาดที่จะทำให้ฟิวส์ตัด เช่น 50% ของความล้มเหลวในหน้าต่าง 20 คำขอ
  2. กำหนดเวลาที่วงจรจะถูกตัด เช่น 30 วินาที
  3. นับความสำเร็จและความล้มเหลวใน sliding window
  4. เมื่อเกินเกณฑ์ ให้เปลี่ยนสถานะเป็น open
  5. เมื่อครบเวลา ให้เปลี่ยนเป็น half-open และส่งคำขอทดสอบสองสามตัว
  6. จากผลการทดสอบ ให้กลับไปที่ closed หรือ open อีกครั้ง

⚠️ คำเตือน: อย่าสับสนระหว่าง circuit breaker กับ retries Retries ส่งซ้ำคำขอเดียว ในขณะที่ฟิวส์ควบคุมการไหลทั้งหมดไปยังบริการ เมื่อใช้ร่วมกันมีพลัง แต่ต้องตั้งค่าให้สอดคล้องกัน เพื่อไม่ให้ฟิวส์เปิดเร็วเกินไปจากข้อผิดพลาดเดี่ยวๆ ปกติ

ผลลัพธ์ที่คาดหวัง: เมื่อบริการไม่พร้อมใช้งานเป็นเวลานาน client จะหยุดส่งคำขอไปยังบริการนั้น, ส่งคืนข้อความสำรองอย่างรวดเร็ว, และตรวจสอบการฟื้นตัวเป็นระยะ

✅ ตรวจสอบ: ทำให้เซิร์ฟเวอร์ทดสอบไม่พร้อมใช้งาน client ควรหลังจากความล้มเหลวหลายครั้ง หยุดส่งคำขอ (open), และเมื่อเซิร์ฟเวอร์กลับมาให้บริการ client ควรกลับมาทำงานปกติผ่าน half-open

ตรวจสอบผลลัพธ์: ควรนับ metric ใดบ้าง

ความทนทานไม่สามารถประเมินด้วยตาเปล่า ต้องใช้ตัวเลข นี่คือ metric สำคัญที่แสดงว่า client เชื่อถือได้มากขึ้นหรือไม่

ตัวชี้วัดหลัก

  • สัดส่วนคำตอบสำเร็จ (success rate) – เปอร์เซ็นต์ของคำขอที่จบด้วยรหัส 2xx ยิ่งสูงยิ่งดี พยายามให้ค่าสูงคงที่แม้ภายใต้โหลด
  • p95 latency – เวลาที่ 95% ของคำขอเสร็จสิ้น ค่านี้ซื่อสัตย์กว่าค่าเฉลี่ย เพราะแสดงว่าส่วนใหญ่รู้สึกอย่างไร ไม่ใช่แค่คำขอที่โชคดี
  • สัดส่วน 429 – เปอร์เซ็นต์ของคำตอบด้วยรหัส 429 ถ้าสูง แสดงว่าคุณส่งคำขอก้าวร้าวเกินไป เป้าหมายคือลดให้เหลือน้อยที่สุด
  • จำนวนครั้งส่งซ้ำต่อคำขอ – แสดงว่าความสำเร็จนั้นยากแค่ไหน การเพิ่มขึ้นบ่งบอกถึงปัญหา
  • จำนวนครั้งที่ circuit breaker เปิด – การเปิดบ่อยครั้งแสดงถึงความไม่เสถียรของบริการหรือการตั้งค่าที่ก้าวร้าวเกินไป

รายการตรวจสอบความพร้อม

  1. ตั้ง timeout ครบทุกขั้นตอน ไม่มีคำขอใดค้างตลอดไป
  2. Retries ทำงานเฉพาะกับคำขอ idempotent และรหัสที่ปลอดภัย
  3. Backoff เพิ่มขึ้นแบบ exponential และมี jitter
  4. เคารพ Retry-After เสมอ
  5. Parallelism ถูกจำกัดด้วย semaphore ต่อโฮสต์
  6. พูลการเชื่อมต่อกับ keep-alive ตั้งค่าสอดคล้องกับขีดจำกัด
  7. ปฏิกิริยาต่อ 429 ช่วยลดจังหวะ ไม่ใช่เพิ่มการส่งซ้ำ
  8. เมทริกซ์การกระทำตามรหัสถูกใช้งาน
  9. Circuit breaker ป้องกันความล้มเหลวที่ยืดเยื้อ
  10. Metric ถูกเก็บและพร้อมสำหรับการวิเคราะห์

จะรู้ได้อย่างไรว่า client ทนทานขึ้น

เปรียบเทียบ metric ก่อนและหลังปรับปรุงภายใต้โหลดเดียวกัน Client ที่ทนทานจะมีสัดส่วนสำเร็จสูง, สัดส่วน 429 ต่ำ, p95 คงที่, และไม่มี workers ค้าง แม้เซิร์ฟเวอร์จะตามใจ แต่บริการของคุณยังคงทำงานโดยไม่ล้มลูกโซ่

✅ ตรวจสอบ: ทำการทดสอบโหลดบน endpoint ทดสอบ ถ้าภายใต้โหลดสัดส่วนสำเร็จยังคงสูงและไม่มีงานค้าง – ยินดีด้วย client ของคุณทนทานแล้ว

ข้อผิดพลาดทั่วไปและวิธีแก้ไข

มาดูหลุมพรางที่พบบ่อยที่เกือบทุกคนเคยเจอ

ข้อผิดพลาด 1: Retries ทำให้โหลดเพิ่มขึ้น

ปัญหา: เซิร์ฟเวอร์โอเวอร์โหลด และการส่งซ้ำที่รุนแรงของคุณทำให้เซิร์ฟเวอร์พังสนิท สาเหตุ: ส่งซ้ำโดยไม่มี backoff และไม่ลดจังหวะ วิธีแก้: เพิ่ม exponential backoff พร้อม jitter, จำกัดจำนวนครั้ง, ลด parallelism โดยรวมเมื่อมีข้อผิดพลาดเพิ่มขึ้น

ข้อผิดพลาด 2: ส่งซ้ำคำขอที่ไม่ idempotent

ปัญหา: คำสั่งซื้อซ้ำ, การหักเงินซ้ำ, เรกคอร์ดซ้ำ สาเหตุ: ส่งซ้ำ POST requests โดยไม่ยั้ง วิธีแก้: ส่งซ้ำเฉพาะเมธอดที่ idempotent สำหรับ POST ให้ใช้คีย์ idempotency ที่เซิร์ฟเวอร์จดจำและจะไม่ดำเนินการซ้ำ

ข้อผิดพลาด 3: รักษา 429 ด้วยการเปลี่ยน IP ไม่รู้จบ

ปัญหา: คุณเปลี่ยน IP ซ้ำแล้วซ้ำเล่า แต่ 429 ก็ยังมา สาเหตุ: ขีดจำกัดไม่ได้ผูกกับ IP แต่ผูกกับคีย์หรือบัญชี หรือคุณแค่ส่งคำขอมากเกินไปโดยรวม วิธีแก้: ลดจังหวะและเคารพ Retry-After การเปลี่ยน IP เป็นเพียงเครื่องมือหนึ่ง ไม่ใช่สิ่งทดแทนความสุภาพ

ข้อผิดพลาด 4: พายุส่งซ้ำแบบซิงโครนัส

ปัญหา: client ทั้งหมดส่งซ้ำในเวลาเดียวกัน เซิร์ฟเวอร์ล้มอีกครั้ง สาเหตุ: backoff ที่ไม่มี jitter วิธีแก้: เพิ่มองค์ประกอบสุ่มให้กับการหยุดแต่ละครั้ง

ข้อผิดพลาด 5: Workers ค้าง

ปัญหา: บริการค่อยๆ หยุดประมวลผลงาน สาเหตุ: ไม่มี timeout, คำขอค้างตลอดไป วิธีแก้: ตั้ง connect, read และ total timeout สำหรับทุกคำขอ

ข้อผิดพลาด 6: สิทธิ์ semaphore รั่ว

ปัญหา: เมื่อเวลาผ่านไป client หยุดส่งคำขอ สาเหตุ: สิทธิ์ semaphore ไม่ถูกปล่อยเมื่อเกิดข้อผิดพลาด วิธีแก้: ปล่อยสิทธิ์ในบล็อก finally เพื่อให้แน่ใจว่าเกิดขึ้นเสมอ

ข้อผิดพลาด 7: ตอบสนองต่อ 407 ผิด

ปัญหา: client ส่งซ้ำและเปลี่ยน IP ไม่รู้จบ แต่ยังได้รับ 407 สาเหตุ: รหัส 407 มาจาก proxy และหมายถึงข้อผิดพลาด authentication ของ proxy ไม่ใช่ปัญหาของบริการ วิธีแก้: ตรวจสอบและแก้ไขข้อมูลรับรอง proxy การส่งซ้ำที่นี่ไร้ประโยชน์

โค้ดสำเร็จรูป

ด้านล่างเป็นแนวทางในสามสแตก ปรับให้เข้ากับโปรเจกต์ของคุณ

Python บน httpx

สร้าง client httpx พร้อม timeout ที่ชัดเจนผ่านออบเจกต์ Timeout ซึ่งแยก connect และ read ตั้งค่าขีดจำกัดพูลผ่าน httpx Limits โดยระบุจำนวนการเชื่อมต่อสูงสุดต่อโฮสต์ ห่อหุ้มการเรียกในลูป retry: เมื่อ 429 และ 503 ให้อ่าน Retry-After คำนวณการหยุดเป็นค่าสูงสุดระหว่าง exponential backoff กับ jitter และค่า Retry-After จากนั้นรอด้วย asyncio sleep จำกัด parallelism ด้วย asyncio Semaphore ปล่อยสิทธิ์ในบล็อก finally ส่งซ้ำเฉพาะเมธอดที่ idempotent จำกัดจำนวนครั้งที่ 5

Python บน urllib3 Retry

ไลบรารี urllib3 มีกลไกพร้อมใช้ สร้างออบเจกต์ Retry ด้วยพารามิเตอร์: total กำหนดจำนวนครั้ง, backoff_factor เปิดใช้งาน exponential backoff, status_forcelist ระบุรหัสสำหรับส่งซ้ำ เช่น 429, 500, 502, 503, 504 พารามิเตอร์ respect_retry_after_header รวมการเคารพ Retry-After ส่ง Retry นี้ไปยัง PoolManager หรือใน HTTPAdapter ของ requests นี่เป็นวิธีที่เร็วที่สุดในการได้ความทนทานพื้นฐานโดยไม่ต้องเขียนลูปเอง

Node.js

ใช้ fetch ในตัวกับ AbortController สำหรับ timeout: สร้าง controller, ตั้ง setTimeout ให้ abort, ส่ง signal ไปยัง fetch ห่อหุ้มการเรียกในฟังก์ชันที่มีลูป retry ตรวจสอบ response.status: เมื่อ 429 และ 503 ให้อ่านส่วนหัว Retry-After ผ่าน response.headers.get, คำนวณการหยุดด้วย jitter, รอผ่าน promise กับ setTimeout สำหรับการจำกัด parallelism ให้ใช้ semaphore แบบ promise อย่างง่าย หรือไลบรารียอดนิยม ควบคุมจำนวน promise พร้อมกันผ่านคิว

Go

ใน Go ตั้งค่า http.Client ด้วยฟิลด์ Timeout สำหรับ timeout รวม และตั้งค่า Transport ด้วยพารามิเตอร์ MaxIdleConnsPerHost และ IdleConnTimeout สำหรับพูลและ keep-alive สำหรับ connect timeout ให้ใช้ DialContext กับ net.Dialer ใช้งานลูป retry: เมื่อ 429 และ 503 ให้อ่านส่วนหัว Retry-After, คำนวณการหยุดผ่าน time.Duration ด้วย exponential growth และ jitter สุ่ม, รอผ่าน time.Sleep หรือ select กับ context จำกัด parallelism ด้วย buffered channel เป็น semaphore: เขียนไปยัง channel ก่อน request, อ่านจาก channel ใน defer หลังจบ

คำแนะนำ: ในทุกภาษา ให้นำการตั้งค่า (timeout, จำนวนครั้ง, ขีดจำกัด parallelism) ออกมาเป็น configuration แทนที่จะ hardcode เพื่อให้ปรับพฤติกรรมตามแต่ละบริการได้โดยไม่ต้องเขียนโค้ดใหม่

ความสามารถเพิ่มเติมและการปรับแต่ง

เมื่อ client พื้นฐานทำงานได้แล้ว ก็สามารถทำให้ฉลาดขึ้นได้

Adaptive rate limiting

แทนที่จะใช้ขีดจำกัดคงที่ ให้ทำให้ลอยตัวได้ อ่านส่วนหัว X-RateLimit-Remaining และลดจังหวะล่วงหน้าเมื่อเหลือน้อย คุณจะหลีกเลี่ยง 429 ก่อนที่จะเกิดขึ้น

ลำดับความสำคัญของงาน

ไม่ใช่ทุกคำขอเท่าเทียมกัน สร้างคิวที่มีลำดับความสำคัญ: งานสำคัญทำก่อน งานไม่จำเป็นถูกเลื่อนออกไปก่อนเมื่อเกิดการเสื่อมสภาพ

แคช

สำหรับ GET requests ที่ idempotent เพิ่มแคชที่มีอายุสั้น ซึ่งช่วยลดโหลดบนเซิร์ฟเวอร์และสัดส่วน 429 โดยไม่ต้องใช้เทคนิคอื่น

การสังเกตการณ์

เชื่อมต่อ structured logs และ metrics บันทึกทุกการส่งซ้ำ, ทุกการเปิด circuit breaker, ทุกการหยุดนาน เพื่อให้คุณพบจุดคอขวดได้เร็วเมื่อเกิดเหตุการณ์

คำแนะนำ: เริ่มจาก client เรียบง่าย และเพิ่มฟีเจอร์ขั้นสูงเมื่อจำเป็นจริงๆ ความซับซ้อนก่อนเวลาก็แย่พอๆ กับการไม่มีเลย

FAQ: คำถามที่พบบ่อย

ต้องเคารพ Retry-After เสมอหรือไม่ แม้จะนานมาก?

ใช่ ถ้า Retry-After นานเกินไปสำหรับสถานการณ์ของคุณ ควรเลื่อนงานหรือส่งคืนคำตอบที่ลดทอน ดีกว่าส่งซ้ำก่อนกำหนด การไม่เคารพ Retry-After มักนำไปสู่ 429 อีกครั้ง

ส่งซ้ำ POST requests ได้ไหม?

ได้แต่ด้วยความระมัดระวัง ถ้าการดำเนินการไม่ idempotent การส่งซ้ำอาจสร้างรายการซ้ำ ใช้คีย์ idempotency เพื่อให้เซิร์ฟเวอร์ปกป้องคุณจากการดำเนินการซ้ำ

จำนวนคำขอพร้อมกันเริ่มต้นที่เท่าไหร่ดี?

เริ่มต้นน้อยๆ เช่น 5-10 ต่อโฮสต์ แล้วค่อยๆ เพิ่มโดยสังเกตสัดส่วน 429 และ p95 เมื่อ 429 เริ่มเพิ่มขึ้น – คุณถึงเพดานแล้ว

429 ต่างจาก 503 ในทางปฏิบัติอย่างไร?

429 เกี่ยวกับจังหวะของคุณ: คุณส่งบ่อยเกินไป 503 เกี่ยวกับเซิร์ฟเวอร์: มันโอเวอร์โหลดหรือกำลังบำรุงรักษา เมื่อ 429 ควรลดจังหวะและอาจเปลี่ยน IP เมื่อ 503 การเปลี่ยน IP ไม่มีประโยชน์ แค่ลองใหม่ภายหลัง

ทำไม client ของฉันบางครั้งได้รหัส 407?

รหัส 407 มาจาก proxy และหมายถึงการ authentication ที่ proxy ล้มเหลว ตรวจสอบชื่อผู้ใช้และรหัสผ่าน proxy การเปลี่ยน IP และ backoff จะไม่ช่วย – นี่คือข้อผิดพลาดในการตั้งค่า

จำนวนครั้งส่งซ้ำที่ปกติคือเท่าไหร่?

ปกติ 3 ถึง 5 ครั้ง มากกว่านั้นไม่ค่อยมีประโยชน์: ถ้าไม่สำเร็จในห้าครั้ง ปัญหาจะร้ายแรงกว่าข้อผิดพลาดชั่วคราว

ทำไมต้องมี jitter ในเมื่อ backoff ก็เพิ่มขึ้นอยู่แล้ว?

ไม่มี jitter client หลายตัวจะส่งซ้ำในเวลาเดียวกัน ทำให้เกิดพายุซิงโครนัส การกระจายแบบสุ่นช่วยกระจายการส่งซ้ำตามเวลาและทำให้เซิร์ฟเวอร์ได้พักอย่างนุ่มนวล

เมื่อใดควรเปิด circuit breaker?

เมื่อสัดส่วนข้อผิดพลาดใน sliding window เกินเกณฑ์ที่กำหนด เช่น ครึ่งหนึ่งของคำขอ สิ่งนี้ปกป้องทั้งเซิร์ฟเวอร์และคุณจากการใช้ทรัพยากรโดยเปล่าประโยชน์

การเปลี่ยน IP ช่วยแก้ 429 หรือไม่?

บางครั้ง ถ้าขีดจำกัดผูกกับ IP แต่ถ้าขีดจำกัดอยู่ที่คีย์หรือบัญชี การเปลี่ยน IP ก็ไร้ประโยชน์ การเปลี่ยน IP ไม่ได้แทนที่การลดจังหวะและการเคารพ Retry-After

ควรแสดงอะไรให้ผู้ใช้เมื่อบริการล้ม?

ข้อความสำรองที่เข้าใจได้, ข้อมูลจากแคช หรือผลลัพธ์ที่ลดทอน ดีกว่าการค้างหรือข้อผิดพลาดทางเทคนิคบนหน้าจอ

บทสรุป

คุณผ่านเส้นทางที่ยาวไกลแล้ว มาทบทวนสิ่งที่คุณสร้างขึ้น คุณตั้งค่า timeout ทุกขั้นตอนเพื่อให้ไม่มีคำขอค้างตลอดไป คุณเพิ่ม retries อัจฉริยะด้วย exponential backoff และ jitter ซึ่งส่งซ้ำเฉพาะคำขอที่ปลอดภัยและเคารพ Retry-After คุณจำกัด parallelism ด้วย semaphore และตั้งค่าพูลการเชื่อมต่อกับ keep-alive คุณสร้างปฏิกิริยาที่ถูกต้องต่อ 429 และจัดทำเมทริกซ์การกระทำตามรหัสตอบกลับ สุดท้าย คุณเพิ่ม circuit breaker และการเสื่อมสภาพแบบควบคุมได้

แนวคิดหลักของคู่มือนี้คือ 429 ไม่ใช่ข้อผิดพลาด แต่เป็นการสนทนา เซิร์ฟเวอร์บอกให้คุณลดจังหวะ และ client ที่สุภาพจะฟัง ความทนทานไม่ได้เกิดจากความก้าวร้าว แต่เกิดจากความสามารถในการหยุดในเวลาที่เหมาะสม

จะทำอะไรต่อ

รวบรวม metric ภายใต้โหลดจริงและดูสัดส่วนสำเร็จและ 429 ค่อยๆ ปรับขีดจำกัดตามแต่ละบริการ เพิ่ม adaptive rate limiting ตามส่วนหัว X-RateLimit นำแคชสำหรับคำขอ idempotent มาใช้

จะพัฒนาไปทางไหน

ศึกษาเรื่องพูล IP และสุขภาพของมัน – เป็นพื้นที่ใหญ่ที่เราไม่ได้แตะในที่นี้ เจาะลึกเรื่องการสังเกตการณ์: การติดตาม trace, dashboard, alert และอย่าลืมอ่านเอกสารของบริการที่คุณทำงานด้วย: ขีดจำกัดที่แน่นอนดีกว่าการเดาเสมอ

คุณทำได้ดีมาก ตอนนี้คุณมี client ที่ไม่ตื่นตระหนก แต่ประพฤติตัวอย่างทนทานและสุภาพ นี่คือรากฐานที่ใช้อินทิเกรตที่เชื่อถือได้ ขอให้โชคดีในโปรเจกต์ของคุณ