AiHummer
Azərbaycanca
Daxil ol
v1.0.x
{ }Swagger

Çatdırılma, outbox və bərpa

v1.0.x · yeniləndi 2026-06-26

Bir dövr bitdikdə, cavab hələ də gəldiyi kanala çatmalıdır — etibarlı şəkildə və dəqiq bir dəfə. AiHummer bunu tranzaksiyalı outbox, idempotent yan-effektlər və yenidən başlatma sonrası dövr bərpası ilə həll edir. Daha böyük tətbiqlər üçün opsional NATS şini çatdırılmanı daşıya bilər.

Zəmanətli çatdırılma

Cavab dövrün sonunda birbaşa (inline) göndərilmir. Bunun əvəzinə o, onu istehsal edən işin bir hissəsi kimi outbox-a növbəyə salınır və çatdırılma işçisi onu götürüb ilkin gəldiyi kanala göndərir. Cavab tərk etməzdən əvvəl davamlı şəkildə qeyd olunduğundan, “cavab istehsal edildi” və “cavab göndərildi” arasında baş verən qəza onu itirə bilməz — yenidən başlatma zamanı outbox qeydi hələ də oradadır və çatdırılma bərpa olunur.

turn produces reply
   └─▶ enqueue in outbox (durable)
         └─▶ delivery worker ─▶ originating channel
               └─ acknowledged ─▶ marked delivered

Çatdırılma idempotentliklə birləşdirilib ki, bu ən-azı-bir-dəfə işçisi dəqiq-bir-dəfə xarici davranış versin: bərpaya-davamlı uçot açarı və yan-effekt baryeri təkrar çatdırılmış və ya yenidən oxunmuş cavabın kanala yalnız bir dəfə göndərilməsini təmin edir (bax: Çoxkirayəçilik və idempotentlik).

[!NOTE] Buradakı “dəqiq-bir-dəfə” xaricən görünən nəticəni təsvir edir: istifadəçi cavabı bir dəfə alır. Daxili olaraq işçi çatdırmağı bir dəfədən çox cəhd edə bilər; idempotentlik təbəqəsi bu cəhdləri tək görünən göndərməyə yığır.

Yenidən başlatma sonrası dövr bərpası

Əgər gateway dövr ortasında yenidən başlasa — deploy, qəza, hostun yenidən başlaması — iş tərk edilmir. Dövr bərpası yarımçıq qalan dövrü yenidən oxuyaraq onun tamamlanmasına imkan verir. Bu yalnız ona görə təhlükəsizdir ki, yan-effektlər idempotentdir: yenidən başlatmadan əvvəl artıq baş vermiş hər hansı poçt və ya kanal-göndərmə öz uçot açarı ilə tanınır və keçilir, baş verməyən hissələr isə sona qədər icra olunur. İstifadəçi yarımçıq və ya təkrarlanmış cavab əvəzinə tək, tam bir cavab görür.

Opsional NATS şini

Standart olaraq çatdırılma tamamilə PostgreSQL vasitəsilə işləyir ki, bu da minimal tətbiqi bir gateway plus verilənlər bazasında saxlayır. Daha böyük və ya çox-gateway-li tətbiqlər üçün URL-i konfiqurasiya edərək çatdırılmanı NATS şininə qoya bilərsiniz:

# gateway.env
AIHUMMER_NATS_URL=nats://127.0.0.1:4222

Şin həqiqətən opsionaldır — AIHUMMER_NATS_URL-i təyin etməyin və outbox onsuz işləyir. Mövcud olduqda, NATS çatdırılma işinin axdığı nəqliyyat olur ki, bu da proksi arxasında üfüqi miqyaslanan gateway-lərə uyğun gəlir.

[!TIP] Sıfır-dayanma yeniləmələri reverse proksi arxasında iki və ya daha çox gateway işlədir. Planlaşdırıcı Postgres advisory lock vasitəsilə tək-lider qalır və idempotent çatdırılma əlavə gateway-lərin heç nəyi iki dəfə göndərmədən yükü bölüşməsinə imkan verir.

Nəyi izləməli

Çatdırılma etibarlılıq problemlərinin ilk olaraq üzə çıxdığı yerdir, ona görə də izlənməli şey budur. AiHummer telemetriyanı OTLP (AIHUMMER_OTEL_ENDPOINT) üzərindən ötürür və Grafana panellərini təqdim edir; toplamaq üçün heç bir Prometheus /metrics son nöqtəsi yoxdur.

  • Çatdırılma nəticələri — hər çatdırılma cəhdinin nəticəsi. Uğursuzluqların artan sürəti kanal və ya aşağı-axın probleminə işarə edir.
  • Outbox dərinliyi — neçə cavabın çatdırılmağı gözlədiyi. Davamlı artım çatdırılmanın geri qaldığını bildirir.
  • DLQ dərinliyi — təkrar cəhdlərini tükətmiş və ölü-məktub növbəsinə düşmüş qeydlər. İstənilən DLQ artımı araşdırılmağa layiqdir.

[!WARNING] Bunları dövr gecikməsi və xəta dərəcəsi ilə birlikdə izləyin. Artan outbox və ya DLQ dövrlərin özlərinin hələ də uğurlu olduğu hallarda belə aşağı-axın kanallarının deqradasiyaya uğradığının erkən xəbərdarlığıdır.

Növbəti hara