I colloqui su Kafka verificano se capisci come i dati si muovono attraverso un log: come i topic vengono suddivisi in partizioni, su quale ordinamento puoi fare affidamento, come i consumer si distribuiscono il lavoro e cosa succede quando qualcosa va storto. Le domande basate su scenari riguardanti lag, duplicati e perdita di dati sono comuni, perché sono i problemi che si incontrano in produzione.
Di seguito trovi 22 domande con risposte. Dettagli come i valori predefiniti variano tra le versioni di Kafka, quindi menziona che controlleresti la versione in uso.
Concetti fondamentali
1. Cos'è Kafka e a cosa serve?
Kafka è un commit log distribuito e replicato. I producer aggiungono record ai topic e i consumer li leggono al proprio ritmo. È usato per lo streaming di eventi, pipeline di log e metriche, disaccoppiamento dei servizi, alimentazione di sistemi analitici e stream processing.
2. Cosa sono i topic, le partizioni e gli offset?
Un topic è un flusso di record con un nome. Ogni topic è suddiviso in partizioni, e ogni partizione è un log ordinato e append-only. Ogni record in una partizione ha un offset, un numero sequenziale che ne identifica la posizione. Gli offset sono univoci solo all'interno di una partizione.
3. In che modo le partizioni influenzano l'ordinamento?
Kafka garantisce l'ordine solo all'interno di una partizione. I record con la stessa chiave vanno nella stessa partizione per impostazione predefinita, quindi mantengono l'ordine tra loro. Tra partizioni diverse non c'è ordinamento. Se ti serve che tutti gli eventi di un cliente siano in ordine, usa l'ID del cliente come chiave.
4. Cos'è un broker e cosa fa il controller?
Un broker è un server Kafka che memorizza le partizioni e serve i client. Un cluster ha diversi broker. Uno di essi svolge il ruolo di controller, che gestisce i metadati del cluster e la leadership delle partizioni. Le versioni più recenti di Kafka usano KRaft, un meccanismo di consenso integrato, al posto di ZooKeeper per questi metadati.
5. Come funziona la replica?
Ogni partizione ha un replication factor. Una replica è il leader, che gestisce letture e scritture, e le altre sono follower che la copiano. Le in-sync replica (ISR) sono quelle allineate con il leader. Se il leader fallisce, viene scelto un nuovo leader tra le ISR.
Producer
6. Cosa significano le impostazioni di acks?
| acks | Significato | Compromesso |
|---|---|---|
| 0 | Il producer non attende alcuna conferma | Più veloce, può perdere dati |
| 1 | Il leader conferma dopo la scrittura | Può perdere dati se il leader fallisce prima della replica |
| all | Il leader attende tutte le in-sync replica | Durabilità massima, latenza più alta |
Per scritture durevoli, usa acks=all con min.insync.replicas impostato ad almeno 2 e un replication factor di 3.
7. Come si evitano i messaggi duplicati da parte di un producer?
Abilita il producer idempotente (enable.idempotence=true), che permette al broker di scartare i duplicati causati dai retry all'interno di una partizione. Per scritture che devono coinvolgere più partizioni o topic in modo atomico, usa le transazioni.
8. Come sceglie un producer la partizione?
Se fornisci una chiave, il partitioner predefinito ne calcola l'hash per scegliere la partizione. Senza chiave, il producer distribuisce i record tra le partizioni (le versioni recenti usano un approccio sticky per riempire i batch in modo efficiente). Puoi anche scrivere un partitioner personalizzato.
9. Cosa influenza il throughput di un producer?
Il batching (batch.size, linger.ms), la compressione (come lz4 o zstd), il numero di partizioni e acks. Batch più grandi e la compressione di solito aumentano il throughput al costo di un po' di latenza.
Consumatori
10. Che cos'è un gruppo di consumatori?
Un insieme di consumatori che si dividono il lavoro di lettura di un topic. Ogni partizione è assegnata a un solo consumatore del gruppo alla volta. Quindi il numero di consumatori utili in un gruppo è limitato dal numero di partizioni, e i consumatori in eccesso restano inattivi.
11. Cosa succede durante un rebalance?
Quando un consumatore si unisce o esce, o quando cambiano le partizioni, il gruppo riassegna le partizioni. Durante un rebalance classico, il consumo si mette in pausa mentre questo avviene. Il rebalancing cooperativo e la static membership riducono il disagio. I rebalance frequenti spesso derivano da consumatori che impiegano troppo tempo a elaborare (max.poll.interval.ms) o che non inviano gli heartbeat.
12. Come vengono committati gli offset?
I consumatori committano l'offset del prossimo record da leggere, memorizzato in un topic interno. L'auto-commit è semplice ma può committare prima che l'elaborazione sia terminata. I commit manuali dopo l'elaborazione ti danno il controllo su cosa significa "fatto".
13. Cosa significano at-most-once, at-least-once ed exactly-once?
- At-most-once: committa l'offset prima dell'elaborazione. Un crash può perdere record.
- At-least-once: elabora, poi committa. Un crash può causare una rielaborazione, quindi i duplicati sono possibili.
- Exactly-once: l'effetto avviene una sola volta. In Kafka questo è possibile all'interno di Kafka usando producer idempotenti, transazioni e consumatori read_committed. Quando si scrive su un sistema esterno, di solito servono scritture idempotenti o deduplicazione tramite una chiave.
Una buona risposta dice che "exactly once" dipende da dove si trovano gli effetti collaterali.
14. Come gestiresti un poison message che fallisce sempre?
Cattura l'errore, riprova un numero limitato di volte, poi invia il record a un dead-letter topic con i dettagli, committa l'offset e vai avanti. Configura un alert sul dead-letter topic così che qualcuno indaghi.
Operazioni e scenari
15. Il consumer lag sta crescendo. Come lo diagnostichi?
- Controlla quali partizioni hanno lag. Una sola partizione calda indica una chiave sbilanciata. Lag ovunque indica un'elaborazione lenta o troppi pochi consumatori.
- Controlla il tempo di elaborazione per record e le chiamate a valle come un database.
- Controlla se ci sono rebalance frequenti.
- Controlla se il rate del producer è aumentato.
- Risolvi con più consumatori (fino al numero di partizioni), un'elaborazione più veloce, la gestione a batch o più partizioni.
16. Quando dovresti aumentare il numero di partizioni?
Quando ti serve più parallelismo di quanto i consumatori attuali possano fornire, o quando il throughput per partizione è il limite. Attenzione: aggiungere partizioni cambia la mappatura chiave-partizione per i nuovi record, quindi l'ordinamento per una chiave può rompersi durante il cambiamento. Pianifica il numero di partizioni in anticipo quando l'ordinamento è importante.
17. Come vengono conservati i dati e cosa è la log compaction?
Per impostazione predefinita, Kafka elimina i vecchi segmenti in base al tempo o alla dimensione (retention.ms, retention.bytes). Con la log compaction, Kafka mantiene almeno l'ultimo valore per ogni chiave, il che si adatta a un changelog o a un topic simile a una tabella. Un valore null (un tombstone) contrassegna una chiave per l'eliminazione.
18. Cosa succede se un broker si guasta?
Le partizioni guidate da quel broker eleggono nuovi leader dall'ISR. I client aggiornano i metadati e continuano. Se non c'è una replica in sync disponibile, la partizione non è disponibile a meno che tu non consenta l'elezione di un leader unclean, che rischia una perdita di dati.
19. Come proteggi un cluster Kafka?
TLS per la crittografia in transito, SASL (come SCRAM o OAuth) o mutual TLS per l'autenticazione, ACL per l'autorizzazione su topic e gruppi, e controlli di rete. Cripta i campi sensibili a livello applicativo se necessario.
20. Come monitori Kafka?
I segnali chiave sono il consumer lag, le partizioni under-replicated, le partizioni offline, la latenza delle richieste, l'utilizzo del disco e i tassi di riduzione e aumento dell'ISR, raccolti tramite metriche JMX e strumenti come Prometheus e Grafana.
Domande di progettazione
21. Quando sceglieresti Kafka invece di una coda di messaggi come RabbitMQ o SQS?
Scegli Kafka quando ti serve un throughput elevato, la riproduzione di eventi passati, diversi consumatori indipendenti dello stesso stream o lo stream processing. Scegli una coda tradizionale per il routing per messaggio, code di attività semplici o quando non vuoi gestire le partizioni.
22. Progetta una pipeline di eventi di ordini.
"Gli ordini vanno in un topic orders con chiave l'ID dell'ordine, così gli eventi di un ordine restano in ordine. Userei tre o più broker, un replication factor di 3, acks=all e producer idempotenti. I consumatori per fatturazione, inventario e analytics usano ciascuno il proprio gruppo. Le scritture di fatturazione sono idempotenti per ID ordine, i record falliti vanno in un dead-letter topic e monitorerei il lag per gruppo. Sceglierei il numero di partizioni in base al throughput di picco e al numero previsto di consumatori, con margine di crescita."
Come prepararsi
Se puoi, avvia un Kafka in locale, scrivi un producer e un consumer group, ferma un consumer e osserva il rebalance. Rompi qualcosa di proposito, ad esempio un consumer lento, e guarda il lag. Preparati una storia reale su un problema di data pipeline che hai risolto. Per argomenti correlati, consulta le nostre guide su Databricks e colloqui di system design.
Esercitati a spiegare ad alta voce le garanzie di consegna, perché è lì che le risposte diventano vaghe. Un colloquio simulato e una trascrizione ti mostreranno dove. Segui le regole del datore di lavoro sugli strumenti di AI in qualsiasi colloquio dal vivo.
Esercitati con le risposte per colloqui su Kafka con YesToTheOffer
Fai un colloquio tecnico simulato, spiega ad alta voce le garanzie di consegna e rivedi la trascrizione in seguito. 30 minuti gratuiti, senza abbonamento.
