---
title: "Kafka Simulator v1.4 — semantica di consegna, transazioni e attivo/attivo"
date: 2026-08-24T00:00:00.000Z
author: "michal"
excerpt: "Exactly-once, read_committed e il last stable offset, begin/commit/abort e il ciclo consume–process–produce. Il modulo transazioni rende l'EOS — l'argomento più difficile di Kafka — qualcosa che puoi percorrere passo dopo passo. Il free play guadagna anche un nuovo tipo di cluster: attivo/attivo."
---
La v1.4 aggiunge il modulo **transazioni** al [Kafka Simulator](/kafka-simulator/) — **10 nuovi scenari** sull'argomento che gli ingegneri approvano più spesso con un cenno del capo e vedono davvero all'opera più raramente: la semantica exactly-once. Il programma arriva a **55 su 125**.

## Cosa c'è nella v1.4

Le transazioni trasformano un flusso di scritture in un'unità atomica, e cambiano ciò che un consumer ha il permesso di vedere:

- **`read_committed` e il last stable offset (LSO)** — perché un consumer transazionale legge fino all'LSO e non fino all'high watermark, e come una transazione aperta tiene fermo quel tetto.
- **begin / commit / abort** — il ciclo di vita transazionale del producer come una macchina a stati che guidi tu, incluso ciò che un marker di abort fa ai record che copre.
- **Il ciclo consume–process–produce** — `sendOffsetsToTransaction`, e perché committare gli offset *dentro* la transazione è ciò che rende reale l'exactly-once end-to-end.
- **Il fencing** — come un producer zombie viene escluso tramite epoch, e perché è la rete di sicurezza sotto l'intero modello.

L'exactly-once è difficile da insegnare perché gran parte è invisibile: i marker, l'LSO, gli epoch e un consumer che salta in silenzio i record abortiti. Il simulatore mette tutto sulla timeline — puoi guardare l'LSO restare fermo sotto una transazione aperta e balzare in avanti nell'istante in cui viene committata.

## Nuovo tipo di cluster nel free play: attivo/attivo

La scala di topologie iniziata in v1.3 con l'attivo/passivo continua a salire: il selettore di cluster del free play guadagna una terza forma — **Attivo / attivo**: due regioni, entrambe accettano scritture, ciascuna replica verso l'altra.

Non è, deliberatamente, «l'attivo/passivo con la freccia raddoppiata». Il preset è *simmetrico*:

- **Ogni regione possiede il proprio topic.** `west` possiede `west.orders`, `east` possiede `east.orders`, e ciascuno viene replicato in sola lettura nell'altra regione — così entrambi i lati custodiscono l'intero flusso senza ambiguità su chi possa scrivere sotto lo stesso nome.
- **Ogni regione scrive in locale e legge in globale.** Un producer scrive solo nel topic della propria regione; il consumer group di ogni regione legge sia il topic locale sia la copia replicata, così ogni record viene visto una volta per lato.
- **Ogni regione è un cluster a sé.** Entrambe eseguono un quorum KRaft indipendente, quindi puoi uccidere i controller di una regione — o l'intera regione — e osservare cosa il lato superstite riesce e non riesce più a fare.

Proprio quest'ultimo punto è il contrasto tagliente con le garanzie transazionali che questo pack insegna: l'exactly-once è una promessa *per cluster*, e una coppia attivo/attivo sono due cluster. Tutto ciò che il modulo transazioni ti dà vale dentro una regione e si ferma al mirror.

Il *programma* DR che spiega queste forme arriva sempre in v1.8 — le sandbox atterrano prima di proposito, così hai dove provare le idee prima che gli scenari le raccontino.

## Sulle fondamenta della replica

Questo pack poggia direttamente sulla v1.3. Una transazione è una garanzia di durabilità con l'atomicità aggiunta sopra, quindi l'ISR e l'high watermark che lì hai imparato a leggere restano il terreno solido anche qui — l'LSO è semplicemente un tetto più stretto al di sopra.

Apri il [simulatore](/kafka-simulator/), avvia una transazione, produci al suo interno e abortiscila — poi guarda cosa un consumer `read_committed` vede e cosa no.