Kanal tampon boyutu seçimi backpressure sorunlarını gizler mi, nasıl karar vermeliyim?

Kısa cevap: Evet, büyük bir buffer backpressure’ı gizler.

Kısa cevap

Buffer’ı küçük tutun, bloklamanın Kafka poll döngüsüne kadar yansımasına izin verin ve tüketici sayısını ölçülen consumer lag’e göre artırın — buffer boyutuna göre değil.

Neden

1. Backpressure’ın tanımı zaten bloklamadır. Unbuffered ya da küçük buffer’lı bir kanalın amacı, yavaş consumer’ın producer’ı bloklamasıdır — hissetmek istediğiniz sinyal budur. 10.000’lik buffer bu sinyali susturur; bir throughput problemini bir latency + bellek problemine çevirir ve sorunu sadece geciktirir.

2. Buffer throughput eklemez, yalnızca burst yutar. Sürekli üretim hızı > sürekli tüketim hızı ise hiçbir buffer boyutu sizi kurtarmaz: dolar ve yine bloklarsınız, sadece daha geç. Buffer yalnızca ortalama tüketim ortalama üretime yetiştiği, ama gelişin düzensiz/burst olduğu durumda anlamlıdır.

3. Kafka’da gerçek backpressure = poll’u yavaşlatmak. Kanal bloklandığında consumer döngünüz bir sonraki mesajı çekmeyi bırakır; Kafka tarafında consumer lag büyür. Bu tam olarak istediğiniz sinyaldir ve üstelik broker’da durable’dır. On binlerce mesajı bellekte tamponlamak, in-flight işi commit edilen offset’ten koparır: offset işlenmeden önce commit ediliyorsa (auto-commit gibi) process çökmesinde o mesajları kaybedersiniz; offset işlem tamamlandıktan sonra commit ediliyorsa (bu örnekteki gibi) mesajlar kaybolmaz, sadece yeniden işlenir.

Ne yapmalı

1. Boyut kuralı: 0 ya da küçük (worker sayısının 1-2 katı). Amaç scheduling jitter’ını yumuşatmaktır, hız uyumsuzluğunu saklamak değil. Bounded bir worker havuzu + küçük kanal, hem paralelliği verir hem bloklamayı geri yansıtır.

   jobs := make(chan Event, len(workers)) // buffer ≈ worker sayısı, devasa değil
   for i := 0; i < len(workers); i++ {
       go func() {
           for e := range jobs {
               process(e)
           }
       }()
   }
   for msg := range consumer.Poll() {
       jobs <- decode(msg) // kanal doluysa burada bloklar → poll yavaşlar → Kafka lag artar
       consumer.Commit(msg) // işlenene kadar commit etmeyerek at-least-once koruyun
   }

2. Sinyali ölçün, yoksa gizli kalır. len(ch)/cap(ch), Kafka consumer lag ve işleme latency’sini metrik olarak dışa verin. Kanal sürekli cap’e yakın seyrediyorsa consumer’lar yetişemiyordur — cevap buffer’ı büyütmek değil, worker sayısını artırmak (ya da işleme adımını hızlandırmak).

3. Sinyali Kafka’da tutun, kanalda değil. Lag broker’da kalıcıdır ve dashboard’unuzda görünür; bellekteki buffer ise çökünce yok olur. Backpressure’ın nerede biriktiğini seçebiliyorsanız, dayanıklı ve gözlemlenebilir yeri seçin.

Sonuç: Ben olsam 10.000’lik buffer’ı hemen küçültüp kanal kapasitesini worker sayısına yakın bir yere çekerdim. Bloklamanın poll döngüsüne kadar yansımasına izin verip Kafka consumer lag’i birincil backpressure metriğim yapardım. Yük altında lag kalıcı olarak artıyorsa worker havuzunu ya da işleme hızını büyütürdüm — asla tamponu değil. Büyük buffer bir çözüm değil, problemin görünmez olduğu penceredir.