Örnek sorular
Gcp Messaging EventingZorluk 1
Google Cloud Pub/Sub öncelikle ne için kullanılır?
- aStatik web sitelerini doğrudan son kullanıcılara sunmak için
- bEvent producer'ları consumer'lardan ayırmak için asenkron mesajlaşma✓
- cHiç mesajlaşma içermeyen zamanlanmış batch işleri çalıştırmak için
- dGörsel/video gibi büyük binary objeleri saklamak için
Açıklama:Pub/Sub yönetilen bir asenkron mesajlaşma servisidir: publisher'lar bir topic'e mesaj gönderir, subscriber'lar bunları bağımsız olarak alır, böylece producer ve consumer birbirinden bağımsız ölçeklenip hata verebilir. a ve d ilgisiz servisleri (statik hosting, obje depolama) anlatıyor, c ise zamanlamayı anlatıyor, mesajlaşmayı değil.
Gcp Messaging EventingZorluk 1
Standart bir Pub/Sub subscription'ı varsayılan olarak hangi teslimat garantisini sağlar?
- aExactly-once teslimat Pub/Sub'ın desteklediği tek moddur
- bHiçbir teslimat garantisi yoktur — mesajlar herhangi bir yeniden deneme veya yeniden teslim girişimi olmadan sessizce kaybolabilir
- cAt-least-once teslimat — bir mesaj yeniden teslim edilebilir ama kaybolmaz✓
- dAt-most-once teslimat — bir mesaj bir kez teslim edilir ya da hiç edilmez
Açıklama:Pub/Sub'ın varsayılan garantisi at-least-once'tur: bir mesaj onaylanana kadar erişilebilir kalır, network/timeout sorunları yeniden teslime yol açabilir ama mesaj sessizce kaybolmaz. Exactly-once ek kısıtlarla ayrıca etkinleştirilen bir özelliktir (a genel bir iddia olarak yanlış), Pub/Sub at-most-once ya da garantisiz mod sunmaz (b, d yanlış).
Gcp Messaging EventingZorluk 1
Pub/Sub'da push subscription ile pull subscription arasındaki temel fark nedir?
- aPush subscription'larda Pub/Sub mesajları HTTP üzerinden bir endpoint'e teslim eder; pull subscription'larda consumer mesajları almak için aktif olarak bir API çağırır✓
- bPush subscription'lar mesajları kalıcı olarak saklar; pull subscription'lar bir saat sonra siler
- cPull subscription'lar yalnızca Cloud Functions ile, push subscription'lar yalnızca Compute Engine ile çalışır
- dFonksiyonel bir fark yoktur, yalnızca konsoldaki bir adlandırma farkıdır
Açıklama:Push, mesajları geldiği anda yapılandırılmış bir HTTPS endpoint'ine teslim eder; pull'da subscriber mesajları kendi zamanlamasıyla almak için Pub/Sub API'sini çağırmak zorundadır. Retention davranışı (b) push/pull ile ilgisizdir, hiçbir mod belirli bir compute servisiyle sınırlı değildir (c yanlış).
Gcp Messaging EventingZorluk 2
Bir Pub/Sub mesajındaki ordering key ne garanti eder?
- aAynı ordering key'e sahip mesajlar, başka ordering key kullanan mesajlardan farklı olarak tam olarak bir kez teslim edilir
- bAynı ordering key'e sahip mesajlar otomatik olarak tek bir teslimatta gruplanır
- cAynı ordering key'e sahip mesajlar özel bir dead-letter topic'e yönlendirilir
- dAynı ordering key'e sahip mesajlar subscriber'lara yayınlandıkları sırayla teslim edilir✓
Açıklama:Ordering key'ler, o key'i paylaşan mesajlar için yayın sırasının korunmasını sağlar, bunun karşılığında o key içinde bir miktar throughput kaybı olur. Teslimat garantisini exactly-once'a çevirmez (a), mesajları gruplamaz (b), dead-letter yönlendirmesiyle ilgisi yoktur (c).
Gcp Messaging EventingZorluk 2
Bir Pub/Sub subscription'ında yapılandırılan dead-letter topic'in amacı nedir?
- aKota boşaltmak için işlenemeyen mesajları kalıcı olarak siler
- bYapılandırılan deneme sayısını aşan teslim hatalı mesajları alır, böylece ayrıca incelenebilirler✓
- cHatalı mesajları asla vazgeçmeden sonsuza kadar otomatik olarak yeniden dener
- dTeslimat başarısına bakmaksızın her mesajın bir yedek kopyasını saklar
Açıklama:Dead-letter topic, yapılandırılan maksimum teslim deneme sayısını aşan mesajları yakalar; sürekli başarısız olan mesajları sonsuza kadar yeniden denemek veya silmek yerine incelenmek üzere ayırır. Mesajları doğrudan silmez (a), sonsuza kadar denemez (c), ve yalnızca hatalı mesajları alır, her mesajı değil (d).
Gcp Messaging EventingZorluk 2
Varsayılan olarak Pub/Sub, bir subscription'da onaylanmamış bir mesajı ne kadar süre saklar?
- aSonsuza kadar — onaylanmamış mesajlar, subscription ayarlarından bağımsız olarak hiçbir zaman otomatik olarak kaldırılmaz
- bVarsayılan onay süresine (acknowledgement deadline) eşit olarak 10 saniye
- cVarsayılan olarak 7 güne kadar, daha uzun bir retention süresine yapılandırılabilir✓
- dTam olarak 1 saat, bu değeri değiştirme seçeneği yoktur
Açıklama:Pub/Sub'ın bir subscription için varsayılan mesaj saklama süresi 7 gündür ve bu pencere yapılandırılabilir. Onay süresi (b) çok daha kısa, ayrı bir ayardır ve tek bir teslim denemesinin yeniden teslimden önce ne kadar süresi olduğunu kontrol eder, toplam saklamayı değil; saklama süresi sonsuz (a) ya da bir saatte sabit (d) değildir.