Thử lại các chức năng không đồng bộ

Tài liệu này mô tả cách bạn có thể yêu cầu các hàm nền không đồng bộ (không phải HTTPS) thử lại khi bị lỗi.

Ngữ nghĩa của việc thử lại

Cloud Functions đảm bảo thực thi ít nhất một lần chức năng hướng sự kiện cho mỗi sự kiện do nguồn sự kiện phát ra. Theo mặc định, nếu lệnh gọi hàm kết thúc do có lỗi thì hàm đó sẽ không được gọi lại và sự kiện sẽ bị loại bỏ. Khi bạn bật tính năng thử lại trên một chức năng theo sự kiện, Cloud Functions sẽ thử lại lệnh gọi hàm không thành công cho đến khi nó hoàn tất thành công hoặc hết thời gian thử lại.

Đối với các chức năng thế hệ 2, khoảng thời gian thử lại này sẽ hết hạn sau 24 giờ. Đối với các chức năng thế hệ 1, nó sẽ hết hạn sau 7 ngày. Cloud Functions thử lại các hàm theo sự kiện mới được tạo bằng cách sử dụng chiến lược thời gian chờ theo cấp số nhân, với thời gian chờ tăng dần từ 10 đến 600 giây. Chính sách này được áp dụng cho các chức năng mới vào lần đầu tiên bạn triển khai chúng. Nó không được áp dụng trở về trước cho các chức năng hiện có được triển khai lần đầu trước khi những thay đổi được mô tả trong ghi chú phát hành này có hiệu lực, ngay cả khi bạn triển khai lại các chức năng.

Khi tính năng thử lại không được bật cho một chức năng (được coi là mặc định), thì chức năng đó luôn báo cáo rằng nó đã thực thi thành công và mã phản hồi 200 OK có thể xuất hiện trong nhật ký của nó. Điều này xảy ra ngay cả khi chức năng gặp lỗi. Để làm rõ khi chức năng của bạn gặp lỗi, hãy nhớ báo cáo lỗi một cách thích hợp.

Tại sao các chức năng hướng sự kiện không thể hoàn thành

Trong một số trường hợp hiếm hoi, một chức năng có thể thoát sớm do lỗi nội bộ và theo mặc định, chức năng này có thể được thử lại tự động hoặc không.

Thông thường hơn, một hàm theo hướng sự kiện có thể không hoàn thành thành công do có lỗi trong chính mã hàm. Những lý do điều này có thể xảy ra bao gồm:

  • Hàm này có lỗi và thời gian chạy sẽ đưa ra một ngoại lệ.
  • Hàm không thể đạt đến điểm cuối dịch vụ hoặc hết thời gian chờ khi cố gắng thực hiện điều đó.
  • Hàm cố tình đưa ra một ngoại lệ (ví dụ: khi một tham số không được xác thực).
  • Hàm Node.js trả về lời hứa bị từ chối hoặc chuyển giá trị khác null cho lệnh gọi lại.

Trong bất kỳ trường hợp nào ở trên, hàm sẽ dừng thực thi theo mặc định và sự kiện sẽ bị loại bỏ. Để thử lại chức năng khi xảy ra lỗi, bạn có thể thay đổi chính sách thử lại mặc định bằng cách đặt thuộc tính "thử lại khi thất bại" . Điều này khiến sự kiện phải được thử lại nhiều lần cho đến khi chức năng hoàn thành thành công hoặc hết thời gian chờ thử lại.

Bật hoặc tắt tính năng thử lại

Định cấu hình thử lại từ Bảng điều khiển GCP

Nếu bạn đang tạo một chức năng mới:

  1. Từ màn hình Tạo chức năng , chọn Thêm trình kích hoạt và chọn loại sự kiện để kích hoạt chức năng của bạn.
  2. Trong ngăn kích hoạt Eventarc , hãy chọn hộp kiểm Thử lại khi không thành công để bật thử lại.

Nếu bạn đang cập nhật một chức năng hiện có:

  1. Từ trang Tổng quan về chức năng đám mây , hãy nhấp vào tên của chức năng bạn đang cập nhật để mở màn hình Chi tiết chức năng , sau đó chọn Chỉnh sửa từ thanh menu để hiển thị ngăn kích hoạt HTTPS và Eventarc .
  2. Trong ngăn trình kích hoạt Eventarc , hãy nhấp vào biểu tượng chỉnh sửa để chỉnh sửa cài đặt trình kích hoạt của bạn.
  3. Trong ngăn kích hoạt Eventarc , hãy chọn hoặc bỏ chọn hộp kiểm Thử lại khi không thành công để bật hoặc tắt tính năng thử lại.

Định cấu hình thử lại từ mã chức năng của bạn

Với Cloud Functions cho Firebase, bạn có thể bật tính năng thử lại trong mã cho một hàm. Để thực hiện việc này cho một hàm nền, chẳng hạn như functions.foo.onBar(myHandler); , hãy sử dụng runWith và định cấu hình chính sách lỗi:

functions.runWith({failurePolicy: true}).foo.onBar(myHandler);

Việc đặt true như minh họa sẽ định cấu hình một chức năng để thử lại khi không thành công.

Thực hành tốt nhất

Phần này mô tả các phương pháp hay nhất để sử dụng số lần thử lại.

Sử dụng thử lại để xử lý các lỗi nhất thời

Vì hàm của bạn được thử lại liên tục cho đến khi thực thi thành công nên các lỗi cố định như lỗi phải được loại bỏ khỏi mã của bạn thông qua quá trình kiểm tra trước khi bật thử lại. Việc thử lại được sử dụng tốt nhất để xử lý các lỗi gián đoạn/tạm thời có khả năng giải quyết cao khi thử lại, chẳng hạn như điểm cuối dịch vụ không ổn định hoặc hết thời gian chờ.

Đặt điều kiện kết thúc để tránh vòng lặp thử lại vô hạn

Cách tốt nhất là bảo vệ hàm của bạn khỏi vòng lặp liên tục khi sử dụng thử lại. Bạn có thể thực hiện việc này bằng cách đưa vào điều kiện kết thúc được xác định rõ trước khi hàm bắt đầu xử lý. Lưu ý rằng kỹ thuật này chỉ hoạt động nếu hàm của bạn khởi động thành công và có thể đánh giá điều kiện cuối.

Một cách tiếp cận đơn giản nhưng hiệu quả là loại bỏ các sự kiện có dấu thời gian cũ hơn một thời điểm nhất định. Điều này giúp tránh việc thực thi quá mức khi lỗi dai dẳng hoặc tồn tại lâu hơn dự kiến.

Ví dụ: đoạn mã này loại bỏ tất cả các sự kiện cũ hơn 10 giây:

const eventAgeMs = Date.now() - Date.parse(event.timestamp);
const eventMaxAgeMs = 10000;
if (eventAgeMs > eventMaxAgeMs) {
  console.log(`Dropping event ${event} with age[ms]: ${eventAgeMs}`);
  callback();
  return;
}

Sử dụng tính năng catch với Lời hứa

Nếu chức năng của bạn đã bật thử lại thì mọi lỗi chưa được xử lý sẽ kích hoạt thử lại. Đảm bảo rằng mã của bạn nắm bắt được mọi lỗi mà lẽ ra không dẫn đến việc thử lại.

Đây là một ví dụ về những gì bạn nên làm:

return doFooAsync().catch((err) => {
    if (isFatal(err)) {
        console.error(`Fatal error ${err}`);
    }
    return Promise.reject(err);
});

Làm cho các hàm hướng sự kiện có thể thử lại trở thành bình thường

Các hàm hướng sự kiện có thể được thử lại phải là hàm bình thường. Dưới đây là một số hướng dẫn chung để làm cho một hàm như vậy trở nên bình thường:

  • Nhiều API bên ngoài (chẳng hạn như Stripe) cho phép bạn cung cấp khóa tạm thời làm tham số. Nếu đang sử dụng API như vậy, bạn nên sử dụng ID sự kiện làm khóa tạm thời.
  • Idempotency hoạt động tốt với việc phân phối ít nhất một lần, vì nó giúp bạn thử lại một cách an toàn. Vì vậy, cách thực hành chung tốt nhất để viết mã đáng tin cậy là kết hợp tính tạm thời với số lần thử lại.
  • Hãy chắc chắn rằng mã của bạn là bình thường trong nội bộ. Ví dụ:
    • Đảm bảo rằng đột biến có thể xảy ra nhiều lần mà không làm thay đổi kết quả.
    • Truy vấn trạng thái cơ sở dữ liệu trong một giao dịch trước khi thay đổi trạng thái.
    • Hãy chắc chắn rằng tất cả các tác dụng phụ đều bình thường.
  • Áp đặt kiểm tra giao dịch bên ngoài chức năng, độc lập với mã. Ví dụ: trạng thái tồn tại ở đâu đó ghi lại rằng ID sự kiện nhất định đã được xử lý.
  • Xử lý các lệnh gọi hàm trùng lặp ngoài băng tần. Ví dụ: có một quy trình dọn dẹp riêng để dọn dẹp sau các lệnh gọi hàm trùng lặp.

Định cấu hình chính sách thử lại

Tùy thuộc vào nhu cầu của Chức năng đám mây của bạn, bạn có thể muốn trực tiếp định cấu hình chính sách thử lại. Điều này sẽ cho phép bạn thiết lập bất kỳ sự kết hợp nào sau đây:

  • Rút ngắn thời gian thử lại từ 7 ngày xuống chỉ còn 10 phút.
  • Thay đổi thời gian chờ tối thiểu và tối đa cho chiến lược thử lại thời gian chờ theo cấp số nhân.
  • Thay đổi chiến lược thử lại thành thử lại ngay lập tức.
  • Định cấu hình chủ đề thư chết .
  • Đặt số lần thử phân phối tối đa và tối thiểu.

Để định cấu hình chính sách thử lại:

  1. Viết hàm HTTP.
  2. Sử dụng API Pub/Sub để tạo đăng ký Pub/Sub, chỉ định URL của hàm làm mục tiêu.

Xem tài liệu Pub/Sub về xử lý lỗi để biết thêm thông tin về cách định cấu hình trực tiếp Pub/Sub.