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 - *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
  38     wurden.
  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!