ไม่ว่าคุณจะกำลังพัฒนาแอปที่เพิ่งเริ่มเผยแพร่หรือใช้บริการที่มีผู้ใช้งานจำนวนมากอยู่แล้ว คุณจะได้รับประโยชน์จากการดูข้อมูลเชิงลึกและคำแนะนำเกี่ยวกับการปรับขนาดของคู่มือนี้ กับ FCM ได้อย่างราบรื่น แนวคิดและแนวทางปฏิบัติเหล่านี้ช่วยคุณหลีกเลี่ยงเชิงลบ จะส่งผลต่อเวลาที่ต้องส่งข้อความจำนวนมาก
คำสำคัญและแนวคิด
คำขอส่งข้อความ: คำขอส่งข้อความ FCM ที่ใช้แทนคำว่า "request" "message" หรือ "query"
คำขอต่อวินาที (RPS): เมตริกที่ใช้อธิบายอัตราการส่งขาเข้า คำขอไปยัง FCM ที่ใช้แทนกันได้กับคำค้นหาต่อวินาที (QPS)
โทเค็นโควต้า ที่เก็บข้อมูลโทเค็น และรีฟิล: เมื่อส่งข้อความให้กับ API ของ HTTP v1 ของ FCM คำขอแต่ละรายการจะใช้โทเค็นโควต้าที่จัดสรรไว้ให้ในเวลาที่กำหนด หน้าต่างนี้เรียกว่า "ที่เก็บข้อมูลโทเค็น" จะเติมจนเต็มในช่วงท้าย กรอบเวลา ตัวอย่างเช่น HTTP v1 API จัดสรรโควต้าโทเค็น 600,000 รายการสำหรับแต่ละโทเค็น ที่เก็บข้อมูลโทเค็น 1 นาที ซึ่งจะนำไปเติมให้เต็มเมื่อหมดเวลา 1 นาทีของแต่ละช่วง
การควบคุมฝั่งเซิร์ฟเวอร์: เมื่อปริมาณการเข้าชมสูงกว่าปริมาณการรับส่งข้อมูลของบริการ FCM
คำขอที่มากกว่าความสามารถในการแสดงผลจะถูกปฏิเสธเพื่อจำกัดอัตราคำขอขาเข้า
ระบบอาจตอบกลับข้อผิดพลาด 429 รายการที่มีส่วนหัว retry-after เพื่อระบุ
ว่าคุณควรรอในระยะเวลาที่กำหนดก่อนที่จะลองส่งคำขออีกครั้ง
การควบคุมฝั่งไคลเอ็นต์: เมื่อลูกค้าสังเกตเห็นว่าคำขอล้มเหลว เวลาในการตอบสนองจะสูง
หรือข้อผิดพลาด 429 รายการ ควรระบุการไหลออกของขีดจำกัดอัตราคำขอโดยสมัครใจเพื่อหลีกเลี่ยงไม่ให้เกิดการกำเริบ
สำหรับความคับคั่ง
Exponential Backoff เมื่อลองแก้ไขข้อผิดพลาดอีกครั้ง ให้เพิ่มความล่าช้าของเวลาเป็นทวีคูณ เช่น 1s, 2, 4, 8, 16, 32 วินาที
การกระตุก: หลีกเลี่ยงการส่งคำขอซ้ำในช่วงเวลาที่แน่นอน เสียงกระตุก คุณจะเปลี่ยนการหน่วงเวลาการลองซ้ำผ่านกระบวนการสุ่มเพื่อกระจายอย่างเท่าเทียมกัน ในช่วงระยะเวลาหนึ่ง (เช่น 0.9, 2.3, 4.1, 8.5, 17.9, 34.7)
ลองขยายเสียงอีกครั้ง: เมื่อมีการลองขยายคำขอที่ล้มเหลวอีกครั้งโดยไม่มีเลขชี้กำลัง ย้อนกลับ/สั่น มักจะสะสมและเพิ่มปริมาณการรับส่งข้อมูลอย่างต่อเนื่อง ที่อาจ "ขยายผล" และปัญหาการจราจรที่คับคั่งยิ่งขึ้นไปอีก
ปัญหา: การเข้าชมที่เพิ่มขึ้นอย่างรวดเร็ว
FCM ประมวลผลคำขอหลายล้านรายการต่อวินาที (RPS) ผู้มีส่วนร่วมมากที่สุดสำหรับ ปัญหาความคับคั่งของระบบ ปัญหาเวลาในการตอบสนอง และการหยุดทำงานคือการเข้าชมที่เพิ่มขึ้นอย่างรวดเร็ว
การจราจรที่ติดขัดคืออะไร
การเข้าชมที่เพิ่มขึ้นอย่างรวดเร็วมีหลายประเภท
การเพิ่มขึ้นอย่างรวดเร็วในทันที: FCM ได้รับการเข้าชมมากกว่า 2 เท่าในช่วง 30 ครั้งแรก วินาทีถึง 2 นาทีในแต่ละชั่วโมง มีความคล้ายคลึงกัน แม้ว่าจะน้อยกว่า แต่ยอดแหลมก็ สังเกตที่ตัวเลขช่วงครึ่งชั่วโมงและ 15 ชั่วโมง (เช่น 00:15, 00:30, 00:45)
ลองขยายเสียงอีกครั้ง: การลองส่งคำขอที่ไม่สำเร็จหรือหมดเวลาอีกครั้งโดยไม่มี Exponential Backoff จะสะสมจนเกิดเป็นคลื่นการเข้าชมซ้ำๆ ทับยอดการเข้าชมที่มีอยู่เดิม
การเปลี่ยนแปลงรูปแบบการเข้าชมอย่างกะทันหัน: การนำการเข้าชมใหม่ไปยัง FCM หรือการย้ายการเข้าชม ไปยัง FCM ในภูมิภาคต่างๆ โดยไม่มีปัจจัยที่ทำให้ความราบรื่น เช่น การค่อยๆ เพิ่มจำนวน ทำให้เพิ่มขึ้นอย่างฉับพลัน
การใช้โทเค็นโควต้าแบบโหลดด้านหน้า: การใช้โทเค็นโควต้าทั้งหมดจนหมดเมื่อเริ่มต้น กรอบเวลาของโควต้าแทนที่จะกระจายคำขอไปทั่วทั้งโควต้าให้เท่าๆ กัน หน้าต่างจะเปิดการเด้งตัวขึ้นออกที่ยากและมีราคาแพง และการจัดสรรภาระงาน
กิจกรรมพิเศษ: การเข้าชมที่เพิ่มขึ้นในช่วงวันหยุด (วันส่งท้ายปีเก่า) หรือการแข่งขันกีฬา (ฟุตบอลโลก FIFA)
แก้ไขการเข้าชมที่เพิ่มขึ้นอย่างรวดเร็วโดย "การปรับยอดเส้นโค้ง"
ส่วนนี้จะอธิบายกลยุทธ์ที่จะทำให้ยอดการเข้าชมพุ่งสูงขึ้นอย่างราบรื่น กลยุทธ์ในการ "ทำให้เส้นโค้งแบนราบ"
ใช้ FCM สำหรับกรณีการใช้งานที่เหมาะสมเท่านั้น
มีบางกรณีที่การใช้ FCM เพื่อส่งการแจ้งเตือนไม่ จำเป็นหรือเหมาะสม
เช่น สำหรับการแจ้งเตือนกิจกรรมในปฏิทิน คุณจะกำหนดเวลางานในพื้นที่ได้ใน แอปของคุณให้แสดงการแจ้งเตือนในเวลาที่เหมาะสมแทนการส่ง จากเซิร์ฟเวอร์แอปของคุณ จำกัดข้อความ FCM ให้ซิงค์ปฏิทินเท่านั้น
หลีกเลี่ยงการเพิ่มขึ้นอย่างฉับพลัน
รูปแบบที่ต่อต้านการปรับขนาดอย่างหนึ่งคือส่งการแจ้งเตือน FCM ให้เร็วที่สุด อนุญาต แทนที่จะใช้การควบคุมฝั่งเซิร์ฟเวอร์ ลองพิจารณาวิธีเหล่านี้
- ลูกค้าทั้งหมดของคุณต้องได้รับการแจ้งเตือนเดียวกันภายในช่วงเวลา 1 นาทีหรือไม่ ตัวอย่างเช่น กรอบเวลาการนำส่ง 5 นาทีจะยังตอบโจทย์ความต้องการทางธุรกิจของคุณไหม
- คุณสามารถแบ่งกลุ่มลูกค้าตามลำดับความสำคัญเพื่อให้มีความราบรื่นเหนือช่วงที่เพิ่มขึ้นหรือไม่
- คุณสามารถตั้งการแจ้งเตือนล่วงหน้าได้ไหม
เมื่อเป็นไปได้: หลีกเลี่ยงกลยุทธ์ที่ทำให้โควต้าการส่ง FCM ของคุณหมดทันที และให้ทำรูปแบบซ้ำๆ ในทันทีที่เติมที่เก็บข้อมูลโทเค็น การเข้าถึงนี้ รูปแบบสร้างปัญหาการจัดสรรภาระงานสำหรับ FCM และ ระบบต่างๆ เพิ่มการเข้าชมให้น้อยที่สุดเท่าที่จะทำได้ เพิ่มขั้นต่ำจาก 0 ถึง RPS สูงสุดตลอดกรอบเวลา 60 วินาที ต้องการกรอบเวลาที่นานขึ้นสำหรับระยะเวลาที่นานขึ้น RPS
หลีกเลี่ยง "เฉพาะช่วงเวลา" การจราจร
หากเป็นไปได้: ให้หลีกเลี่ยงการส่งข้อความภายในกรอบเวลา 2 นาทีหลังจาก เครื่องหมาย :00, :15, :30 และ :45 นาที
ใช้การควบคุมฝั่งเซิร์ฟเวอร์
ใช้การควบคุมฝั่งเซิร์ฟเวอร์เพื่อตรวจสอบและจัดการโฟลว์การรับส่งข้อมูลไปยัง FCM
การจัดการการดำเนินการซ้ำ
แม้ว่า FCM จะพยายามให้มีความพร้อมใช้งานสูง แต่บางครั้งคำขอบางรายการอาจหมดเวลา หรือทำไม่สำเร็จ แม้ว่าเหตุผลอาจแตกต่างกันไป แต่แนวทางปฏิบัติแนะนำต่อไปนี้จะช่วยเพิ่มประสิทธิภาพให้การลองอีกครั้ง เพื่อส่งข้อความให้เร็วที่สุด และลดผลกระทบที่จะเกิดกับ การจราจรที่ติดขัด
หมดเวลา
ตั้งค่าระยะหมดเวลาอย่างน้อย 10 วินาทีสำหรับคำขอส่งก่อน กำลังลองอีกครั้ง การเรียกใช้กระบวนการระยะไกลภายในของ FCM ส่วนใหญ่จะใช้การหมดเวลา 10 วินาที
ข้อผิดพลาด
- สำหรับข้อผิดพลาด 400, 401, 403, 404 ให้ยกเลิกและไม่ต้องลองใหม่
- สำหรับข้อผิดพลาด 429: ลองอีกครั้งหลังจากรอระยะเวลาที่ตั้งไว้ในการลองใหม่หลังจาก ส่วนหัว หากไม่ได้ตั้งค่าการลองอีกครั้งหลังจากตั้งค่าส่วนหัวไว้ ค่าเริ่มต้นจะเป็น 60 วินาที
- สำหรับข้อผิดพลาด 500 โปรดลองอีกครั้งโดยใช้ Exponential Backoff
Exponential Backoff
เพื่อหลีกเลี่ยงการขยายซ้ำ ให้ใช้เลขชี้กำลัง Back-off ที่มีเสียงรบกวนสำหรับคำขออีกครั้ง Firebase Admin SDK สำหรับ เช่น ติดตั้งใช้งาน Exponential Backoff
การตั้งค่าเพิ่มเติมที่แนะนำมีดังนี้
- ช่วงเวลาขั้นต่ำ: อย่าลองดำเนินการกับ FCM ที่ล้มเหลวอีกครั้งในทันที โปรดรออย่างน้อย 10 วินาทีก่อนลองส่งคำขอที่ไม่สำเร็จอีกครั้ง
- ช่วงเวลาสูงสุด: ตั้งค่าช่วงเวลาสูงสุดสำหรับการตัดคำขอที่ไม่ตรงเวลาแล้ว แทนการลองใหม่โดยไม่มีกำหนด
หากมีการพยายามส่งคำขอซ้ำอย่างต่อเนื่องโดยใช้ Exponential Backoff และคำขอยังคง หากผ่านไป 60 นาทีแล้วไม่ผ่าน ข้อผิดพลาดดังกล่าวอาจจัดอยู่ในหมวดหมู่ข้อผิดพลาดที่ลองใหม่ได้ หรือ FCM เกิดการหยุดทำงาน ซึ่งการลองใหม่อาจทำให้อาการกำเริบโดยไม่ได้ตั้งใจ สถานการณ์
สร้างแผนการเปิดตัวและย้อนกลับ และทำการเปลี่ยนแปลงอย่างค่อยเป็นค่อยไป
เมื่อทำการเปลี่ยนแปลงการเข้าชมจำนวนมาก เช่น เพิ่มการเข้าชมใน FCM หรือ การย้ายการเข้าชมตามภูมิภาคหรือเครือข่าย การออกแบบแผนการเปิดตัว/ย้อนกลับ และการใช้การเปลี่ยนแปลงแบบค่อยเป็นค่อยไปจะช่วยปกป้องผู้ใช้ บริการ และ FCM ของคุณ
- แผนการเปิดตัวช่วยสร้างความคาดหวังของผู้มีส่วนเกี่ยวข้องให้สอดคล้องกัน ในบางสถานการณ์ (ที่กล่าวถึงด้านล่าง) คุณอาจต้องแชร์แผนการเปิดตัวกับทีม FCM ล่วงหน้าเพื่อหลีกเลี่ยงเรื่องน่าประหลาดใจ
- แผนย้อนกลับช่วยให้สามารถพิจารณาเผื่อกรณีที่อาจเกิดขึ้นและเตรียมกลไกสำหรับฟื้นตัวจากการทำงานล้มเหลวที่ไม่ได้คาดไว้ได้อย่างรวดเร็วและปลอดภัย
- การเปลี่ยนแปลงแบบค่อยเป็นค่อยไปมี 2 ด้านดังนี้
- "แบบขั้นบันได" การเพิ่มจำนวน: จำนวนก้าวควรเป็น 1% -> 5% -> 10% -> 25% -> 50% -> 75% -> 100% หรือละเอียดกว่านั้น "เปียกน้ำ" (สังเกตการทำงานของระบบขณะโหลด) แต่ละขั้นตอนเป็นเวลา 1 วันถึง 1 สัปดาห์ วิธีนี้จะช่วยให้คุณมองเห็นปัญหาที่อาจเกิดขึ้นก่อน "ขั้นตอนถัดไป" ถัดไป
- การเพิ่มจำนวนการเข้าชมแบบค่อยเป็นค่อยไป: เมื่อทำตามแต่ละ "ก้าว" เพื่อเพิ่มการจราจร ทำให้การจราจรคล่องตัวในรอบเวลาอย่างน้อย 1 ชั่วโมง วิธีนี้จะช่วยให้โครงสร้างพื้นฐานด้านการจัดสรรภาระงานของ FCM ปรับขนาดการรับส่งข้อมูลใหม่ได้อย่างเหมาะสม ในขณะเดียวกันก็ลดความเสี่ยงที่จะเกิดฮอตสปอตและความคับคั่ง
นี่คือสถานการณ์สมมติสำหรับการย้ายข้อมูล RPS กว่า 500,000 รายการทั่วโลกจาก FCM Legacy HTTP API ไปยัง FCM HTTP v1 API
| สัปดาห์ | Step | กลยุทธ์การเพิ่มจำนวนแบบค่อยเป็นค่อยไป |
|---|---|---|
| 0 | การเพิ่มจำนวน 1% | การเพิ่มจำนวนอย่างราบรื่นจาก 0 ถึง 5,000 RPS เป็น FCM HTTP v1 ในช่วงเวลา 1 ชั่วโมง |
| 1 | การเพิ่มจำนวน 5% | การเพิ่มจำนวนอย่างราบรื่นจาก 5,000 เป็น 25,000 RPS ในช่วง 2 ชั่วโมง |
| 2 | การเพิ่มจำนวน 10% | การเพิ่มจำนวนอย่างราบรื่นจาก 25,000 เป็น 50,000 RPS ในช่วง 2 ชั่วโมง |
| 3 | การเพิ่มจำนวน 25% | การเพิ่มจำนวนจาก 50,000 เป็น 125,000 RPS ในช่วง 3 ชั่วโมง |
| 4 | การเพิ่มจำนวน 50% | การเพิ่มจำนวนจาก 125,000 เป็น 250,000 RPS ในช่วง 6 ชั่วโมง |
| 5 | การเพิ่มจำนวน 75% | การเพิ่มจำนวนจาก 250,000 เป็น 375,000 RPS ในช่วง 6 ชั่วโมง |
| 6 | การเพิ่มจำนวน 100% | การเพิ่มจำนวนจาก 375,000 เป็น 500,000 RPS ในช่วง 6 ชั่วโมง |
แผนย้อนกลับสมมติ:
- หากเวลาในการตอบสนอง 95 เปอร์เซ็นไทล์เพิ่มขึ้นเป็นมากกว่า 500 มิลลิวินาที หรือหากอัตราส่วนของข้อผิดพลาดเกิน 1% เป็นเวลานานกว่า 1 ชั่วโมงในขั้นตอนใดก็ตาม ให้ใช้การกำหนดค่าแบบไดนามิกเพื่อย้อนกลับไปที่ขั้นตอนก่อนหน้าทันที
- ย้อนกลับไปยังขั้นตอนก่อนหน้านี้ต่อไปจนกว่าเวลาในการตอบสนองและอัตราส่วนข้อผิดพลาดจะกลับไปเป็นระดับที่ต่ำ
ควรติดต่อ FCM เมื่อใด
ติดต่อ FCM ผ่านทีมสนับสนุน Firebase หากเป็นไปตามเงื่อนไขข้อใดข้อหนึ่งต่อไปนี้
- โควต้าเริ่มต้นไม่ตรงตาม Use Case ของคุณอีกต่อไป
- คุณกำลังเปลี่ยนรูปแบบการส่งภายในกรอบเวลา 3 เดือนที่ ระดับ 100,000 RPS ทั่วโลก หรือ 30,000 RPS ในทวีป