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 - *Lade-Modus - Initialisierung und Abschluss-Bedingung:*
31 - Wenn durch einen Rebalance in den Lade-Modus gewechselt wird, muss die
32 *tatsächliche* Offset-Position der zuletzt geschriebenen Nachrichten
33 für die zugeordneten Partitionen ermittelt werden.
34 - Anschließend wird ein Seek auf die Offset-Position 0 (später: auf die
35 in den lokalen Daten gespeicherte Offset-Position) durchgeführt.
36 - Der Lade-Modus ist abgeschlossen, wenn für alle zugeordneten Partitionen
37 der zum Rebalance-Zeitpunkt ermittelte Offset der aktuellsten Nachrichten
39 - Wenn ein weiterer Rebalance erfolgt, während der Lade-Modus bereits
40 aktiv ist, sollte es genügen, die Informationen über die zugeordneten
41 Partitionen zu aktualisieren und die Aktuellen Offsets für diese neu
43 - *Lade-Modus vs. Default-Modus:*
44 - Nur während des Lade-Modus *liest* die `KafkaChatRoomServcie`-Instanz
45 tatsächlich die Nachrichten aus den zugeordneten Partitionen.
46 - Im Default-Modus *schreibt* sie die Nachrichten nur in die Partitionen
47 und speichert sie lokal ab, sobald die *Bestätigung durch den `Producer`*
49 - D.h. insbesondere, dass der `KafkaConsumer` im Default-Modus für alle
50 zugeordneten Partitionen *pausiert* wird!
51 - Damit die Offset-Positon nicht unnötig zurückfällt, sollte ggf.
52 regelmäßig für alle zugeordneten Partitionen ein Seek auf die zuletzt
53 vom Producer bestätigt geschriebenen Offsets durchgeführt werden.
54 - *Beachte:_ Dies ist nicht nötig, wenn die Offsets eh in den lokal
55 gespeicherten Daten gehalten und aus diesen wiederhergestellt werden!
56 - *Umsetzungs-Details:*
57 - Da die in dem Interface `ConsumerRebalanceListener` definierten Methoden
58 in einem zeitkritischem Setting laufen, muss das eigentliche Laden der
59 `ChatRoom`-Zustände separat erfolgen, so dass die Kontrolle schnell an
60 den `KafkaConsumer` zurückgegeben werden kann.
61 - Dafür muss der `KafkaChatRoomService` in einen speziellen Lade-Modus
62 wechseln, der aktiv ist, bis die `ChatRoom`-Instanzen für alle durch
63 den Rebalance zugeteilten Partitionen aus dem Log wiederhergestellt
65 - Das Lock der `KafkaChatRoomService`-Instanz muss während dieser
66 gesmaten Phase aufrecht erhalten werden: Es wird erst gelöst, wenn
67 die Instanz in den normalen Modus zurückwechselt.
68 - D.h. insbesondere auch, dass während dieser ganzen Phase _alle_
69 Anfragen mit `ShardNotOwnedException` abgelehnt werden!
70 - Eine besondere Herausforderung sind *erneute* Rebalances, die
71 Auftreten, *während* der `KafkaChatRoomService` sich noch in einem
72 durch einen vorherigen Rebalance ausgelösten Lade-Modus befindet!