Bir uygulama, bir müşteri mesajını kaydeder ve ardından bir işleyici için bir olay yayınlar. Bu işlemler arasında uygulama çökerse, mesaj mevcut olur ancak işleyici bundan haberdar olmaz. Sırayı tersine çevirmek ise farklı bir sorun yaratır: veritabanındaki değişiklik henüz gerçekleşmemişken olay mevcut olabilir.
İşlem gönderim kutusu, iş değişikliğini ve giden olayı aynı veritabanı işleminde depolayarak bu çift yazma açığını giderir. Bu, değerli bir güvence olmakla birlikte, iş akışının tamamının tam olarak bir kez yürütülmesini sağlamaz.
İlk garantiyi net bir şekilde belirtin
İşlem onaylanırsa, hem etki alanı kaydı hem de giden kutusu kaydı mevcut olur. İşlem geri alınırsa, ikisi de mevcut olmamalıdır. Ayrı bir aktarıcı, giden kutusunu okur ve olayları aracıya iletir.
Şu AWS’nin bu modele ilişkin açıklaması Bu bölümde, işlem sınırı ve yinelenen mesajların işlenmesi gerekliliği ele alınmaktadır. Bir aktarım uygulamasını seçmeden önce bu garantileri belirtmenin yararlı olduğunu düşünüyorum.
Bir giden kutusu kaydı, sabit bir olay kimliği, kiracı bağlamı, olay türü, şema sürümü ve tüketiciler tarafından ihtiyaç duyulan etki alanı referansını içermelidir. Tam bir anlık görüntünün mü yoksa bir referansın mı ekleneceği, olayın amacına ve tutarlılık gereksinimlerine bağlıdır.
Rölede hâlâ bir arıza penceresi bulunuyor
Diyelim ki bir aktarıcı bir olayı başarıyla yayınladıktan sonra, gönderilecekler satırını “gönderildi” olarak işaretlemeden önce çöktü. Bir sonraki aktarım denemesinde bu olay yeniden yayınlanabilir. Yayınlanmadan önce “gönderildi” olarak işaretlemek ise, olayın kaybolma riskini doğurur.
Bu nedenle, tüketicinin yinelenen verileri alabileceğini varsayıyorum. Birden fazla aktarım işçisi olması durumunda, bir işçinin devre dışı kalması durumunda sistemin toparlanmasını sağlarken, kontrolsüz rekabeti önleyen bir talep stratejisi de gereklidir.
Yayınlama durumu, yapılan denemeleri, bir sonraki uygun yeniden deneme zamanını ve son geçerli hata mesajını içermelidir. Sürekli büyüyen bir gönderilecekler kutusu, sadece veritabanı eklemeleri kabul ettiği için sağlıklı bir kuyruk değil, araştırılması gereken bir birikimdir.
Tüketicileri iş sınırında idempotent hale getirin
Yerel veritabanı işlemleri gerçekleştiren bir tüketici için, işlenen olay kimliğini kaydedebilir ve işlemi tek bir işlem içinde uygulayabilirim. Benzersizlik kısıtlaması, iki eşzamanlı teslimatın aynı işlemi iki kez uygulamasını engeller.
Dış etkiler daha zordur. Tüketici bir e-posta gönderirse veya bir ödeme işlemi gerçekleştirirse, veritabanındaki bu işlem uzak hizmeti içeremez. Bu işlem için, belirsiz sonuçlara yönelik bir sağlayıcı idempotans anahtarı, kalıcı bir işlem kaydı veya mutabakat yolu gereklidir.
Aracı teslimat ayarları bu uygulama sınırını ortadan kaldırmaz. Bir JetStream alıcısında, uygulamanın işi güvenli bir şekilde tamamlanmış sayabileceği durumlarda, onay ve yeniden teslimat davranışları birbiriyle uyumlu olmalıdır. NATS kullanıcı kılavuzları Bu, devreye alınmış yapılandırma için söz konusu işleyişleri doğrulamak için uygun yerdir.
Etki alanının hangi sıralamaya ihtiyacı olduğuna karar verin
Genel sıralama genellikle maliyetli ve gereksizdir. Bir konuşmanın kendine özgü bir sıralaması olabilirken, bununla ilgisi olmayan konuşmalar bağımsız olarak ilerleyebilir. İşçilerin işlerini bitirme sırasına güvenmek yerine, bu alan gerekliliğini ifade etmeyi tercih ederim.
Tüketiciler, boşlukları ve güncel olmayan olayları tespit etmek için toplu bir sürümü veya diziyi kullanabilirler. Ardından, kurtarma politikası beklemek, yetkili durumu yeniden yüklemek veya bir tekrar talebinde bulunmak arasında bir karar verir.
Şema sürümleme de önemlidir. Bir dağıtım sırasında aracıda kalan bir mesaj, eski bir kod tarafından üretilmiş olabilir. Tüketicilerin, hâlâ teslim edilebilen sürümler için bir uyumluluk planına ihtiyacı vardır.
Tüm yolu çalıştır
En eski yayınlanmamış olayın süresini, yayınlama hatalarını, tüketici gecikmelerini, tekrarlanan teslimatları ve başarısız mesaj hacmini takip ediyorum. Bu ölçümler farklı hata noktalarını ortaya koyar ve tek bir kuyruk sayısına indirgenmemelidir.
Hata testlerim, yayınlamadan sonra röleyi durdurur, yan etkisi tamamlandıktan sonra tüketiciyi durdurur ve kaydedilmiş bir olayı tekrar oynatır. Her test, sistemin amaçlanan işlevini kaybetmeden veya etkisini katlamadan toparlanıp toparlanamadığını kontrol eder.
Giden kutusu, uygulamaya yayınlama konusunda kalıcı bir taahhüt sunar. Ancak tüketiciler ve sonraki aşamadaki entegrasyonlar, bu taahhüdü işlevsel hale getirmek zorundadır.
25 Eylül 2026 tarihinde güncellenmiştir.