Örnek sorular
St Kafka Producer Consumer SemanticsZorluk 2
Kafka producer'da linger.ms ayarı neyi kontrol eder?
- aProducer'ın bir batch'i göndermeden önce daha fazla kayıt birikmesi için ne kadar bekleyeceğini✓
- bBir broker'ın bir mesajı silinmeye uygun hale gelene kadar ne kadar tuttuğunu
- cBir consumer'ın rebalance öncesi
poll() çağrıları arasında ne kadar bekleyeceğini - dProducer'ın yeniden denemeden önce broker onayını ne kadar bekleyeceğini
Açıklama:linger.ms, bir batch'i göndermeden önce daha fazla kaydın birikmesine izin veren küçük, yapay bir gecikme ekler; bu, gecikme pahasına throughput'u artırır. Onay beklemek request.timeout.ms'in işidir, poll sıklığı consumer'ı, mesaj saklama ise broker/topic ayarını ilgilendirir.
St Kafka Producer Consumer SemanticsZorluk 3
Bir producer'da batch.size=16384 (byte) ve linger.ms=50 ayarlı. Düzenli, orta yoğunluklu trafik altında bir batch'in broker'a gönderilmesini gerçekte ne tetikler?
- aHer iki koşulun aynı anda doğru olması: batch dolu OLMALI VE 50ms geçmiş OLMALI
- bHangisi önce gerçekleşirse: batch 16384 byte'a dolar VEYA batch başladıktan sonra 50ms geçer✓
- cYalnızca
batch.size önemlidir; bir batch'te kayıt olduktan sonra linger.ms yok sayılır - dYalnızca
linger.ms önemlidir; batch.size sadece başlangıçtan sonraki ilk batch'e uygulanır
Açıklama:Bu iki ayar VE değil VEYA koşuludur: boyut eşiği aşılır aşılmaz ya da linger süresi dolar dolmaz, hangisi önce gerçekleşirse batch gönderilir. Bu, yüksek throughput'ta verimli batch'lemeyi sağlarken düşük throughput'ta en kötü durum gecikmesini de sınırlar.
St Kafka Producer Consumer SemanticsZorluk 2
Broker geçici olarak erişilemez olduğu için producer'ın buffer.memory'si gönderilmeyi bekleyen batch'lerle dolar. Bu durumda yeni bir send() çağrısına ne olur?
- aHiç beklemeden anında bir exception fırlatır
- bOtomatik olarak kaydı doğrudan local diske yazmaya geçer
- cUygulamaya haber vermeden kaydı sessizce düşürür
- d
max.block.ms süresine kadar bloke olur, sonra bir timeout exception fırlatır✓
Açıklama:Producer'ın bellek buffer'ı dolduğunda send(), yer açılmasını (örneğin bir batch tamamlanınca) max.block.ms süresine kadar bekleyerek bloke olur; bu pencerede yer açılmazsa veriyi sessizce düşürmek yerine çağırana bir timeout exception fırlatır.
St Kafka Producer Consumer SemanticsZorluk 1
Producer'ın compression.type ayarı gerçekte neyi sıkıştırır?
- a
gzip, snappy, lz4 ya da zstd gibi bir codec kullanarak tüm kayıt batch'ini✓ - bBroker'ın disk üzerindeki log segment'lerini, batch zaten yazıldıktan sonra
- cProducer ile broker arasındaki TLS handshake payload'unu
- dYalnızca her kaydın mesaj key'ini, value sıkıştırılmadan kalır
Açıklama:Kafka'da sıkıştırma batch seviyesinde uygulanır: producer, gönderme öncesi biriken tüm batch'i yapılandırılmış codec ile sıkıştırır; bu, kayıtları tek tek sıkıştırmaktan daha verimlidir.
St Kafka Producer Consumer SemanticsZorluk 2
Bir producer, manuel partition override'ı olmayan ve 6 partition'lı bir topic'e sürekli aynı key'i (örn. "user-42") taşıyan ProducerRecord'lar gönderiyor. Bu kayıtlara ne olur?
- aO anda en az veriye sahip partition'a yönlendirilir
- bKey'in değerinden bağımsız olarak partition 0'a düşer
- cYükü eşit dağıtmak için 6 partition'a round-robin şekilde dağıtılır
- dPartition sayısı 6'da sabit kaldığı sürece hepsi aynı partition'a hash'lenir✓
Açıklama:Varsayılan partitioner, bir partition'ı deterministik olarak seçmek için kayıt key'ini hash'ler; bu yüzden partition sayısı değişmediği sürece aynı key her zaman aynı partition'a eşlenir. Key bazlı sıralamayı mümkün kılan da budur.
St Kafka Producer Consumer SemanticsZorluk 3
Bir producer, bir topic'e key'siz (key == null) kayıtlar gönderiyor. Modern Kafka client'larında (2.4+) varsayılan partitioner bu kayıtları partition'lara nasıl dağıtır?
- aArdışık her kaydı kesinlikle farklı bir partition'a round-robin sırayla gönderir
- bBir partition'a batch dolana kadar 'yapışır', sonra başka bir partition'a geçer✓
- cSıralamayı basit tutmak için tüm key'siz kayıtları sadece partition 0'a gönderir
- dÖzel bir partitioner yapılandırılmadıkça key'siz kayıtları göndermeyi reddeder
Açıklama:Kafka'nın varsayılan mantığı 2.4'ten beri key'siz kayıtlar için sticky batch'leme kullanır: batch hazır olana kadar bir partition'da kalır, sonra geçer. Kafka 3.3, KIP-794 ile uygulamayı değiştirmiş; bu batch davranışını korurken broker performansına adaptasyonu eklemiştir.