Son Service Bus kuyruklara genel bakış
Azure Service Bus kuyrukları ve konu abonelikleri, bekleyen ileti kuyruğu (DLQ) olarak adlandırılan ikincil bir alt kuyruğa sahip olur. Bekleyen ileti kuyruğu açıkça oluşturulmalı ve ana varlığa göre silinemez veya yönetilemez.
Bu makalede, Service Bus' içinde ileti Service Bus. Tartışmanın büyük bir örneği, GitHub.'de yer alan Dead-Letter kuyrukları örneği tarafından GitHub.
Bekleyen ileti kuyruğu
Teslim olmayan ileti kuyruğun amacı, herhangi bir alıcıya teslim verilemeyecek veya işlenmeyecek iletileri tutmaktır. İletiler daha sonra DLQ'dan kaldırılabilir ve ince olabilir. Bir uygulama, operatörün yardımıyla sorunları düzeltebilir ve iletiyi yeniden gönderebilir, bir hata olduğunu günlüğe işebilir ve düzeltici eylem gerçekleştirebilir.
API ve protokol perspektifinden bakıldığında DLQ çoğunlukla diğer herhangi bir kuyruğa benzer, ancak iletiler yalnızca üst varlığın teslim olmayan harf işlemiyle gönderilebilirsiniz. Ayrıca yaşam süresi gözlemlenmez ve bir DLQ'dan ileti gönderebilirsiniz. Teslim olmayan ileti kuyruğu, peek-lock teslimi ve işlemsel işlemleri tam olarak destekler.
DLQ'nun otomatik olarak temizlenmesi yoktur. İletiler DLQ'dan açıkça alınana ve ileti geri alınıncaya kadar DLQ'da kalır.
DLQ ileti sayısı
Konu düzeyinde, ileti gönderme sırasındaki iletilerin sayısını almak mümkün değildir. Bunun nedeni, iletiler iç hataya neden olmadığı sürece Service Bus düzeyinde yer alamamalarıdır. Bunun yerine, bir gönderen bir konuya ileti gönderdiğinde, ileti konu başlığı için aboneliklere milisaniye içinde iletilmesine ve dolayısıyla artık konu düzeyinde kalmama neden olur. Bu nedenle, konu başlığı için abonelikle ilişkilendirilmiş DLQ'da iletileri görebilir. Aşağıdaki örnekte, Service Bus Explorer şu anda "test1" aboneliği için DLQ'da 62 ileti olduğunu gösterir.
Azure CLI komutunu kullanarak DLQ iletilerinin sayısını da alabilirsiniz: az servicebus topic subscription show .
İletileri DLQ'ya taşıma
İleti altyapısının içinde Service Bus DLQ'ya ileti göndermeye neden olan çeşitli etkinlikler vardır. Bir uygulama ayrıca iletileri açıkça DLQ'ya da taşıyabilirsiniz. Aşağıdaki iki özellik (ileti olmayan harf nedeni ve olmayan harf açıklaması) ileti olmayan iletilere eklenir. Uygulamalar, geçerli olmayan neden özelliği için kendi kodlarını tanımlayabilir, ancak sistem aşağıdaki değerleri ayarlar.
| Geri gelen harf nedeni | Geri gelen harf hata açıklaması |
|---|---|
| HeaderSizeExceeded | Bu akış için boyut kotası aşıldı. |
| TTLExpiredException | İletinin süresi doldu ve teslim edilmeyenler sırasına eklendi. Ayrıntılar için Yaşam süresi bölümüne bakın. |
| Oturum Kimliği null. | Oturumun etkin olduğu varlık, oturum tanımlayıcısı null olan bir iletiye izin vermiyor. |
| MaxTransferHopCountExceeded | Kuyruklar arasında iletme sırasında izin verilen en fazla atlama sayısı. Değer 4 olarak ayarlanır. |
| MaxDeliveryCountExceededExceptionMessage | İleti, en fazla teslim denemesi sonrasında tüketilemedi. Ayrıntılar için Maksimum teslim sayısı bölümüne bakın. |
En fazla teslim sayısı
Kuyruklar ve abonelikler için ileti teslim etmek için Service Bus sınırı vardır. Varsayılan değer 10'dur. Bir ileti göz atma kilidi altında teslim edilirken açıkça bırakıldı veya kilidin süresi dolduğunda ileti teslim sayısı artırılır. Teslim sayısı sınırı aşarsa ileti DLQ'ya taşınır. DLQ'daki iletinin geri gönderme nedeni şu şekilde ayarlanır: MaxDeliveryCountExceeded. Bu davranış devre dışı bırakılamaz, ancak maksimum teslim sayısını büyük bir sayıya ayarlayın.
Yaşam süresi
Kuyruklarda veya aboneliklerde süresi dolan iletilerin hepsi DLQ'ya taşınır. TTLExpiredException, büyük harfli neden kodu olarak ayarlanır.
Ertelenen iletiler de temizlenmez ve süresi dolsa da geri alınan ileti kuyruğuna taşınmaz. Bu davranış tasarım gereğidir.
Abonelik kurallarını işleme sırasında oluşan hatalar
Filtre değerlendirme özel durumlarında postayı geri göndermeyi etkinleştirirsanız, aboneliğin SQL kuralı yürütülürken oluşan hatalar, soruna neden olan iletiyle birlikte DLQ'da yakalanır. Bu seçeneği, tüm ileti türlerinin abonelerinin yer almay olduğu bir üretim ortamında kullanmayın.
Uygulama düzeyindeki postasız yazma
Uygulamalar, sistem tarafından sağlanan geri gönderme özelliklerine ek olarak, kabul edilemez iletileri açıkça reddetmek için DLQ kullanabilir. Herhangi bir tür sistem sorunu, yanlış biçimlendirilmiş yük içeren iletiler veya bazı ileti düzeyi güvenlik düzeni kullanılırken kimlik doğrulaması başarısız olan iletiler nedeniyle düzgün işlenemedi iletileri içerebilir.
ForwardTo veya SendVia senaryolarında ileti geri gönderme
İletiler, aşağıdaki koşullar altında aktarımda olmayan ileti kuyruğuna gönderilir:
- Bir ileti, birlikte zincirlenmiş dörtten fazla kuyruktan veya konudan geçer.
- Hedef kuyruk veya konu başlığı devre dışı bırakıldı veya silindi.
- Hedef kuyruk veya konu başlığı, maksimum varlık boyutunu aşıyor.
Bekleyen ileti kuyruğuna giden yol
Geçersiz harf kuyruğuna erişmek için aşağıdaki söz dizimlerini kullanabilirsiniz:
<queue path>/$deadletterqueue
<topic path>/Subscriptions/<subscription path>/$deadletterqueue
Sonraki adımlar
İleti süre sonu ayarında kullanım dışı olan iletileri yapılandırmanın farklı yolları hakkında bilgi edinmek için bkz. Kuyruk veya abonelik için kullanım dışı iletileri etkinleştirme.