Cho dù bạn đang phát triển một ứng dụng mới ra đờ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ừ những hiểu biết sâu sắc 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ẻ với FCM. Những khái niệm và thực tiễn này có thể giúp bạn tránh được những tác động tiêu cực khi bạn cần gửi số lượng lớn tin nhắn.
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 số liệu để mô tả tốc độ yêu cầu gửi đế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 ngạch, Nhóm mã thông báo và Nạp lại : Khi gửi tin nhắn dựa trên API FCM HTTP v1, mỗi yêu cầu sẽ sử dụng Mã thông báo hạn ngạch được phân bổ trong một khoảng thời gian nhất định. Cửa sổ này, được gọi là " Thùng mã thông báo ", sẽ được nạp đầy vào cuối cửa sổ thời gian. Ví dụ: API HTTP v1 phân bổ 600K mã thông báo hạn ngạch cho mỗi nhóm mã thông báo 1 phút, sẽ đầ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á khả năng của dịch vụ FCM, các yêu cầu vượt quá khả năng phục vụ sẽ bị từ chối đối với luồng vào giới hạn tốc độ. Phản hồi lỗi 429 với 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 khách hàng nhận thấy yêu cầu không thành công, độ trễ cao hoặc lỗi 429 , họ nên tự nguyện 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.
Độ trễ theo cấp số nhân : Khi thử lại lỗi, hãy cộng thêm độ trễ thời gian theo cấp số nhân. Ví dụ: 1s, 2s, 4s, 8s, 16s, 32s.
Jittering : Tránh thử lại các yêu cầu ở những khoảng thời gian chính xác. Với jittering, 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 đồ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 thử lại : Khi các yêu cầu không thành công được thử lại mà không có hiện tượng giật/nghẽn theo cấp số nhân, chúng thường tích lũy và tăng thêm 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 đề 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). Nguyên nhân lớn nhất gây ra tắc nghẽn hệ thống, các vấn đề về độ trễ và 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ăng đột biến là gì?
Có một số loại tăng đột biến lưu lượng truy cập khác nhau.
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 giây đến 2 phút đầu tiên 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 thấy ở các mốc nửa giờ và một phần tư giờ (ví dụ: 00:15, 00:30, 00:45)
Khuếch đại 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 chờ theo cấp số nhân có thể tích lũy thành các đợt lưu lượng truy cập lặp lại trên đỉnh lưu lượng truy cập hiện có.
Thay đổi mô hình lưu lượng truy cập đột ngột: 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 khắp 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 đột biến.
Việc sử dụng mã thông báo hạn ngạch tải trước: Việc sử dụng hết tất cả mã thông báo hạn ngạch khi bắt đầu khoảng thời gian hạn ngạch thay vì trải đều các yêu cầu trên các khoảng thời gian hạn ngạch sẽ tạo ra các dao động bật tắt gây khó khăn và tốn kém cho việc cân bằng tải.
Các 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 cá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 nhằm giảm bớt sự gia tăng lưu lượng truy cập khi có thể—các chiến lược để "làm phẳng đườ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à 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 tác vụ cục bộ trong ứng dụng của mình để 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 tin nhắn FCM ở mức đồng bộ hóa lịch.
Tránh gai
Một mô hình chống mở rộng quy mô là gửi thông báo FCM nhanh nhất mà hệ thống cho phép, thay vì áp dụng điều tiết phía máy chủ. Hãy xem xét những điều sau:
- Tất cả khách hàng của bạn có cần nhận được cùng một thông báo trong vòng 1 phút không? Chẳng hạn, thời hạn giao hàng 5 phút có còn đáp ứng nhu cầu kinh doanh của bạn không?
- Khách hàng của bạn có thể được phân khúc dựa trên mức độ ưu tiên để vượt qua các đợt tăng đột biến không?
- Thông báo của bạn có thể được lên lịch trước thời hạn không?
Bất cứ khi nào có thể : tránh các chiến lược dẫn đến cạn kiệt ngay hạn ngạch gửi FCM của bạn, chỉ lặp lại mẫu này ngay khi thùng mã thông báo của bạn được nạp đầy. 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 cường lưu lượng truy cập càng dần càng tốt. Tối thiểu, tăng từ 0 lên RPS tối đa trong khoảng thời gian 60 giây. Thích các cửa sổ dài hơn để có RPS cao hơn.
Tránh giao thông "đúng giờ"
Nếu có thể : tránh gửi tin nhắn trong khoảng thời gian 2 phút cho mỗi mốc :00, :15, :30 và :45 phút.
Triển khai điều chỉnh phía máy chủ
Triển khai đ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 đến FCM.
Xử lý lần thử lại
Mặc dù FCM cố gắng đạt được 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 khác nhau nhưng các phương pháp hay nhất sau đây sẽ tối ưu hóa hành vi thử lại để gửi thông báo sớm nhất có thể, đồng thời giảm thiểu tác động đến tắc nghẽn giao thông.
Hết giờ
Đặt thời gian chờ ít nhất 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 Cuộc gọi thủ tục 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: hủy bỏ và không thử lại.
- Đối với lỗi 429: thử lại sau khi đợi khoảng thời gian được đặt trong tiêu đề thử lại sau. Nếu không đặt tiêu đề thử lại sau, mặc định là 60 giây.
- Đối với 500 lỗi: thử lại với thời gian chờ theo cấp số nhân.
Sự lùi lại theo cấp số nhân
Để tránh khuếch đại thử lại, hãy triển khai tính năng dự phòng theo cấp số nhân với hiện tượng rung lắc cho các yêu cầu thử lại. Ví dụ: SDK quản trị Firebase triển khai tính năng dự phòng theo cấp số nhân.
Dưới đây là một số cài đặt được đề xuất thêm:
- 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 với FCM. Đợi ít nhất 10 giây trước khi 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 được thử lại liên tục với thời gian chờ theo cấp số nhân 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 thành lỗi có thể thử lại hoặc FCM đang gặp phải tình trạng ngừng hoạt động trong đó việc thử lại có thể vô tình làm tình hình trở nên trầm trọng hơn.
Tạo kế hoạch triển khai và khôi phục cũng như 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 lên FCM hoặc chuyển lưu lượng truy cập giữa các vùng hoặc mạng, việc thiết kế kế hoạch triển khai/hủy bỏ 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 sẽ điều chỉnh 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 có thể muốn chia sẻ trước kế hoạch triển khai của mình 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ế để phục hồi nhanh chóng và an toàn sau những lỗi không lường trước được.
- Thực hiện những thay đổi dần dần có hai khía cạnh:
- Tăng tốc "theo 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 hoạt động 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 cho phép bạn phát hiện các vấn đề tiềm ẩn trước khi "tăng cường" tiếp theo
- Tăng dần lưu lượng giao thông: Khi thực hiện từng "bước" để tăng lưu lượng giao thông, hãy điều chỉnh lưu lượng giao thô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 của bạn một cách thích hợp đồng thời giảm thiểu khả năng xảy ra các điểm nóng và tắc nghẽn.
Đây là một kịch bản giả định để di chuyển 500.000 RPS trên toàn cầu từ API FCM Legacy HTTP sang API FCM HTTP v1:
| Tuần | Bước chân | Chiến lược tăng dần dần |
|---|---|---|
| 0 | tăng tốc 1% | Tăng tốc mượt mà từ 0 lên 5.000 RPS lên FCM HTTP v1 trong vòng một giờ. |
| 1 | tăng tốc 5% | Tăng tốc mượt mà từ 5.000 lên 25.000 RPS trong 2 giờ. |
| 2 | tăng tốc 10% | Tăng tốc mượt mà từ 25.000 đến 50.000 RPS trong 2 giờ |
| 3 | tăng tốc 25% | Tăng tốc từ 50.000 lên 125.000 RPS trong 3 giờ |
| 4 | tăng tốc 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 trăm tăng lên 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 danh nghĩa.
Khi nào cần liên hệ với FCM
Liên hệ với FCM thông qua Hỗ trợ Firebase nếu áp dụng bất kỳ điều nào sau đây:
- Hạn ngạch 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 cách gửi của mình 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 toàn lục địa.