Bir cron işi birden fazla NestJS düğümünde nasıl koordine edilir?

Question

IT Interview Practice · Accepted Answer

Önce “cronjob yalnızca bir düğümde çalışsın” ifadesini tanımlayın. **Eşzamanlı çalışmayı önlemek ile tekrarlanan iş etkisini önlemek farklı gereksinimlerdir.** Ortak zamanlayıcı yürütmeyi koordine eder; işlemin kendisi çökme ve yeniden deneme sonrasında güvenli kalmalıdır.

Üç NestJS düğümüne dağıtılan günlük fatura işini düşünün. Zamanlanmış işin çalışmasını, fakat worker yeniden başladığında başka bir fatura üretmemesini istiyoruz.

## 1. Neden bütün düğümlerin işi başlattığını anlayın

Her uygulama örneği kendi cron callback'ini kaydeder. Zamanı geldiğinde her biri bağımsız başlayabilir:

```text
00:00 -> Node A -> invoice task
      -> Node B -> invoice task
      -> Node C -> invoice task
```

Yerel isRunning bayrağı yalnızca bir süreçte vardır. NestJS waitForCompletion, o örnekte çakışan callback'leri durdurabilir ancak diğer düğümleri koordine etmez. Üç düğüme aynı bayrağı eklemek yine üç ayrı karar bırakır. [NestJS zamanlama](https://docs.nestjs.com/techniques/task-scheduling).

Bu nedenle hangi işin var olduğuna ve kimin işleyebileceğine karar veren ortak bir yere ihtiyacımız vardır.

## 2. Koordinasyon modelini seçin

| Durum | Değerlendirilecek seçenek | Kalan sorumluluk |
| --- | --- | --- |
| Platform zaten zamanlanmış işler sunuyor | Zamanlamayı web örneklerinin dışında çalıştırın | Çakışma, kurtarma ve kaçırılan çalışmaları yapılandırın. |
| Ekip zaten BullMQ işletiyor | Ortak Job Scheduler ve özel kuyruk | Ortak eşzamanlılık ve güvenli yeniden denemeleri yapılandırın. |
| Mevcut görev uygulama düğümlerinde kalmalı | Ortak kilit veya lease | Sahipliği, süre dolumunu ve eski worker'ları doğru yönetin. |

Fatura örneğinde Redis ve BullMQ zaten varsa sabit scheduler ID kullanan ortak zamanlayıcı pratik bir adaydır. Web düğümü eklemek bağımsız zamanlamalar oluşturmasın diye zamanlamayı worker'lardan ayırın.

Desteklenen BullMQ sürümünde özel kuyruğun global concurrency değerini bire ayarlayın. Bu, worker'lar arasındaki aktif işleri sınırlar; her worker'da yerel concurrency değerinin bir olması hâlâ birkaç worker'ın farklı işleri çalıştırmasına izin verir. [Global concurrency](https://docs.bullmq.io/guide/queues/global-concurrency).

Dünün işi hâlâ çalışıyorsa ne yapılacağını belirleyin: beklemek, atlamak veya çalışmaları birleştirmek. Saat dilimini ve kesinti sonrası kaçırılan iş günlerinin tamamlanıp tamamlanmayacağını tanımlayın.

## 3. Yalnızca işi değil, faturayı koruyun

Worker'ın faturayı oluşturup işin tamamlandığını kaydetmeden çöktüğünü varsayalım. Kurtarma, fatura zaten var olmasına rağmen işi yeniden çalıştırabilir.

```text
[Create invoice] -> [Crash before completion]
                              |
                            [Retry]
                              |
                  [Same business key: reuse result]
```

Müşteri ve faturalama dönemi gibi sabit bir iş anahtarı kullanın. Yerel veritabanı işlemlerinde benzersizlik kısıtı ve transaction, fatura oluşturmayı tamamlanmış çalışma kaydıyla birleştirebilir. Yeniden deneme böylece başka fatura oluşturmak yerine mevcut sonucu bulur.

Harici sağlayıcıda destekleniyorsa idempotency key kullanın ve belirsiz sonuçları uzlaştırın. Kuyruk iş kimliği veya saklanan iş kaydı tek başına bir iş eyleminin tekrar edemeyeceğine dair kalıcı garanti değildir. [Idempotent işler](https://docs.bullmq.io/patterns/idempotent-jobs).

## 4. Kilidin neyi garanti edip edemediğini bilin

Ortak kilit atomik alınmalıdır. Sahiplik token'ı, süre sonu ve yenileme kullanın; yalnızca token hâlâ eşleşiyorsa serbest bırakın. Aksi halde eski worker, yeni worker'ın kilidini kaldırabilir.

Süre dolumu başka bir durum yaratır: duraklatılmış worker lease süresi bittikten sonra devam ederken yeni worker zaten çalışıyordur. Kritik yazmalar, hedefin eski worker'ları reddetmek için kontrol ettiği artan sahiplik numaraları olan fencing token'ları gerektirebilir. Uzun timeout belirlemek bu riski ortadan kaldırmaz.

Koordinasyon kullanılamıyorsa işin sahiplik olmadan çalışmak yerine bekleyip beklemeyeceğine karar verin. Önemli sonuçlar doğuran işlerde bu genellikle daha güvenlidir.

## 5. Hata senaryolarını doğrulayın

Birden fazla düğümü, fatura oluşturulduktan sonraki çökmeyi, lease süresinden uzun duraklamayı, Redis bağlantısının kaybını ve aşamalı dağıtımı test edin. Tekrarlanan denemeleri tekrarlanan etkilerden ayırmak için iş tarihini, worker'ı, denemeyi ve sonucu kaydedin.

**Unutmayın:** zamanlamayı koordine edin → ortak yürütmeyi sınırlayın → iş eylemini yeniden denemeye güvenli yapın → kurtarmayı test edin. “Bir aktif iş” tek başına tam olarak bir iş etkisinin kanıtı değildir.

Durum	Değerlendirilecek seçenek	Kalan sorumluluk
Platform zaten zamanlanmış işler sunuyor	Zamanlamayı web örneklerinin dışında çalıştırın	Çakışma, kurtarma ve kaçırılan çalışmaları yapılandırın.
Ekip zaten BullMQ işletiyor	Ortak Job Scheduler ve özel kuyruk	Ortak eşzamanlılık ve güvenli yeniden denemeleri yapılandırın.
Mevcut görev uygulama düğümlerinde kalmalı	Ortak kilit veya lease	Sahipliği, süre dolumunu ve eski worker'ları doğru yönetin.

1. Neden bütün düğümlerin işi başlattığını anlayın

2. Koordinasyon modelini seçin

3. Yalnızca işi değil, faturayı koruyun

4. Kilidin neyi garanti edip edemediğini bilin

5. Hata senaryolarını doğrulayın

İlgili sorular