juplo.de Git - demos/kafka/chat/blob - README.txt

   1 Aktuelle Idee für die Kafka-Anbindung
   2 =====================================
   3
   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)`
  13     abgelehnt werden!
  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
  38     erreicht ist.
  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
  42     zu ermitteln.
  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`*
  48     erfolgt.
  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
  64     wurden.
  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!