Örnek sorular
Azure Messaging EventingZorluk 1
Azure Service Bus queue ile Service Bus topic arasındaki temel yapısal fark nedir?
- aBir queue yalnızca metin mesajı tutabilir, topic yalnızca binary mesaj tutabilir
- bBir queue her mesajı tek bir consumer'a teslim eder, topic aynı mesajı birden fazla bağımsız subscription'a dağıtabilir✓
- cTopic yalnızca Premium katmanda mevcuttur, queue tüm katmanlarda mevcuttur
- dBir queue her mesajda session ID gerektirir ve bunu içermeyen her mesajı reddeder, topic ise hiçbir zaman session ID gerektirmez
Açıklama:Queue nokta-noktaya bir yapıdır — bir mesaj tek bir alıcı tarafından tüketilir. Topic bir yayınla/abone-ol katmanı ekler: topic'e bağlı her subscription, eşleşen her mesajın kendi kopyasını alır, bu da birden fazla bağımsız consumer'a dağıtım sağlar.
Azure Messaging EventingZorluk 1
Service Bus dead-letter queue'unun (DLQ) amacı nedir?
- aBaşarıyla işlenmiş her mesajın yedek kopyasını saklar
- bBaşarısız mesajları başarılı olana kadar sonsuza kadar otomatik olarak yeniden dener
- cTeslim edilemeyen veya başarıyla işlenemeyen mesajları tutar, böylece ayrıca incelenebilirler✓
- dYöneticilerin yalnızca yük ve performans testleri çalıştırmak için sağladığı ayrı bir Service Bus namespace'idir
Açıklama:DLQ, her queue ve subscription'a eklenen bir alt-kuyruktur; mesajlar süresi dolduğunda, maksimum teslim sayısını aştığında veya alıcı tarafından açıkça dead-letter edildiğinde buraya düşer — sorunlu mesajları ana akıştan ayırıp sonradan incelemeye imkân tanır.
Azure Messaging EventingZorluk 2
Service Bus'ta bir receiver ReceiveAndDelete yerine PeekLock modunu kullanıyor. Bu, mesaj teslimatında neyi değiştirir?
- aPeekLock mesajları tüm subscriber'lara aynı anda teslim eder, ReceiveAndDelete yalnızca birine
- bPeekLock mesajı kilitler ve açık bir tamamlama bekler.✓
- cPeekLock mesajı queue'dan asla kaldırmaz, bu yüzden sınırsız kez okunabilir
- dYalnızca ReceiveAndDelete dead-lettering'i destekler
Açıklama:PeekLock, mesajı bir kilit süresi boyunca diğer receiver'lardan gizler ve açık bir Complete çağrısı gerektirir; bu hiç gerçekleşmezse (çökme, işlenmemiş hata) kilit süresi dolar ve mesaj yeniden görünür olur — Service Bus'ı at-most-once değil at-least-once yapan tam olarak budur. ReceiveAndDelete mesajı alındığı anda hemen kaldırır, bu yüzden alımdan sonra bir çökme mesajı kaybeder.
Azure Messaging EventingZorluk 2
Service Bus session ne için kullanılır?
- aHerhangi bir mesajlaşma gerçekleşmeden önce bir client bağlantısını Service Bus namespace'inin kendisine karşı kimlik doğrulamak için
- bTek bir consumer instance'ının saniyede alabileceği mesaj sayısını sınırlamak için
- cİlgili mesajları (aynı SessionId'yi paylaşan) gruplamak, böylece tek bir receiver onları sırayla işler✓
- dGönderen ile alıcı arasında mesaj gövdelerini taşıma katmanında aktarım sırasında şifrelemek için
Açıklama:Session'lar mesajları bir SessionId ile etiketlemenizi sağlar; Service Bus, aynı SessionId'yi paylaşan tüm mesajların o session için aynı receiver tarafından FIFO sırasıyla işlendiğini garanti eder — bu, sıralı ve ilişkili mesaj işleme gerektiren iş akışları için (ör. müşteri başına sipariş olayları) gereklidir.
Azure Messaging EventingZorluk 1
Azure Event Grid, subscriber'ları bir olay hakkında bilgilendirmek için temelde hangi teslimat modelini kullanır?
- aPush modeli — Event Grid olayı subscriber'ın kayıtlı endpoint'ine aktif olarak teslim eder✓
- bPull modeli — subscriber'lar yeni olayları kontrol etmek için Event Grid'i sabit aralıklarla yoklamalıdır
- cBatch modeli — olaylar yalnızca günde bir kez tek bir toplu dosyada teslim edilir
- dHiçbir yeniden deneme veya teslimat garantisi olmayan yalnızca yayın modeli
Açıklama:Event Grid push tabanlıdır: bir olay gerçekleştiğinde, subscriber'ın endpoint'ini (webhook, Azure Function, Service Bus, Event Hubs vb.) doğrudan çağırır, subscriber'ın yeni olaylar için yoklama yapmasını gerektirmez.
Azure Messaging EventingZorluk 2
Event Grid custom topic nedir?
- aYalnızca Azure sistem servislerinin (Storage veya Resource Groups gibi) yayın yapabileceği önceden tanımlı bir topic
- bKendi uygulamanızın olayları için oluşturduğunuz, kendi kodunuzun özel olay verisi yayınladığı bir topic✓
- cBir subscription'daki her Azure kaynağının olaylarını otomatik olarak birleştiren bir topic
- dYalnızca Kafka-uyumlu streaming iş yükleri için kullanılan bir topic türü
Açıklama:Custom topic'ler, özellikle kendi uygulama/iş olaylarınız için oluşturduğunuz endpoint'lerdir — kodunuz olayları buraya yayınlar; bu, Azure servislerinin (Blob Storage, Resource Groups vb.) kendi yaşam döngüsü olayları için otomatik olarak sunduğu yerleşik endpoint'ler olan system topic'lerden farklıdır.