Cho dù đang phát triển một ứng dụng mới ra mắt 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à các đề xuất trong hướng dẫn này về cách mở rộng quy mô mượt mà bằng FCM. Các khái niệm và phương pháp này có thể giúp bạn tránh 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 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, bộ chứa mã thông báo và tính năng nạp lại hạn mức: Khi gửi thông báo qua API HTTP phiên bản 1 của FCM, 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à "Bộ chứa mã thông báo", nạp lại thành toàn bộ 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 Bộ chứa mã thông báo 1 phút. Bộ chứa mã thông báo này sẽ được nạp đầy vào cuối mỗi cửa sổ 1 phút.
Điều tiết 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á khả năng phân phát sẽ bị từ chối đối với luồng vào giới hạn số lượng yêu cầu. 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 quan sát thấy các 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 tốc độ luồng đầu ra để tránh làm trầm trọng thêm tình trạng tắc nghẽn.
Thời gian đợi luỹ thừa: Khi thử lại lỗi, hãy thêm độ trễ thời gian 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.
Giao diện nhấp nháy: Tránh thử lại các yêu cầu tại những 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).
Thử lại khuếch đại: Khi các yêu cầu không thành công được thử lại mà không có thời gian đợi luỹ thừa/độ trễ, 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 liên tục, 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 có hệ thống, các vấn đề về độ trễ và tình trạng ngừng dịch vụ là mức tăng đột biến về lưu lượng truy cập.
Giao thông tăng đột biến là gì?
Có một số loại tăng đột biến lưu lượng truy cập.
Tăng đột biến theo giờ: FCM nhận được hơn gấp đôi lưu lượng truy cập trong 30 giây đầu tiên đến 2 phút 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)
Thử khuếch đại 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 đợt lưu lượng truy cập lặp lại ở đầu các điểm tối ưu 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.
Việc 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 khi bắt đầu khoảng thời gian hạn mức thay vì chia đều các yêu cầu trên các khoảng thời gian hạn mức sẽ tạo ra các dao động khi tắt gây khó khăn và tốn kém cho việc cân bằng tải.
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 (FIFA World Cup).
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 để khắc phục mức tăng đột biến về lưu lượng truy cập nếu có thể — 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 để gử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 tin nhắn FCM để đồng bộ hoá lịch.
Tránh mốc 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:
- 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 khoảng thời gian 1 phút không? Ví dụ: nếu khung thời gian giao hàng là 5 phút thì vẫn có thể đáp ứng được nhu cầu kinh doanh của bạn.
- Khách hàng của bạn có thể được phân đoạn dựa trên mức độ ưu tiên để vượt qua mức tăng đột biến không?
- Bạn có thể lên lịch trước thông báo của mình không?
Bất cứ khi nào có thể: tránh các chiến lược làm cạn ngay hạn mức gửi FCM, chỉ để lặp lại mẫu ngay khi bộ chứa mã thông báo của bạn nạp lại. Mẫu truy cập này tạo ra các vấn đề cân bằng tải cho FCM và các hệ thống phụ thuộc của nó. Tăng lưu lượng truy cập dần dần hết mức có thể. Tối thiểu, hãy tăng tốc từ 0 đến RPS tối đa trong khoảng thời gian 60 giây. Ưu tiên cửa sổ dài hơn cho ROM cao hơn.
Tránh giao thông "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 chế độ điều tiết phía máy chủ
Triển khai biện pháp điều tiết phía máy chủ để giám sát và quản lý luồng lưu lượng truy cập vào FCM.
Xử lý các lần thử lại
Mặc dù FCM cố gắng đạt được mức độ 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ực hiện được. 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 để gửi thông báo càng sớm càng tốt, đồ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.
Số lần bị tạm ngừng
Hãy đặt thời gian chờ ít nhất là 10 giây đối với 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ỷ bỏ 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 đề thử lại sau. Nếu bạn không đặt tiêu đề thử lại sau khi đặt, thời lượng mặc định 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 khuếch đại thử lại, hãy triển khai thuật toán thời gian đợi luỹ thừa cùng với dao động cho các yêu cầu thử lại. Ví dụ: SDK quản trị của Firebase sẽ triển khai thuật toán 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. Hãy đợi í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 để 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 vào FCM hoặc thay đổi lưu lượng truy cập giữa các khu vực hoặc mạng, việc thiết kế một kế hoạch phát hành/hoàn nguyên và triển khai các thay đổi từng bước sẽ bảo vệ người dùng, dịch vụ của bạn và FCM.
- Kế hoạch ra mắt phù hợp với kỳ vọng của các bên liên quan. Trong một số trường hợp nhất định (được thảo luận bên dưới), bạn nên chia sẻ trước kế hoạch phát hành của mình với nhóm FCM để tránh 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 thực hiện cá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. "Soak" (quan sát hành vi của hệ thống khi có tải) mỗi bước trong 1 ngày đến 1 tuần. Nhờ đó, bạn có thể phát hiện các vấn đề tiềm ẩn trước khi thực hiện "bước chỉnh sửa" tiếp theo
- Tăng dần lưu lượng truy cập: Khi thực hiện mỗi "bước" để tăng lưu lượng, hãy cân bằng lưu lượng 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 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ũ FCM sang API HTTP phiên bản 1 của FCM:
| Tuần | Step | Chiến lược tăng dần từng bước |
|---|---|---|
| 0 | Tăng dần 1% | Tăng tốc mượt mà từ 0 đến 5.000 RPS sang FCM HTTP v1 trong vòng một giờ. |
| 1 | Tăng dần 5% | Tăng tốc trơn tru từ 5.000 đến 25.000 RPS trong 2 giờ. |
| 2 | Tăng dần 10% | Tăng tốc trơn tru từ 25.000 đến 50.000 RPS trong 2 giờ |
| 3 | Tăng dần 25% | Tăng tốc từ 50.000 lên 125.000 RPS trong 3 giờ |
| 4 | Tăng dần 50% | Tăng tốc từ 125.000 lên 250.000 RPS trong 6 giờ |
| 5 | Tăng tốc 75% | Tăng tốc từ 250.000 lên 375.000 RPS trong 6 giờ |
| 6 | Tăng tốc 100% | Tăng tốc từ 375.000 lên 500.000 RPS trong 6 giờ |
Kế hoạch khôi phục giả định:
- Nếu độ trễ 95 phân vị 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ở về mức danh nghĩa.
Khi nào nên liên hệ với FCM
Hãy liên hệ với FCM thông qua bộ phận Hỗ trợ của Firebase nếu thuộc 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ô 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.