Cho dù bạn đ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 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ô suôn sẻ với FCM. Những khái niệm và phương pháp này có thể giúp bạn tránh được tiêu cực ảnh hưởng khi bạn 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 nhau với "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 luồng cuộc gọi đến gửi yêu cầu đến 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 theo FCM HTTP phiên bản 1 API, mỗi yêu cầu 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ổ. Cửa sổ này có tên là "Bộ chứa mã thông báo", refills thành đầ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 Bộ chứa mã thông báo 1 phút, sẽ 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á lưu lượng truy cập của dịch vụ FCM
hạn mức, các yêu cầu vượt quá khả năng phân phát bị từ chối đối với lưu lượng truy cập giới hạn số lượng yêu cầu
luồng. 429 phản hồi lỗi có tiêu đề retry-after có thể được trả về để cho biết
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 ứng dụng phát hiện thấy lỗi yêu cầu, độ trễ cao,
hoặc 429 lỗi, nên họ phải tự nguyện đặt luồng ra giới hạn số lượng yêu cầu để tránh trầm trọng hơn
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 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.
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. Có sự 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 chúng một cách đồ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 quá trình khuếch đại: Khi yêu cầu không thành công được thử lại mà không có luỹ thừa thời gian đợi/biến động, chúng thường tích luỹ và bổ sung vào tải lưu lượng truy cập liên tục, có khả năng "đang lan toả" và làm trầm trọng thêm các vấn đề tắc nghẽn giao thông.
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). Người đóng góp nhiều nhất cho tình trạng tắc nghẽn hệ thống, vấn đề về độ trễ và tình trạng ngừng dịch vụ là mức tăng đột biến 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 lưu lượng truy cập nhiều hơn gấp đôi trong 30 lần đầu tiên giây đế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 quan sát được ở mốc nửa giờ và 15 phút (ví dụ: 00:15, 00:30, 00:45)
Thử lại khuếch đại: 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 ở trên các điểm tối ưu hoá 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: 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 vào FCM trên khắp các khu vực mà không cần các yếu tố làm mượt như tăng dần số lượng có thể là nguyên nhân gây đột biến.
Sử dụng mã thông báo hạn mức tải trước: Xóa hết tất cả mã thông báo hạn mức ở đầu hạn mức thay vì chia đều các yêu cầu cho hạn mức. sẽ tạo ra các dao động bật-tắt gây 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 độ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 để giải quyết vấn đề tăng đột biến lưu lượng truy cập trong đó khả thi—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à bạn không thể sử dụng FCM để gửi thông báo cần thiết hoặc phù hợp.
Ví dụ: đối với các thông báo về sự kiện trên lịch, bạn có thể lên lịch cho một việc cần làm trên máy trong để ứng dụng của bạn hiện thông báo vào những thời điểm thích hợp thay vì gửi từ máy chủ ứng dụng của bạn. 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 mô hình mở rộng là gửi thông báo FCM nhanh nhất có thể 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. Quyền truy cập này tạo ra các vấn đề cân bằng tải cho FCM và các phần phụ thuộc của nó hệ thống. 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 dần 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 để đặt vị trí cao hơn RPS.
Tránh tình trạng "theo giờ" giao thông
Khi có thể: tránh gửi thư trong khoảng thời gian 2 phút của mỗi các mốc :00, :15, :30 và :45.
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 hết sức để cung cấp dịch vụ, 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ù lý do có nhiều khác nhau, nhưng các phương pháp hay nhất sau đây để tối ưu hoá 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 đối với tắc nghẽn giao thông.
Số lần bị tạm ngừng
Đặ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 đang 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 đã đặt trong lượt 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 thử khuếch đại lại, hãy triển khai luỹ thừa thuật toán chờ tạo ra sự dao động cho các yêu cầu thử lại. SDK dành cho quản trị viên của Firebase, đối với chẳng hạn như 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 được thử lại liên tục bằng thuật toán thời gian đợi luỹ thừa mà vẫn không thành công sau 60 phút thì lỗi đó được 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ụ, khiến việc thử lại có thể vô tình trở nên nghiêm trọng hơn tình huống.
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 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, thiết kế kế hoạch phát hành/hoàn nguyên và việc 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 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 (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 mọi tình huống 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 bước" tăng dần: Các bước phải là 1% -> 5% -> 10% -> 25% -> 50% -> 75% -> 100% hoặc cao hơn. "Ngâm (quan sát hành vi của hệ thống khi đang 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 từng "bước" để tăng lưu lượng, hãy làm mượt 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 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.
Đây là một kịch bản giả định để di chuyển 500.000 RPS ra toàn cầu từ API HTTP cũ 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 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
Liên hệ với FCM thông qua Nhóm hỗ trợ của Firebase nếu bất kỳ trường hợp nào sau đây xảy ra:
- 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 sẽ thay đổi thói quen gửi của mình trong khoảng thời gian 3 tháng tại theo thang đo 100.000 RPS trên toàn cầu hoặc 30.000 RPS tại lục địa.