Cho dù đang phát triển một ứng dụng mới hay đã 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 trong 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 số lượng lớn thư.
Các thuật ngữ và khái niệm chính
Yêu cầu gửi tin nhắn: Một yêu cầu gửi tin nhắn FCM; có thể 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 độ yêu cầu đến FCM; được dùng thay thế cho Số truy vấn mỗi giây (QPS).
Mã thông báo hạn mức, Nhóm mã thông báo và Lượng mã thông báo được cấp lại: Khi gửi thông báo qua FCM HTTP v1 API, 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 (gọi là "Token Bucket") sẽ được nạp đầy vào cuối khung thời gian. Ví dụ: HTTP v1 API phân bổ 600.000 Mã thông báo hạn mức cho mỗi Nhóm mã thông báo 1 phút, nhóm này sẽ được nạp đầy vào cuối mỗi khoảng thời gian 1 phút.
Điều tiết phía máy chủ: Khi lưu lượng truy cập vượt quá khả năng của dịch vụ FCM, các yêu cầu vượt quá khả năng phân phát sẽ bị từ chối để giới hạn tốc độ dòng dữ liệu đầu vào. Các phản hồi lỗi 429 có tiêu đề retry-after có thể được trả về để 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 thấy các yêu cầu không thành công, độ trễ cao hoặc lỗi 429, máy khách nên tự nguyện giới hạn tốc độ luồng dữ liệu đầu ra để tránh làm trầm trọng thêm tình trạng tắc nghẽn.
Thuật toán thời gian đợi luỹ thừa: Khi thử lại các 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, v.v.
Giảm độ trễ: Tránh thử lại các yêu cầu ở khoảng thời gian chính xác. Với phương pháp làm trễ ngẫu nhiên, bạn sẽ thay đổi độ trễ khi thử lại thông qua một quy trình ngẫu nhiên để phân phối đồng đều 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).
Khuếch đại số lần thử lại: Khi các yêu cầu không thành công được thử lại mà không có độ trễ tăng theo cấp luỹ thừa/dao động, chúng thường tích luỹ và làm tăng tải lưu lượng truy cập đang diễn ra, có khả năng "khuếch đại" và làm trầm trọng thêm các vấn đề về 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). Yếu tố đóng góp lớn nhất vào tình trạng tắc nghẽn hệ thống, các vấn đề về độ trễ và sự cố ngừng hoạt động là lưu lượng truy cập tăng đột biến.
Lưu lượng truy cập đột biến là gì?
Có một số loại biến động lưu lượng truy cập.
Lượng truy cập tăng đột biến vào đầu mỗi giờ: FCM nhận được lượng truy cập gấp hơn 2 lần 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, nhưng chúng tôi cũng nhận thấy các mức tăng đột biến tại các mốc nửa giờ và 15 phút (ví dụ: 00:15, 00:30, 00:45)
Thử lại khuếch đạ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ó Thuật toán tăng tốc luỹ thừa có thể tích luỹ thành các đợt 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 chuyển hướng lưu lượng truy cập mới đến FCM hoặc chuyển lưu lượng truy cập sang FCM ở nhiều khu vực mà không có các yếu tố làm mượt như tăng dần có thể gây ra các đợt tăng đột biến.
Sử dụng hết mã thông báo hạn mức ngay từ đầu: Việc sử dụng hết tất cả mã thông báo hạn mức ngay từ đầu khoảng thời gian hạn mức thay vì phân bổ đều các yêu cầu trong khoảng thời gian hạn mức sẽ tạo ra các dao động bật/tắt khó cân bằng tải và tốn kém.
Sự kiện đặc biệt: Lưu lượng truy cập tăng đột biến 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 của 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 "giảm tốc độ tăng trưởng"
Phần này mô tả các chiến lược để giảm thiểu các đợt tăng đột biến lưu lượng truy cập nếu có thể – các chiến lược để "giảm đường cong".
Chỉ sử dụng FCM cho các trường hợp sử dụng phù hợp
Có một số trường hợp sử dụng mà bạn không cần hoặc không nên dùng FCM để gửi thông báo.
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 tác vụ cục bộ trong ứng dụng để hiển thị thông báo vào 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 số lượng tin nhắn FCM được gửi để đồng bộ hoá lịch.
Tránh tăng đột biến
Một mẫu chống mở rộng quy mô là gửi thông báo FCM nhanh nhất có thể thay vì áp dụng tính năng điều tiết phía máy chủ. Hãy cân nhắc những điều sau:
- Có phải tất cả khách hàng của bạn đều cần nhận được cùng một thông báo trong vòng 1 phút không? Ví dụ: khoảng thời gian giao hàng 5 phút có đáp ứng được 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 các đợt tăng đột biến không?
- Bạn có thể lên lịch gửi thông báo trước không?
Bất cứ khi nào có thể: tránh những chiến lược dẫn đến việc sử dụng hết hạn mức gửi FCM ngay lập tức, chỉ để lặp lại mẫu này ngay khi nhóm mã thông báo của bạn được nạp lại. Mẫu truy cập này gây ra 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 dần dần 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 cửa sổ dài hơn để có RPS cao hơn.
Tránh giao thông "vào mỗi giờ"
Nếu có thể: tránh gửi tin nhắn trong vòng 2 phút kể từ các mốc :00, :15, :30 và :45.
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ủ để giám sát và quản lý lưu lượng truy cập đến FCM.
Xử lý các lần thử lại
Mặc dù FCM luôn cố gắng duy trì tính sẵn sà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 sau đây sẽ tối ưu hoá hành vi thử lại để gửi thông báo sớm nhất có thể trong khi giảm thiểu tác động đến tình trạng tắc nghẽn lưu lượng truy cập.
Hết thời gian chờ
Đặt thời gian chờ tối thiểu là 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 thủ tục từ xa nội bộ của FCM đều sử dụng thời gian chờ là 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 không có tiêu đề retry-after, hãy đặt giá trị mặc định là 60 giây.
- Đối với lỗi 500: thử lại với thời gian đợi luỹ thừa.
Thuật toán thời gian đợi luỹ thừa
Để tránh tình trạng khuếch đại số lần thử lại, hãy triển khai thuật toán thời gian đợi luỹ thừa có thêm độ trễ ngẫu nhiên để thử lại các yêu cầu. Ví dụ: Firebase Admin SDK triển khai cơ chế tăng thời gian chờ luỹ thừa.
Sau đây là một số chế độ cài đặt khác nên dùng:
- Khoảng thời gian tối thiểu: Đừ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 rồi thử lại 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 với thời gian đợi tăng theo cấp luỹ thừa và vẫn không thành công sau 60 phút, thì yêu cầu đó có thể bị phân loại sai là lỗi có thể thử lại hoặc FCM đang gặp sự cố khiến các lần 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 triển khai 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 lớn về lưu lượng truy cập (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/khôi phục và triển khai các thay đổi dần dần sẽ bảo vệ người dùng, dịch vụ của bạn và FCM.
- Kế hoạch triển khai giúp các bên liên quan có chung kỳ vọng. Trong một số trường hợp (được thảo luận bên dưới), bạn nên chia sẻ kế hoạch phát hành trước 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 bất ngờ và chuẩn bị cơ chế để nhanh chóng và an toàn khôi phục sau các lỗi không lường trước được.
- Việc thực hiện các thay đổi từng bước có 2 khía cạnh:
- Tăng dần theo từng bước: Các bước phải là 1% -> 5% -> 10% -> 25% -> 50% -> 75% -> 100% hoặc chi tiết hơn. "Soak" (quan sát hành vi của hệ thống khi tải) mỗi bước 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 "bước lên" 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 phân bổ lưu lượng truy cập trong khoảng thời gian ít nhất là một giờ. Điều này cho phép cơ sở hạ tầng cân bằng tải của FCM điều chỉnh quy mô lưu lượng truy cập mới một cách thích hợp, đồng thời giảm thiểu khả năng xảy ra tình trạng quá tải và tắc nghẽn.
Sau đây là một kịch bản giả định về việc 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 số lượng |
|---|---|---|
| 0 | Tăng dần 1% | Tăng dần từ 0 lê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 vòng 2 giờ. |
| 2 | Tăng dần 10% | Tăng dần từ 25.000 lên 50.000 RPS trong vòng 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 dần 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ễ ở phân vị thứ 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 khôi phục về các bước trước đó cho đến khi độ trễ và tỷ lệ lỗi trở lại mức bình thường.
Thời điểm liên hệ với FCM
Liên hệ với FCM thông qua Nhóm hỗ trợ của Firebase nếu bạn gặp phải bất kỳ trường hợp nào sau đây:
- 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ẫu gửi 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.