Eşzamansız işlevleri yeniden deneme

Bu belgede, başarısızlık durumunda yeniden denenmesi için nasıl eşzamansız (HTTPS olmayan) arka plan işlevleri isteyebileceğiniz açıklanmaktadır.

Olay odaklı işlevlerin tamamlanamamasının nedenleri

Nadiren de olsa bir işlev, dahili bir hata nedeniyle erken çıkabilir ve varsayılan olarak işlev otomatik olarak yeniden denenmeyebilir.

Daha yaygın olarak, etkinliğe dayalı bir işlev, işlev kodunda oluşan hatalar nedeniyle başarıyla tamamlanamayabilir. Bunun olası nedenleri şunlardır:

• Fonksiyonda bir hata var ve çalışma zamanı bir istisna oluşturuyor.
• İşlev, bir hizmet uç noktasına ulaşamıyor veya bunu yapmaya çalışırken zaman aşımına uğruyor.
• İşlev, kasıtlı olarak bir istisna oluşturur (örneğin, bir parametre doğrulama başarısız olduğunda).
• Bir Node.js işlevi, reddedilen bir söz döndürüyor veya geri çağırmaya null olmayan bir değer iletiyor.

Yukarıdaki durumlarda işlevin yürütülmesi durdurulur ve hata döndürülür. İletileri oluşturan etkinlik tetikleyiciler, işlevinizin ihtiyaçlarını karşılayacak şekilde özelleştirebileceğiniz yeniden deneme politikalarına sahiptir.

Yeniden denemenin anlamı

Cloud Functions, bir etkinlik kaynağı tarafından yayınlanan her etkinlik için etkinliğe dayalı bir işlevin en az bir kez yürütülmesini sağlar. Yeniden denemeleri yapılandırma şekliniz, işlevinizi nasıl oluşturduğunuza bağlıdır:

• Google Cloud Console'da veya Cloud Run Admin API ile oluşturulan işlevler için etkinlik tetikleyicilerini ayrı olarak oluşturup yönetmeniz gerekir. Tetikleyicilerde, işlevinizin ihtiyaçlarına göre özelleştirebileceğiniz varsayılan yeniden deneme davranışları bulunur.
• Cloud Functions v2 API ile oluşturulan işlevler, gerekli etkinlik tetikleyicilerini (örneğin, Pub/Sub konuları veya Eventarc tetikleyicileri) örtülü olarak oluşturur. Yeniden denemeler varsayılan olarak bu tetikleyiciler için devre dışıdır ve Cloud Functions v2 API kullanılarak yeniden etkinleştirilebilir.

Cloud Run ile oluşturulan etkinliğe dayalı işlevler

Google Cloud Console'da veya Cloud Run Admin API ile oluşturulan işlevler için etkinlik tetikleyicilerini ayrı olarak oluşturup yönetmeniz gerekir. Her tetikleyici türünün varsayılan davranışını incelemenizi önemle tavsiye ederiz:

• Eventarc yeniden deneme politikasında, eksponansiyel geri yükleme gecikmesiyle birlikte varsayılan mesaj saklama süresi 24 saattir. Eventarc Yeniden deneme etkinlikleri ile ilgili dokümanları inceleyin.
• Pub/Sub, varsayılan olarak tüm aboneliklerde anında yeniden teslim politikasını kullanır. Pub/Sub dokümanlarındaki ileti hatalarını işleme ve istekleri yeniden deneme bölümlerini inceleyin.

Cloud Functions v2 API ile oluşturulan etkinliğe dayalı işlevler

Cloud Functions v2 API kullanılarak oluşturulan işlevler (ör. Cloud Functions gcloud CLI, REST API veya Terraform kullanılarak) sizin adınıza etkinlik tetikleyicileri oluşturur ve yönetir. Varsayılan olarak, bir işlev çağrısı hatayla sonlanırsa işlev tekrar çağrılmaz ve etkinlik bırakılır. Etkinliğe dayalı bir işlevde yeniden denemeleri etkinleştirdiğinizde, Cloud Functions başarısız olan işlev çağrısı başarıyla tamamlanana veya yeniden deneme penceresinin süresi dolana kadar yeniden denenir.

Varsayılan olarak bir işlev için yeniden denemeler etkinleştirilmediğinde işlev her zaman başarılı bir şekilde yürütüldüğünü bildirir ve günlüklerinde 200 OK yanıt kodları görünebilir. Bu durum, işlev bir hatayla karşılaşsa bile geçerlidir. İşleviniz bir hatayla karşılaştığında bunu net bir şekilde belirtmek için hataları uygun şekilde bildirdiğinizden emin olun.

Yeniden denemeleri etkinleştirme veya devre dışı bırakma

Yeniden denemeleri işlev kodunuzdan yapılandırma

Cloud Functions for Firebase ile bir işlev için kodda yeniden denemeleri etkinleştirebilirsiniz. functions.foo.onBar(myHandler); gibi bir arka plan işlevi için bunu yapmak üzere runWith kullanın ve bir hata politikası yapılandırın:

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

true ayarını gösterildiği gibi yapmak, başarısızlık durumunda yeniden deneyecek bir işlev yapılandırır.

Yeniden deneme aralığı

En iyi uygulamalar

Bu bölümde, yeniden denemeleri kullanmayla ilgili en iyi uygulamalar açıklanmaktadır.

Geçici hataları işlemek için yeniden denemeyi kullanma

İşleviniz başarılı bir şekilde yürütülene kadar sürekli olarak yeniden denendiğinden, yeniden denemeler etkinleştirilmeden önce test yoluyla kodunuzdaki hatalar gibi kalıcı hatalar giderilmelidir. Yeniden denemeler, aralıklı veya geçici hataları işlemek için en iyi yöntemdir. Bu hataların yeniden denendiğinde çözülme olasılığı yüksektir. Örneğin, güvenilmez bir hizmet uç noktası veya zaman aşımı.

Sonsuz yeniden deneme döngülerini önlemek için bir bitiş koşulu ayarlayın

Yeniden denemeleri kullanırken işlevinizi sürekli döngüye girmeye karşı korumak en iyi uygulamadır. Bu işlemi, işlev işlemeye başlamadan önce iyi tanımlanmış bir bitiş koşulu ekleyerek yapabilirsiniz. Bu tekniğin yalnızca işleviniz başarıyla başlatılırsa ve bitiş koşulunu değerlendirebilirse çalıştığını unutmayın.

Basit ancak etkili bir yaklaşım, belirli bir süreden eski zaman damgalarına sahip etkinlikleri silmektir. Bu, hatalar kalıcı olduğunda veya beklenenden daha uzun sürdüğünde aşırı yürütme işlemlerini önlemeye yardımcı olur.

Örneğin, bu kod snippet'i 10 saniyeden eski tüm etkinlikleri siler:

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;
}

catch'ı Promises ile kullanma

İşlevinizde yeniden denemeler etkinse işlenmeyen tüm hatalar yeniden denemeyi tetikler. Kodunuzun, yeniden denemeye yol açmaması gereken hataları yakaladığından emin olun.

Yapmanız gerekenlere dair bir örnek:

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

Yeniden denenebilir etkinlik odaklı işlevleri idempotent yapma

Yeniden denenebilen olay odaklı işlevler, idempotent olmalıdır. Bu tür bir işlevi idempotent yapmak için bazı genel yönergeleri aşağıda bulabilirsiniz:

• Birçok harici API (ör. Stripe), parametre olarak bir idempotentlik anahtarı sağlamanıza olanak tanır. Bu tür bir API kullanıyorsanız etkinlik kimliğini, idempotentlik anahtarı olarak kullanmanız gerekir.
• Yeniden deneme güvenli hale geldiğinden, idempotentlik en az bir kez teslimatla iyi çalışır. Bu nedenle, güvenilir kod yazmayla ilgili genel bir en iyi uygulama, yeniden denemelerle birlikte idempotentliği kullanmaktır.
• Kodunuzun dahili olarak idempotent olduğundan emin olun. Örneğin:
  • Mutasyonların sonucu değiştirmeden birden fazla kez gerçekleşebildiğinden emin olun.
  • Durumu değiştirmeden önce bir işlemdeki veritabanı durumunu sorgulayın.
  • Tüm yan etkilerin kendi içinde idempotent olduğundan emin olun.
• İşlevin dışında, koddan bağımsız bir işlem kontrolü uygulayın. Örneğin, belirli bir etkinlik kimliğinin zaten işlendiğini kaydeden bir durumu kalıcı hale getirin.
• Bant dışı yinelenen işlev çağrılarıyla ilgilenin. Örneğin, yinelenen işlev çağrılarından sonra temizlik yapan ayrı bir temizleme süreciniz olsun.

Yeniden deneme politikasını yapılandırma

İşlevinizin ihtiyaçlarına bağlı olarak yeniden deneme politikasını doğrudan yapılandırmak isteyebilirsiniz. Bu sayede, aşağıdakilerin herhangi bir kombinasyonunu ayarlayabilirsiniz:

• Yeniden deneme aralığını 7 günden 10 dakikaya kadar kısaltın.
• Üstel geri çekilme yeniden deneme stratejisi için minimum ve maksimum geri çekilme süresini değiştirin.
• Yeniden deneme stratejisini hemen yeniden denenecek şekilde değiştirin.
• Bir geçersiz konu yapılandırın.
• Maksimum ve minimum teslimat denemesi sayısı belirleyin.

Yeniden deneme politikasını yapılandırmak için:

1. Bir HTTP işlevi yazın.
2. Pub/Sub aboneliği oluşturmak için Pub/Sub API'yi kullanın ve işlevin URL'sini hedef olarak belirtin.

Pub/Sub'ı doğrudan yapılandırma hakkında daha fazla bilgi için Pub/Sub hataları işleme dokümanlarına bakın.