Cho dù bạn đang phát triển một ứng dụng mới hay đang chạy một dịch vụ có lưu lượng truy cập cao, bạn đều có thể hưởng lợi từ thông tin chi tiết và đề xuất của hướng dẫn này về cách mở rộng quy mô một cách suôn sẻ bằng FCM. Những khái niệm và phương pháp này có thể giúp bạn tránh được tác động tiêu cực khi cần gửi một lượng lớn thư.
Các thuật ngữ và khái niệm chính
Yêu cầu tin nhắn: Yêu cầu tin nhắn FCM; được sử dụng thay thế cho "yêu cầu", "tin nhắn" hoặc "truy vấn".
Số yêu cầu mỗi giây (RPS): Một chỉ số để mô tả tốc độ của số yêu cầu đến tới FCM; được sử dụng thay thế cho nhau với Truy vấn mỗi giây (QPS).
Mã thông báo hạn mức, bộ chứa mã thông báo và nạp lại: Khi gửi thông báo qua API FCM HTTP v1, mỗi yêu cầu sẽ sử dụng một Mã thông báo hạn mức được phân bổ trong một khoảng thời gian nhất định. Cửa sổ này, được gọi là "Token Bucket" (Vùng chứa mã thông báo), sẽ nạp lại đầy vào cuối khoảng thời gian. Ví dụ: API HTTP v1 phân bổ 600.000 mã thông báo hạn mức cho mỗi Vùng chứa mã thông báo 1 phút. Vùng chứa này sẽ được nạp đầy vào cuối mỗi khoảng thời gian 1 phút.
Giới hạn tốc độ phía máy chủ: Khi lưu lượng truy cập vượt quá dung lượng của dịch vụ FCM, các yêu cầu vượt quá dung lượng phân phát sẽ bị từ chối để giới hạn tốc độ luồng truy cập. Hệ thống có thể trả về phản hồi lỗi 429 có tiêu đề retry-after để cho biết rằng bạn nên đợi một khoảng thời gian nhất định trước khi thử lại yêu cầu.
Điều tiết phía máy khách: Khi quan sát thấy lỗi yêu cầu, độ trễ cao hoặc lỗi 429, ứng dụng nên tự nguyện đặt giới hạn luồng đầu ra để tránh tình trạng tắc nghẽn nghiêm trọng hơn.
Thời gian đợi luỹ thừa: Khi thử lại lỗi, hãy thêm độ trễ thời gian tăng theo cấp số nhân. Ví dụ: 1 giây, 2 giây, 4 giây, 8 giây, 16 giây, 32 giây.
Rối loạn: Tránh thử lại các yêu cầu theo khoảng thời gian chính xác. Với tính năng dao động, bạn thay đổi độ trễ thử lại thông qua một quy trình ngẫu nhiên để phân phối thống nhất theo thời gian (ví dụ: 0,9 giây, 2,3 giây, 4,1 giây, 8,5 giây, 17,9 giây, 34,7 giây).
Tăng cường thử lại: Khi các yêu cầu không thành công được thử lại mà không có khoảng thời gian đợi/độ trễ luỹ thừa, các yêu cầu này thường tích luỹ và thêm vào tải lưu lượng truy cập đang diễn ra, có thể "khuếch đại" và làm trầm trọng thêm các vấn đề tắc nghẽn lưu lượng truy cập.
Vấn đề: lưu lượng truy cập tăng đột biến
FCM xử lý hàng triệu yêu cầu mỗi giây (RPS). Nguyên nhân lớn nhất gây ra tình trạng tắc nghẽn hệ thống, sự cố về độ trễ và sự cố ngừng hoạt động là sự gia tăng đột biến của lưu lượng truy cập.
Giao thông tăng đột biến là gì?
Có một số loại mức tăng đột biến về lưu lượng truy cập.
Sự gia tăng theo giờ: FCM nhận được lưu lượng truy cập nhiều hơn gấp đôi trong khoảng thời gian từ 30 giây đến 2 phút đầu tiên của mỗi giờ. Tương tự, mặc dù ít hơn, mức tăng đột biến cũng được quan sát ở mốc nửa giờ và 15 phút (ví dụ: 00:15, 00:30, 00:45)
Tăng cường thử lại: Việc thử lại các yêu cầu không thành công hoặc hết thời gian chờ mà không có thời gian đợi luỹ thừa có thể tích luỹ thành các làn sóng lưu lượng truy cập lặp lại trên các đỉnh lưu lượng truy cập hiện có.
Thay đổi đột ngột về mẫu lưu lượng truy cập: Việc hướng lưu lượng truy cập mới đến FCM hoặc di chuyển lưu lượng truy cập đến FCM qua nhiều khu vực mà không có các yếu tố làm mượt (như tăng tốc dần) có thể gây ra đột biến.
Sử dụng mã thông báo hạn mức tải trước: Việc sử dụng hết tất cả mã thông báo hạn mức ở đầu khoảng thời gian hạn mức thay vì phân bổ đều các yêu cầu trên các khoảng thời gian hạn mức sẽ tạo ra sự dao động bật/tắt khó khăn và tốn kém để cân bằng tải.
Sự kiện đặc biệt: Lưu lượng truy cập tăng vọt trong các ngày lễ (Đêm giao thừa) hoặc sự kiện thể thao (Giải vô địch bóng đá thế giới FIFA).
Khắc phục tình trạng lưu lượng truy cập tăng đột biến bằng cách "làm phẳng đường cong"
Phần này mô tả các chiến lược để làm giảm sự gia tăng đột biến về lưu lượng truy cập (nếu có thể) – các chiến lược để "làm phẳng đường cong".
Chỉ dùng FCM cho các trường hợp sử dụng thích hợp
Có một số trường hợp sử dụng mà việc sử dụng FCM để phân phối thông báo là không cần thiết hoặc không phù hợp.
Ví dụ: đối với thông báo sự kiện trên lịch, bạn có thể lên lịch cho một nhiệm vụ cục bộ trong ứng dụng để hiển thị thông báo vào những thời điểm thích hợp thay vì gửi thông báo đó từ máy chủ ứng dụng. Giới hạn thông báo FCM ở chế độ đồng bộ hoá lịch.
Tránh tình trạng tăng đột biến
Một phương pháp chống điều chỉnh theo tỷ lệ là gửi thông báo FCM nhanh chóng mà hệ thống cho phép, thay vì áp dụng chế độ điều tiết phía máy chủ. Hãy cân nhắc những điều sau:
- Tất cả khách hàng của bạn có cần nhận cùng một thông báo trong khoảng thời gian 1 phút không? Ví dụ: khoảng thời gian giao hàng là 5 phút có còn đáp ứng nhu cầu kinh doanh của bạn không?
- Bạn có thể phân đoạn khách hàng dựa trên mức độ ưu tiên để giảm thiểu sự biến động không?
- Có thể lên lịch gửi thông báo trước không?
Bất cứ khi nào có thể: hãy tránh các chiến lược khiến bạn nhanh chóng dùng hết hạn mức gửi FCM, chỉ để lặp lại mẫu này ngay khi bộ chứa mã thông báo được nạp lại. Mẫu truy cập này gây ra các vấn đề về cân bằng tải cho FCM và các hệ thống phụ thuộc của FCM. Tăng lưu lượng truy cập từ từ nhất có thể. Tối thiểu, hãy tăng dần từ 0 đến RPS tối đa trong khoảng thời gian 60 giây. Ưu tiên các khoảng thời gian dài hơn để có RPS cao hơn.
Tránh lưu lượng truy cập "theo giờ"
Nếu có thể: tránh gửi tin nhắn trong khoảng thời gian 2 phút của mỗi mốc :00, :15, :30 và :45 phút.
Triển khai tính năng điều tiết phía máy chủ
Triển khai tính năng điều tiết phía máy chủ để theo dõi và quản lý luồng lưu lượng truy cập đến FCM.
Xử lý các lần thử lại
Mặc dù FCM luôn nỗ lực để có khả năng hoạt động cao, nhưng đôi khi một số yêu cầu sẽ hết thời gian chờ hoặc không thành công. Mặc dù có nhiều lý do, nhưng các phương pháp hay nhất sau đây sẽ tối ưu hoá hành vi thử lại để phân phối thông báo sớm nhất có thể, đồng thời giảm thiểu tác động đến tình trạng tắc nghẽn lưu lượng truy cập.
Thời gian chờ
Đặt thời gian chờ ít nhất 10 giây cho các yêu cầu gửi trước khi thử lại. Hầu hết các Lệnh gọi quy trình từ xa nội bộ của FCM đều sử dụng thời gian chờ 10 giây.
Lỗi
- Đối với lỗi 400, 401, 403, 404: huỷ và không thử lại.
- Đối với lỗi 429: hãy thử lại sau khi đợi khoảng thời gian được đặt trong tiêu đề retry-after. Nếu bạn không đặt tiêu đề retry-after, thì giá trị mặc định sẽ là 60 giây.
- Đối với 500 lỗi: hãy thử lại bằng thuật toán thời gian đợi luỹ thừa.
Thuật toán thời gian đợi luỹ thừa
Để tránh tình trạng tăng cường thử lại, hãy triển khai thời gian đợi luỹ thừa với độ trễ để thử lại các yêu cầu. Ví dụ: SDK Quản trị Firebase triển khai thời gian đợi luỹ thừa.
Dưới đây là một số chế độ cài đặt được đề xuất khác:
- Khoảng thời gian tối thiểu: Không thử lại ngay một yêu cầu không thành công bằng FCM. Chờ ít nhất 10 giây trước khi thử lại một yêu cầu không thành công.
- Khoảng thời gian tối đa: Đặt khoảng thời gian tối đa để loại bỏ các yêu cầu không còn kịp thời, thay vì thử lại vô thời hạn.
Nếu một yêu cầu liên tục được thử lại bằng thuật toán thời gian đợi luỹ thừa và vẫn không thành công sau 60 phút, thì yêu cầu đó sẽ bị phân loại sai là lỗi có thể thử lại, hoặc FCM đang gặp sự cố ngừng dịch vụ, trong đó việc thử lại có thể vô tình làm trầm trọng thêm tình hình.
Tạo kế hoạch phát hành và khôi phục, đồng thời thực hiện các thay đổi dần dần
Khi thực hiện các thay đổi về lưu lượng truy cập trên quy mô lớn, chẳng hạn như tăng lưu lượng truy cập đến FCM hoặc chuyển lưu lượng truy cập giữa các khu vực hoặc mạng, việc thiết kế kế hoạch triển khai/huỷ triển khai và triển khai các thay đổi dần dần sẽ bảo vệ người dùng, dịch vụ và FCM của bạn.
- Kế hoạch triển khai giúp các bên liên quan điều chỉnh kỳ vọng. Trong một số trường hợp (xem phần thảo luận bên dưới), bạn nên chia sẻ trước kế hoạch triển khai với nhóm FCM để tránh những điều bất ngờ.
- Kế hoạch khôi phục cho phép bạn tính đến các trường hợp dự phòng và chuẩn bị cơ chế để khôi phục nhanh chóng và an toàn sau những lỗi không lường trước được.
- Việc thay đổi dần dần có hai khía cạnh:
- Tăng tốc "từng bước": Các bước nên là 1% -> 5% -> 10% -> 25% -> 50% -> 75% -> 100% hoặc tốt hơn. "Ngâm" (quan sát hành vi của hệ thống khi tải) mỗi bước trong khoảng từ 1 ngày đến 1 tuần. Điều này giúp bạn phát hiện các vấn đề tiềm ẩn trước khi "nâng cấp" tiếp theo
- Tăng lưu lượng truy cập dần dần: Khi thực hiện từng "bước" để tăng lưu lượng truy cập, hãy điều chỉnh lưu lượng truy cập trong khoảng thời gian ít nhất một giờ. Điều này cho phép cơ sở hạ tầng cân bằng tải của FCM mở rộng quy mô lưu lượng truy cập mới của bạn một cách thích hợp, đồng thời giảm thiểu nguy cơ xảy ra các điểm nóng và tình trạng tắc nghẽn.
Dưới đây là một tình huống giả định để di chuyển 500.000 RPS trên toàn cầu từ API HTTP cũ của FCM sang API HTTP v1 của FCM:
| Tuần | Bước | Chiến lược tăng dần từng bước |
|---|---|---|
| 0 | Tăng dần 1% | Tăng dần từ 0 đến 5.000 RPS cho FCM HTTP phiên bản 1 trong vòng một giờ. |
| 1 | Tăng dần 5% | Tăng dần từ 5.000 lên 25.000 RPS trong 2 giờ. |
| 2 | Tăng dần 10% | Tăng dần từ 25.000 lên 50.000 RPS trong 2 giờ |
| 3 | Tăng dần 25% | Tăng từ 50.000 lên 125.000 RPS trong 3 giờ |
| 4 | Tăng dần 50% | Tăng từ 125.000 lên 250.000 RPS trong 6 giờ |
| 5 | Tăng tốc 75% | Tăng từ 250.000 lên 375.000 RPS trong 6 giờ |
| 6 | Tăng dần 100% | Tăng từ 375.000 lên 500.000 RPS trong 6 giờ |
Kế hoạch khôi phục giả định:
- Nếu độ trễ 95% tăng lên hơn 500 mili giây hoặc nếu tỷ lệ lỗi vượt quá 1% trong hơn một giờ ở bất kỳ bước nào, hãy sử dụng cấu hình động để quay lại bước trước ngay lập tức.
- Tiếp tục quay lại các bước trước đó cho đến khi độ trễ và tỷ lệ lỗi trở về mức thông thường.
Thời điểm liên hệ với FCM
Hãy liên hệ với FCM thông qua Nhóm hỗ trợ của Firebase nếu bạn gặp phải trường hợp sau:
- Hạn mức mặc định không còn đáp ứng trường hợp sử dụng của bạn
- Bạn đang thay đổi mô hình gửi thư trong khoảng thời gian 3 tháng với quy mô 100.000 RPS trên toàn cầu hoặc 30.000 RPS theo lục địa.