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 gửi thông báo: Yêu cầu gửi thông báo FCM; được dùng thay thế cho "yêu cầu", "thông báo" 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 cá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, 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 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. 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.
Giới hạn tốc độ phía máy khách: Khi nhận thấy lỗi yêu cầu, độ 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 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 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 độ trễ, bạn thay đổi độ trễ thử lại thông qua một quy trình ngẫu nhiên để phân phối độ trễ một cách đồ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).
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ờ. Các đỉnh tương tự, mặc dù nhỏ hơn, cũng được quan sát thấy tại các 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 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 đến FCM trên các 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 sự gia tăng độ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 độ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 để 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 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ụ: 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?
- 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ể: 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 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 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 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 tính từ mỗi điểm đánh dấu :00, :15, :30 và :45 phút.
Triển khai chế độ đ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 để 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.
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ỷ 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 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.
Sau đây là một số chế độ cài đặt khác được đề xuất:
- 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 để 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 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ác cơ chế để nhanh chóng và an toàn khôi phục sau các sự cố không lường trướ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. "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. Đ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 phù hợp, đồng thời giảm thiểu khả năng xảy ra điểm phát só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 tốc mượt mà từ 0 đến 5.000 RPS sang FCM HTTP v1 trong khoảng thời gian 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 tốc trơn tru từ 25.000 đế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 dần 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ừ 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.
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ẫu gửi trong khoảng thời gian 3 tháng ở quy mô 100.000 RPS trên toàn cầu hoặc 30.000 RPS trên một lục địa.