---
title: "Kafka Simulator v1.4 — semântica de entrega, transações e ativo/ativo"
date: 2026-08-24T00:00:00.000Z
author: "michal"
excerpt: "Exactly-once, read_committed e o last stable offset, begin/commit/abort e o laço consume–process–produce. O módulo de transações torna o EOS — o tema mais difícil do Kafka — algo que dá para percorrer passo a passo. O modo livre também ganha um novo tipo de cluster: ativo/ativo."
---
A v1.4 acrescenta o módulo de **transações** ao [Kafka Simulator](/kafka-simulator/) — **10 novos cenários** sobre o assunto que os engenheiros mais aprovam com um aceno de cabeça e mais raramente veem de facto acontecer: a semântica exactly-once. O currículo chega a **55 de 125**.

## O que há na v1.4

As transações transformam um fluxo de escritas numa unidade atómica, e mudam aquilo que um consumidor tem permissão para ver:

- **`read_committed` e o last stable offset (LSO)** — porque é que um consumidor transacional lê até ao LSO em vez de até ao high watermark, e como uma transação aberta segura esse teto no lugar.
- **begin / commit / abort** — o ciclo de vida transacional do produtor como uma máquina de estados que tu conduzes, incluindo o que um marcador de abort faz aos registos que cobre.
- **O laço consume–process–produce** — `sendOffsetsToTransaction`, e porque é que fazer commit dos offsets *dentro* da transação é o que torna o exactly-once ponta a ponta real.
- **Fencing** — como um produtor zombie é excluído pela epoch, e porque é que essa é a rede de segurança sob todo o modelo.

Exactly-once é difícil de ensinar porque muito dele é invisível: os marcadores, o LSO, as epochs e um consumidor que salta em silêncio os registos abortados. O simulador põe tudo isso na linha temporal — dá para ver o LSO ficar parado sob uma transação aberta e saltar em frente no instante em que ela faz commit.

## Novo tipo de cluster no modo livre: ativo/ativo

A escada de topologias que começou na v1.3 com o ativo/passivo continua a subir: o seletor de cluster do modo livre ganha uma terceira forma — **Ativo / ativo**: duas regiões, ambas a aceitar escritas, cada uma a replicar para a outra.

Não é, deliberadamente, «o ativo/passivo com a seta duplicada». A predefinição é *simétrica*:

- **Cada região é dona do seu próprio tópico.** `west` é dona de `west.orders`, `east` é dona de `east.orders`, e cada um é replicado só de leitura para a outra região — assim ambos os lados guardam o fluxo inteiro sem ambiguidade sobre quem pode escrever com o mesmo nome.
- **Cada região escreve local e lê global.** Um produtor só escreve no tópico da sua própria região; o grupo de consumidores de cada região lê tanto o tópico local como a cópia replicada, por isso cada registo é visto uma vez por lado.
- **Cada região é um cluster próprio.** Ambas correm um quórum KRaft independente, por isso podes matar os controladores de uma região — ou a região inteira — e observar o que o lado sobrevivente consegue e deixa de conseguir fazer.

É esse último ponto que dá o contraste afiado com as garantias transacionais que este pacote ensina: exactly-once é uma promessa *por cluster*, e um par ativo/ativo são dois clusters. Tudo o que o módulo de transações te dá vale dentro de uma região e para no mirror.

O *currículo* de DR que explica estas formas continua a chegar na v1.8 — os sandboxes aterram primeiro de propósito, para que tenhas onde experimentar as ideias antes de os cenários as narrarem.

## Assente sobre a replicação

Este pacote assenta diretamente na v1.3. Uma transação é uma garantia de durabilidade com atomicidade acrescentada por cima, por isso o ISR e o high watermark que aprendeste a ler ali continuam a ser o chão aqui — o LSO é apenas um teto mais estrito acima deles.

Abre o [simulador](/kafka-simulator/), começa uma transação, produz para dentro dela e aborta-a — e depois vê o que um consumidor `read_committed` vê e não vê.