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önderme 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ım sunucusu, giden kutusunu okur ve olayları aracı sunucuya yayınlar.
AWS’nin bu desene ilişkin açıklamasında, bu işlem sınırı ve yinelenen mesajların işlenmesi gerekliliği ele alınmaktadır. Bir aktarma uygulaması seçmeden önce bu garantilerin belirtilmesinin 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 bulunmaktadır
Diyelim ki, 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 beraberinde getirir.
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 kurtarma işlemini mümkün kı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, yalnızca veritabanı ekleme işlemlerini kabul ediyor diye sağlıklı bir kuyruk değil, araştırılması gereken bir iş birikimidir.
Tüketicileri iş sınırında idempotent hale getirin
Yerel veritabanı işlemlerini 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ı işlemin 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 bir mutabakat yolu gereklidir.
Aracı teslimat ayarları bu uygulama sınırını ortadan kaldırmaz. Bir JetStream tüketicisinde, uygulamanın işi güvenli bir şekilde tamamlanmış sayabileceği durumlarda, onay ve yeniden teslimat davranışları birbiriyle uyumlu olmalıdır. Dağıtılmış yapılandırma için bu işleyişi doğrulamak üzere NATS tüketici belgelerine başvurulmalıdır.
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ıraya ihtiyacı olabilirken, bununla ilgisi olmayan konuşmalar bağımsız olarak ilerleyebilir. İşçilerin işlerini bitirme sırasına bağlı kalmak yerine, bu alan gereksinimini ifade etmeyi tercih ederim.
Tüketiciler, boşlukları ve güncel olmayan olayları tespit etmek için toplu bir sürümü veya diziyi kullanabilir. Ardından, kurtarma politikası beklemeyi, yetkili durumu yeniden yüklemeyi veya tekrar oynatmayı talep etmeyi belirler.
Ş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ın
En eski yayınlanmamış olayın süresini, yayınlama hatalarını, tüketici gecikmelerini, tekrarlanan teslimatları ve geçersiz 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ı yeniden oynatır. Her test, sistemin amaçlanan işlevi kaybetmeden veya etkisini katlamadan toparlanıp toparlanamayacağını kontrol eder.
Giden kutusu, uygulamaya yayınlama konusunda kalıcı bir taahhüt sunar. Tüketiciler ve sonraki aşamadaki entegrasyonlar ise bu taahhüdü işlevsel hale getirmek zorundadır.
25 Eylül 2026 tarihinde güncellenmiştir.