La v1.4 ajoute le module transactions au Kafka Simulator — 10 nouveaux scénarios sur le sujet que les ingénieurs approuvent le plus souvent d’un hochement de tête et voient le plus rarement à l’œuvre : la sémantique exactly-once. Le programme atteint 55 sur 125.

Ce que contient la v1.4

Les transactions transforment un flux d’écritures en une unité atomique, et elles changent ce qu’un consommateur a le droit de voir :

  • read_committed et le last stable offset (LSO) — pourquoi un consommateur transactionnel lit jusqu’au LSO plutôt que jusqu’au high watermark, et comment une transaction ouverte maintient ce plafond en place.
  • begin / commit / abort — le cycle de vie transactionnel du producteur comme une machine à états que vous pilotez vous-même, y compris ce qu’un marqueur d’abort fait aux enregistrements qu’il couvre.
  • La boucle consume–process–produce — sendOffsetsToTransaction, et pourquoi valider les offsets à l’intérieur de la transaction est ce qui rend l’exactly-once de bout en bout réel.
  • Le fencing — comment un producteur zombie est exclu par son epoch, et pourquoi c’est le filet de sécurité sous tout le modèle.

L’exactly-once est difficile à enseigner parce qu’une grande partie en est invisible : les marqueurs, le LSO, les epochs, et un consommateur qui saute silencieusement les enregistrements abandonnés. Le simulateur met tout cela sur la timeline — vous pouvez voir le LSO rester immobile sous une transaction ouverte et bondir en avant à l’instant où elle est validée.

Nouveau type de cluster en mode libre : actif/actif

L’échelle de topologies commencée en v1.3 avec l’actif/passif continue de monter : le sélecteur de cluster du mode libre gagne une troisième forme — Actif / actif : deux régions, toutes deux acceptant les écritures, chacune répliquant vers l’autre.

Ce n’est délibérément pas « l’actif/passif avec la flèche doublée ». Le préréglage est symétrique :

  • Chaque région possède son propre topic. west possède west.orders, east possède east.orders, et chacun est répliqué en lecture seule vers l’autre région — les deux côtés détiennent donc tout le flux, sans ambiguïté sur qui peut écrire sous un même nom.
  • Chaque région écrit en local et lit en global. Un producteur n’écrit que dans le topic de sa propre région ; le groupe de consommateurs de chaque région lit à la fois le topic local et la copie répliquée, de sorte que chaque enregistrement est vu une fois par côté.
  • Chaque région est son propre cluster. Toutes deux font tourner un quorum KRaft indépendant : vous pouvez donc tuer les contrôleurs d’une région — ou la région entière — et observer ce que le côté survivant peut faire, et ne peut plus faire.

C’est précisément ce dernier point qui offre le contraste tranchant avec les garanties transactionnelles enseignées par ce pack : l’exactly-once est une promesse par cluster, et une paire actif/actif, ce sont deux clusters. Tout ce que le module transactions vous donne tient à l’intérieur d’une région et s’arrête au mirror.

Le programme DR qui explique ces formes arrive toujours en v1.8 — les bacs à sable atterrissent d’abord, volontairement, pour que vous ayez où essayer les idées avant que les scénarios ne les racontent.

Dans le prolongement de la réplication

Ce pack repose directement sur la v1.3. Une transaction est une garantie de durabilité à laquelle on ajoute l’atomicité : l’ISR et le high watermark que vous avez appris à lire là-bas restent le socle ici — le LSO n’est qu’un plafond plus strict au-dessus d’eux.

Ouvrez le simulateur, démarrez une transaction, produisez dedans puis abandonnez-la — et regardez ensuite ce qu’un consommateur read_committed voit et ne voit pas.