1 Aktuelle Idee für die Kafka-Anbindung
2 =====================================
4 - *Beobachtung:* Alle schreibenden Anfragen für Nachrichten müssen erst
5 durch `ChatHomeService.getChatRoom(int, UUID)` den zuständigen
6 `ChatRoom` ermitteln, bevor sie die Nachricht schreiben können.
7 - D.h., das Locking, das während einem Rebalance nötig ist, kann
8 *vollständig* in `KafkaChatHomeService` umgesetzt werden.
9 - In `KafkaChatRoomService` muss *keinerlei* Kontrolle mehr erfolgen,
10 ob der `ChatRoom` tatsächlich gerade in die Zuständigkeit der Instanz
11 fällt, da die Anfragen *hier nie ankommen*, wenn die Instanz nicht
12 zuständig ist, da sie dann bereits in `getChatRoom(int, UUID)`
14 - Die in der Domain-Klasse `ChatRoom` definierte Logik, für die
15 Behandlung doppelter Nachrichten *ist vollständig valide*, da Anfragen
16 für einen bestimmten `ChatRoom` dort (bei korrekt implementiertem Locking
17 in `KafkaChatHomeService`) nur ankommen, wenn die Instanz *tatsächlich*
18 für den `ChatRoom` zuständig ist.
19 - D.h. insbesondere auch, dass die Antwort dort (also in dem `ChatRoom`)
20 erst ankommen, wenn dieser *vollständig geladen* ist, so dass die lokale
21 Kontrolle auf doppelte Nachrichten logisch gültig ist.
22 - *Anforderung:* Wenn ein Rebalance aktiv ist, wird die Instanz gelockt.
23 - Das Locking erfolg in `KafkaChatRoomService`, durch das alle Anfragen
24 durchgreifen müssen, so dass hier *zentral alle Aktionen* auf einzelnen
25 `ChatRoom`-Instanzen *unterbunden* werden können.
26 - *Vereinfachung:* Wenn `KafkaChatRoomService` gelockt ist, wird für alle
27 Zugriffe eine `ShardNotOwnedException` erzeugt.
28 - Dadurch wird das Zustands-Handling *extrem vereinfacht*, da Anfragen,
29 die *während* einem Rebalance auflaufen
30 - *Umsetzungs-Details:*
31 - Da die in dem Interface `ConsumerRebalanceListener` definierten Methoden
32 in einem zeitkritischem Setting laufen, muss das eigentliche Laden der
33 `ChatRoom`-Zustände separat erfolgen, so dass die Kontrolle schnell an
34 den `KafkaConsumer` zurückgegeben werden kann.
35 - Dafür muss der `KafkaChatRoomService` in einen speziellen Lade-Modus
36 wechseln, der aktiv ist, bis die `ChatRoom`-Instanzen für alle durch
37 den Rebalance zugeteilten Partitionen aus dem Log wiederhergestellt
39 - Das Lock der `KafkaChatRoomService`-Instanz muss während dieser
40 gesmaten Phase aufrecht erhalten werden: Es wird erst gelöst, wenn
41 die Instanz in den normalen Modus zurückwechselt.
42 - D.h. insbesondere auch, dass während dieser ganzen Phase _alle_
43 Anfragen mit `ShardNotOwnedException` abgelehnt werden!
44 - Eine besondere Herausforderung sind *erneute* Rebalances, die
45 Auftreten, *während* der `KafkaChatRoomService` sich noch in einem
46 durch einen vorherigen Rebalance ausgelösten Lade-Modus befindet!