Ereignisgesteuerte Systeme - Exam

Aufgabe 1)

Kontext eines Logistiksystems: Ein Logistikunternehmen plant die Einführung eines neuen ereignisgesteuerten Systems zur Überwachung und Steuerung der Lieferketten. Die Hauptkomponenten dieses Systems umfassen Fahrer, Fahrzeuge, Warenlager und Pakete. Ereignisse in diesem System beinhalten das Ankommen eines Fahrzeugs im Lager, das Verladen der Pakete, das Verlassen des Lagers und die Auslieferung an Kunden.

a)

Beschreibe das Konzept der Ereignisquelle und -senke im Kontext des Logistiksystems. Erläutere, welche Komponenten als Ereignisquelle und welche als Ereignissenke fungieren könnten. Gib konkrete Beispiele für Ereignisse in diesem System.

Lösung:

Konzept der Ereignisquelle und -senke im Kontext des Logistiksystems

• Ereignisquelle: Eine Ereignisquelle ist eine Komponente des Systems, die ein bestimmtes Ereignis initiiert oder hervorruft. Im Kontext des Logistiksystems könnten folgende Komponenten als Ereignisquellen fungieren:
  • Fahrer: Ein Fahrer kann Ereignisse wie das Ankommen am Lager, das Verladen von Paketen oder das Starten der Auslieferung anstoßen.
  • Fahrzeuge: Ein Fahrzeug selbst könnte als Quelle von Ereignissen wie das Ankommen im Lager oder das Verlassen des Lagers fungieren.
• Ereignissenke: Eine Ereignissenke ist eine Komponente des Systems, die ein bestimmtes Ereignis empfängt oder darauf reagiert. Im Kontext des Logistiksystems könnten folgende Komponenten als Ereignissenken fungieren:
  • Warenlager: Das Lager kann Ereignisse wie das Ankommen von Fahrzeugen oder das Verladen von Paketen empfangen.
  • Pakete: Die Pakete selbst könnten als Senke für Ereignisse wie das Verladen auf ein Fahrzeug oder die Auslieferung an den Kunden betrachtet werden.

Konkrete Beispiele für Ereignisse in diesem System:

• Ankommen eines Fahrzeugs im Lager: Das Ereignis wird vom Fahrzeug (Quelle) initiiert und vom Lager (Senke) empfangen.
• Verladen von Paketen auf ein Fahrzeug: Das Lager (Quelle) initiiert das Ereignis und die Pakete sowie das Fahrzeug (Senken) empfangen es.
• Verlassen des Lagers durch ein Fahrzeug: Das Fahrzeug (Quelle) initiiert das Ereignis und das Lager (Senke) empfängt es.
• Auslieferung eines Pakets an den Kunden: Der Fahrer (Quelle) initiiert das Ereignis und das Paket sowie der Kunde (Senken) empfangen es.

b)

Analysiere die Vorteile der Nutzung eines ereignisgesteuerten Architekturstils in diesem Logistiksystem. Gehe dabei insbesondere auf die Aspekte Modularität, Flexibilität und Erweiterbarkeit ein.

Lösung:

Vorteile der Nutzung eines ereignisgesteuerten Architekturstils im Logistiksystem

• Modularität:
  • Ereignisgesteuerte Architekturen fördern eine klare Trennung der Hauptkomponenten, wie Fahrer, Fahrzeuge, Warenlager und Pakete, in eigenständige, unabhängige Module.
  • Jedes Modul kann unabhängig entwickelt, getestet und gewartet werden, was die Gesamteffizienz erhöht und Fehlerbehebung vereinfacht.
  • Änderungen oder Upgrades an einem Modul haben keinen direkten Einfluss auf andere Module, solange die Schnittstellen standardisiert und eindeutig definiert sind.
• Flexibilität:
  • Durch die Nutzung eines ereignisgesteuerten Ansatzes kann das System flexibel auf variable Geschäftsanforderungen und Umgebungseinflüsse reagieren.
  • Neue Ereignisse können leicht hinzugefügt werden, ohne das gesamte System umgestalten zu müssen. Zum Beispiel kann ein neues Ereignis eingeführt werden, wenn ein neuer Sensortyp in Fahrzeugen verwendet wird.
  • Es ermöglicht dynamische Anpassungen, wie z.B. Routenänderungen basierend auf Echtzeit-Verkehrsdaten, ohne den kontinuierlichen Betrieb des Systems zu stören.
• Erweiterbarkeit:
  • Ein ereignisgesteuertes System ist grundsätzlich auf Erweiterbarkeit ausgelegt, da neue Komponenten und Funktionen leicht hinzugefügt werden können.
  • Externe Systeme wie Lieferanten- oder Kundensysteme können einfacher integriert werden, indem sie auf die definierten Ereignisse reagieren oder eigene Ereignisse auslösen.
  • Eine Erweiterung der Geschäftstätigkeit, z.B. in neue geografische Regionen oder Marktsegmente, kann schneller und kosteneffizienter implementiert werden.

c)

Stelle ein Beispiel für einen Ereignisstrom in diesem Logistiksystem dar. Skizziere die Abfolge der Ereignisse von der Abholung der Pakete bis zur Auslieferung an den Endkunden. Integriere spezielle Technologien wie Event Sourcing und CQRS in Deine Antwort.

Lösung:

Beispiel für einen Ereignisstrom in einem Logistiksystem

• Abholung der Pakete:
  • Fahrer und Fahrzeug erreichen ein Lager.
    • Ereignis 1: Fahrzeug angekommen
  • Pakete werden auf das Fahrzeug verladen.
    • Ereignis 2: Pakete verladen
  • Fahrzeug verlässt das Lager mit den Paketen.
    • Ereignis 3: Fahrzeug verlässt Lager
• Transport:
  • Während des Transports können verschiedene Ereignisse auftreten, wie z.B. Geolokalisierung und Statusupdates.
    • Ereignis 4: Standortupdate des Fahrzeugs
    • Ereignis 5: Status des Fahrzeugs (Halt, Bewegung, etc.)
• Auslieferung:
  • Fahrzeug erreicht das Zielgebiet und der Fahrer beginnt mit der Auslieferung an die Kunden.
    • Ereignis 6: Fahrzeug im Zielgebiet angekommen
  • Pakete werden an die jeweiligen Kunden ausgeliefert.
    • Ereignis 7: Paket an Kunden 1 ausgeliefert
    • Ereignis 8: Paket an Kunden 2 ausgeliefert

Technologien wie Event Sourcing und CQRS können wie folgt integriert werden:

• Event Sourcing: Jedes Ereignis, das im System auftritt, ist persistent und wird in einer Ereignislog oder einem Ereignis-Store gespeichert. Das bedeutet, dass der Zustand des gesamten Systems rückverfolgbar ist und zu einem beliebigen Zeitpunkt rekonstruiert werden kann. Beispiele sind:
  • Speichern jedes Fahrzeug angekommen-Ereignisses
  • Speichern jedes Paket verladen-Ereignisses
• CQRS (Command Query Responsibility Segregation): Dieser Architekturstil trennt die Verantwortung für das Schreiben von Daten (Commands) und das Lesen von Daten (Queries). In unserem Logistiksystem könnte es wie folgt angewendet werden:
  • Commands:
    • Initiieren eines Fahrzeug angekommen-Commands, wenn ein Fahrzeug das Lager erreicht.
    • Initiieren eines Paket verladen-Commands, wenn Pakete verladen werden.
  • Queries:
    • Abfragen des aktuellen Standortes und Status eines Fahrzeugs.
    • Abfragen der Verladehistorie eines bestimmten Pakets.

Durch die Nutzung von Event Sourcing und CQRS erhält das Logistiksystem eine verbesserte Transparenz und Nachvollziehbarkeit, sowie eine robuste und skalierbare Architektur.

d)

Betrachte die Verarbeitung von Ereignissen in Echtzeit innerhalb des Logistiksystems. Entwickle ein Java-Programm, das einen einfachen Ereignisverarbeitungs-Workflow für das Ankommen eines Fahrzeugs im Warenlager und das Verladen von Paketen simuliert. Der Workflow sollte folgende Schritte umfassen: Ereignisregistrierung, Initialisierung und Ereignisverarbeitung.

Lösung:

Verarbeitung von Ereignissen in Echtzeit innerhalb des Logistiksystems

Im Folgenden ist ein einfaches Java-Programm, das den Ereignisverarbeitungs-Workflow für das Ankommen eines Fahrzeugs im Warenlager und das Verladen von Paketen simuliert. Der Workflow umfasst Ereignisregistrierung, Initialisierung und Ereignisverarbeitung.

Hier ist der Java-Code:

 import java.util.ArrayList;  import java.util.List;   // Event classes  class Event {      String eventType;      String description;       public Event(String eventType, String description) {          this.eventType = eventType;          this.description = description;      }       public String getEventType() {          return eventType;      }       public String getDescription() {          return description;      }  }   // Event Handler class  class EventHandler {      List events = new ArrayList<>();       public void registerEvent(Event event) {          events.add(event);      }       public void initializeEventProcessing() {          System.out.println("Initialisierung der Ereignisverarbeitung...");      }       public void processEvents() {          for (Event event : events) {              System.out.println("Verarbeitung des Ereignisses: " + event.getEventType() + " - " + event.getDescription());          }      }  }   // Simulation class  public class LogisticsSystemSimulation {      public static void main(String[] args) {          EventHandler eventHandler = new EventHandler();           // Register events          eventHandler.registerEvent(new Event("Ankommen des Fahrzeugs", "Ein Fahrzeug ist im Warenlager angekommen."));          eventHandler.registerEvent(new Event("Verladen von Paketen", "Pakete werden auf das Fahrzeug verladen."));           // Initialize event processing          eventHandler.initializeEventProcessing();           // Process events          eventHandler.processEvents();      }  }   

Erklärung des Programms:

• Die Event-Klasse repräsentiert ein Ereignis mit einem Typ und einer Beschreibung.
• Die EventHandler-Klasse enthält eine Liste von Ereignissen und Methoden zur Registrierung, Initialisierung und Verarbeitung der Ereignisse.
• Die LogisticsSystemSimulation-Klasse enthält die Hauptmethode, die den Ereignisverarbeitungs-Workflow simuliert.
• In der main-Methode werden Ereignisse für das Ankommen des Fahrzeugs und das Verladen von Paketen registriert, die Ereignisverarbeitung initialisiert und schließlich die Ereignisse verarbeitet.

Mit dieser Simulation wird eine Grundstruktur für die Echtzeit-Ereignisverarbeitung in einem Logistiksystem gezeigt.

Aufgabe 2)

In einem Online-Shop-System werden verschiedene Design Patterns zur Ereignisverarbeitung eingesetzt. Ein Warehouse Service möchte darüber informiert werden, wenn der Lagerbestand bestimmter Produkte aktualisiert wird. Dazu wird das Publish-Subscribe-Muster genutzt.

Darüber hinaus soll die vollständige Historie der Lagerbewegungen nachvollzogen werden können, um den Zustand des Lagers zu einem beliebigen Zeitpunkt in der Vergangenheit rekonstruieren zu können. Dafür wird das Event Sourcing-Muster eingesetzt.

a)

1. Beschreibe das Publish-Subscribe-Muster und seine Vorteile in der oben beschriebenen Anwendung des Online-Shop-Systems. Erläutere auch detailliert, wie du dabei vorgehen würdest, wenn ein neuer Lagerstandsbericht veröffentlicht werden soll und wie der Warehouse Service davon in Kenntnis gesetzt wird. Gehe dabei auf die folgenden Punkte ein:

• Erstellen eines neuen Ereignises für den Lagerstandsbericht.
• Publizieren des Ereignisses über einen Channel/Topic.
• Anmeldeprozess des Warehouse Service für diesen Channel/Topic.

Lösung:

1. Beschreibung des Publish-Subscribe-Musterns und seiner Vorteile

Das Publish-Subscribe-Muster (kurz: Pub-Sub) ist ein Kommunikationsmuster, bei dem Sender (Publisher) und Empfänger (Subscriber) lose gekoppelt sind. Das bedeutet, dass der Publisher nicht direkt weiß, wer seine Nachrichten erhält, und der Subscriber nicht direkt weiß, wer die Nachrichten sendet. Hierbei werden Nachrichten in Topics oder Channels veröffentlicht und die Subscriber abonnieren diese Topics, um Benachrichtigungen zu erhalten.

• Flexibilität: Das Pub-Sub-Muster trennt die Logik der Ereignisgenerierung von der Ereignisverarbeitung. Dadurch können neue Services oder Funktionalitäten einfach hinzugefügt werden, ohne die bestehende Logik zu ändern.
• Skalierbarkeit: Publisher und Subscriber können unabhängig voneinander skalieren. Man kann leicht mehr Publisher oder Subscriber hinzufügen, ohne die bestehenden Systeme zu beeinträchtigen.
• Entkoppelung: Publisher und Subscriber müssen keine Kenntnis voneinander haben, was zu einer einfacheren und flexibleren Systemarchitektur führt.

Vorgehensweise bei der Veröffentlichung eines neuen Lagerstandsberichts

Um das Publizieren eines neuen Lagerstandsberichts und das Abonnieren des Warehouse Service zu erklären, gehen wir Schritt für Schritt vor:

1. Erstellen eines neuen Ereignisses:
   • Wenn sich der Lagerbestand eines Produkts ändert, wird ein neues Ereignis erstellt. Dieses Ereignis beinhaltet wichtige Informationen wie beispielsweise die Produkt-ID, die neue Lagerbestandsmenge und den Zeitstempel der Änderung.

     class LagerstandsberichtEreignis: def __init__(self, produkt_id, neue_menge, zeitstempel): self.produkt_id = produkt_id self.neue_menge = neue_menge self.zeitstempel = zeitstempel

2. Publizieren des Ereignisses:
   • Das erzeugte Ereignis wird an ein zentrales Pub-Sub-System übergeben. Ein Beispiel für ein solches System ist Apache Kafka oder ein Message-Broker wie RabbitMQ.

     def publiziere_ereignis(channel, ereignis): channel.post(ereignis)lagereignis = LagerstandsberichtEreignis(produkt_id=123, neue_menge=50, zeitstempel='2023-10-02T10:00:00Z')publiziere_ereignis('lagerbestand_channel', lagereignis)

3. Anmeldeprozess des Warehouse Service:
   • Der Warehouse Service meldet sich für den entsprechenden Channel oder Topic an. Das bedeutet, er registriert sich als Subscriber und spezifiziert, welche Nachrichten er erhalten möchte.

     class WarehouseService: def __init__(self, channel): self.channel = channel channel.subscribe(self.verarbeite_ereignis) def verarbeite_ereignis(self, ereignis): print(f'Produkt-ID: {ereignis.produkt_id}, neue Menge: {ereignis.neue_menge}')warehouse_service = WarehouseService(channel='lagerbestand_channel')

   • Immer wenn der Channel eine Nachricht erhält, ruft er die verarbeite_ereignis-Methode des Warehouse Service auf und übergibt das Ereignis zur Verarbeitung.

b)

2. Erläutere das Event Sourcing-Muster und wie es in der oben beschriebenen Situation eingesetzt wird, um die Historie der Lagerbewegungen vollständig nachzuvollziehen. Beschreibe außerdem, wie du den Systemzustand zu einem bestimmten Zeitpunkt rekonstruieren würdest. Gehe dabei auf die folgenden Punkte ein:

• Speichern der Ereignisse in einer Ereignislog.
• Einlesen und Replay der Ereignisse zur Rekonstruktion des Lagerzustands.
• Mathematisch: Gegeben sei eine Sequenz von n Ereignissen. Beschreibe mithilfe einer formalen Methode, wie du den Lagerbestand eines bestimmten Produkts aus dieser Sequenz ermittelst, und gehe dabei auf relevante Berechnungen ein.

Lösung:

2. Erläuterung des Event Sourcing-Musterns

Das Event Sourcing-Muster beseitigt die Notwendigkeit, den aktuellen Zustand eines Systems direkt zu speichern. Stattdessen speichert es eine vollständige Historie aller Zustandsänderungen (Ereignisse). Jedes Ereignis beschreibt eine Änderung im System, wodurch der aktuelle Zustand durch das Zusammensetzen dieser Ereignisse rekonstruiert werden kann.

Im Kontext des Online-Shop-Systems ermöglicht Event Sourcing die Nachverfolgung der gesamten Lagerhistorie. Dies bedeutet, dass alle Lagerbewegungen (wie Zugänge und Abgänge) vollständig und unverändert gespeichert werden, sodass der Zustand des Lagers zu jedem beliebigen Zeitpunkt in der Vergangenheit nachvollzogen werden kann.

Speichern der Ereignisse in einer Ereignislog

• Jedes Ereignis, wie eine Bestandsänderung, wird in einer Ereignislog gespeichert. Diese Log ist eine unveränderliche Aufzeichnung aller Ereignisse in der Reihenfolge ihres Auftretens.

  class Ereignis: def __init__(self, produkt_id, menge_aenderung, zeitstempel): self.produkt_id = produkt_id self.menge_aenderung = menge_aenderung self.zeitstempel = zeitstempel ereignislog = [] def speichere_ereignis(ereignis): ereignislog.append(ereignis) # Beispiel eines Ereignisses ereignis = Ereignis(produkt_id=123, menge_aenderung=50, zeitstempel='2023-10-02T10:00:00Z') speichere_ereignis(ereignis)

Einlesen und Replay der Ereignisse zur Rekonstruktion des Lagerzustands

• Um den Lagerbestand zu einem bestimmten Zeitpunkt zu rekonstruieren, liest man die Ereignislog ein und führt eine Replay der Ereignisse durch. Dabei werden die Ereignisse nacheinander angewandt, um den Bestand eines Produkts zu ermitteln.

def rekonstruieren_bestand(produkt_id, bis_zeitstempel): bestand = 0 for ereignis in ereignislog: if ereignis.produkt_id == produkt_id and ereignis.zeitstempel <= bis_zeitstempel: bestand += ereignis.menge_aenderung return bestand # Rekonstruktion des Bestands von Produkt 123 bis zu einem bestimmten Zeitstempel bestand_zu_zeitpunkt = rekonstruieren_bestand(produkt_id=123, bis_zeitstempel='2023-10-02T12:00:00Z')

Mathematische Beschreibung

• Gegeben sei eine Sequenz von n Ereignissen für ein bestimmtes Produkt. Jedes Ereignis i (von 1 bis n) habe eine Bestandsänderung \Delta_i und einen Zeitstempel t_i. Um den Lagerbestand eines bestimmten Produkts zu einem Zeitpunkt T zu bestimmen, summieren wir alle Bestandsänderungen der Ereignisse vor oder gleich T:
• \[ Bestand(T) = \sum_{i=1}^{n} \Delta_i \, \text{für alle Ereignisse mit} \, t_i \leq T \]
• Dabei ist \Delta_i die Bestandsänderung durch Ereignis i. Dies wird im Algorithmus durch eine Schleife realisiert, die die Ereignislog durchläuft und die Bestandsänderungen aufsummiert, solange der Zeitstempel des Ereignisses kleiner oder gleich T ist:

def berechne_bestand(sequenz_von_ereignissen, t): bestand = 0 for ereignis in sequenz_von_ereignissen: if ereignis.zeitstempel <= t: bestand += ereignis.menge_aenderung return bestand

Durch dieses Muster ist es möglich, den Zustand des Lagers zu einem beliebigen Zeitpunkt in der Vergangenheit zu rekonstruieren und somit eine vollständige historische Ansicht des Systems zu erhalten.

Aufgabe 3)

Du arbeitest als Systemarchitekt für ein großes verteiltes Datenbanksystem, das hohe Anforderungen an Konsistenz und Verfügbarkeit stellt. Deine Aufgabe ist es, sicherzustellen, dass Benutzer stets konsistente Daten erhalten, während gleichzeitig eine hohe Verfügbarkeit des Systems gewährleistet wird. Die Datenbank verwendet Quorum-Based Consistency, um Lese- und Schreiboperationen zu koordinieren.

Die Schlüsselbegriffe und Techniken, die Du in dieser Aufgabe berücksichtigen musst, sind:

• Konsistenzmodelle: Starke Konsistenz, Eventual Consistency, Weak Consistency
• Quorum-Based Consistency: Lese-/Schreib-Quoren (\text{R} + \text{W} > \text{N})
• CAP-Theorem: Trade-offs zwischen Konsistenz (C), Verfügbarkeit (A) und Partitionstoleranz (P)
• Synchronisationstechniken: Mutex (Mutual Exclusion), Lamport-Zeitstempel, Sequenznummern, verteilte Sperren
• Locking-Mechanismen: Pessimistisches Sperren, Optimistisches Sperren
• Ziel: Minimierung von Inkonsistenzen und Vermeidung von Race Conditions

a)

Teilaufgabe 1: Erläutere das CAP-Theorem und beschreibe, wie es auf ein verteiltes Datenbanksystem angewendet werden kann. Welche Kompromisse sind notwendig, um eine hohe Verfügbarkeit und Partitionstoleranz zu gewährleisten?

Lösung:

Teilaufgabe 1:

Das CAP-Theorem, auch als Brewer's Theorem bekannt, besagt, dass ein verteiltes Datenbanksystem nur zwei der folgenden drei Eigenschaften gleichzeitig vollständig erfüllen kann:

• Konsistenz (Consistency, C): Jeder Lesevorgang liefert die aktuellsten und vollständigsten Daten. Dies bedeutet, sobald ein Schreibvorgang abgeschlossen ist, werden alle nachfolgenden Leseoperationen die aktualisierten Daten widerspiegeln.
• Verfügbarkeit (Availability, A): Jeder Anfrage an das System erhält eine Antwort (Erfolg oder Fehlschlag) und das System ist jederzeit operativ.
• Partitionstoleranz (Partition Tolerance, P): Das System funktioniert auch dann weiter und verarbeitet Daten korrekt, wenn eine Kommunikationsunterbrechung zwischen den Knoten des Systems auftritt.

Das CAP-Theorem lässt sich mathematisch formulieren als:

 C + A + P = 2 

Das bedeutet, ein verteiltes Datenbanksystem kann nicht gleichzeitig vollständig konsistent und verfügbar sein, während es eine Partition in der Netzwerkkommunikation toleriert. Daher muss das System Kompromisse eingehen dependiendo auf den spezifischen Anforderungen und Anwendungsfall.

Auf ein verteiltes Datenbanksystem angewendet, bedeutet dies:

• Ein System, das Konsistenz und Verfügbarkeit priorisiert (CA-System): In einem solchen System wird die Partitionstoleranz ignoriert. Dies ist jedoch in den meisten praktischen Szenarien unrealistisch, da Netzwerkausfälle unvermeidlich sind.
• Ein System, das Konsistenz und Partitionstoleranz priorisiert (CP-System): Das System stellt sicher, dass Daten konsistent bleiben, auch bei Partitionen, kann aber in solchen Fällen die Verfügbarkeit beeinträchtigen, indem es möglicherweise keine Antworten auf Anfragen gibt.
• Ein System, das Verfügbarkeit und Partitionstoleranz priorisiert (AP-System): Beispielsweise die Eventual Consistency, bei der das System sicherstellt, dass es immer verfügbar ist und Partitionen toleriert, aber es kann eine gewisse Zeit dauern, bis alle Knoten die neuesten Daten widerspiegeln.

Um eine hohe Verfügbarkeit und Partitionstoleranz zu gewährleisten, werden in der Praxis häufig folgende Kompromisse gemacht:

• Eventual Consistency: In vielen verteilten Datenbanksystemen wird eine Form von Eventual Consistency verwendet, bei der das System letztendlich konsistent wird. Das bedeutet, dass alle Knoten im System irgendwann die gleichen Daten haben werden, aber es gibt möglicherweise eine Zeitspanne, in der unterschiedliche Knoten unterschiedliche Daten haben.
• Quorum-Based Consistency: Bei Lese- und Schreiboperationen wird ein Quorum-basiertes System verwendet, bei dem eine Operation als erfolgreich betrachtet wird, wenn eine bestimmte Anzahl von Knoten (Quorum) die Operation bestätigt. Dies ermöglicht eine gewisse Balance zwischen Konsistenz und Verfügbarkeit.

Zusammenfassend sind Kompromisse im CAP-Theorem unvermeidlich. Für ein hohes Maß an Verfügbarkeit und Partitionstoleranz muss die Konsistenz oft in einer Weise vernachlässigt werden, die entweder eventual oder schwache Konsistenz zulässt.

c)

Teilaufgabe 3: Diskutiere die Vor- und Nachteile von Mutex und Lamport-Zeitstempeln zur Vermeidung von Race Conditions in verteilten Systemen. In welchen Szenarien wäre eine der beiden Techniken der anderen vorzuziehen?

Lösung:

Teilaufgabe 3:

Race Conditions in verteilten Systemen können zu Inkonsistenzen und unvorhersehbarem Verhalten führen. Zwei verbreitete Techniken zur Vermeidung von Race Conditions sind Mutex und Lamport-Zeitstempel. Hier sind die Vor- und Nachteile beider Ansätze sowie Szenarien, in denen sie vorzuziehen sind:

• Mutex (Mutual Exclusion):

Vor- und Nachteile:

• Vorteile:
• Starke Konsistenz: Mutex stellt sicher, dass nur ein Knoten gleichzeitig auf eine kritische Ressource zugreifen kann, was Race Conditions verhindert.
• Einfache Implementierung: In kleineren Systemen oder bei wenigen kritischen Ressourcen ist Mutex leicht anzuwenden und zu implementieren.
• Deterministisches Verhalten: Da nur ein Prozess gleichzeitig zugreifen kann, ist das Verhalten vorhersehbar und reproduzierbar.
• Nachteile:
• Skalierbarkeit: Mutex-Mechanismen können in großen verteilten Systemen schwierig sein, da die Verwaltung der Sperren komplex wird.
• Leistungsengpass: Warten auf Freigabe von Sperren kann zu Verzögerungen führen und die Systemleistung beeinträchtigen.
• Deadlocks und Livelocks: Falsche Handhabung von Mutex kann zu Deadlocks (wo zwei oder mehr Prozesse aufeinander warten) oder Livelocks (wo Prozesse unnötig Ressourcen freigeben und erneut sperren) führen.

Szenarien, in denen Mutex vorzuziehen ist:

• Bei kleineren Systemen mit wenigen Knoten.
• In Umgebungen, in denen starke Konsistenz erforderlich ist und Determinismus von hoher Bedeutung ist.
• Für kritische Ressourcen, die nur selten und kurzzeitig gesperrt werden müssen.

• Lamport-Zeitstempel:

Vor- und Nachteile:

• Vorteile:
• Kein zentraler Sperrmechanismus: In einem verteilten System, in dem die Knoten unabhängig arbeiten, reduzieren Lamport-Zeitstempel den Bedarf an zentralen Koordinationsmechanismen.
• Vermeidung von Deadlocks: Durch das sequentielle Abzeichnen von Ereignissen vermeidet diese Methode Deadlocks.
• Bessere Skalierbarkeit: Lamport-Zeitstempel skalieren besser für große Systeme, da sie weniger Kommunikationsaufwand erfordern.
• Nachteile:
• Komplexität: Die Implementierung von Lamport-Zeitstempeln erfordert eine präzise Handhabung bei der Ereignisordnung und ist komplexer als Mutex.
• Konsistenzmodell: Diese Methode gewährleistet nicht automatisch starke Konsistenz, sondern kann unter Umständen verschiedene Versionen eines Zustands ermöglichen.
• Benötigt Synchronisation: Alle Knoten müssen korrekt die Zeitstempel verwalten und austauschen, was zusätzlichen Aufwand bedeutet.

Szenarien, in denen Lamport-Zeitstempel vorzuziehen sind:

• In großen, verteilten Systemen mit vielen Knoten.
• In Anwendungen, die eine geordnete, aber nicht unbedingt sofortige Konsistenz erfordern (z.B. Eventual Consistency).
• Wo Vermeidung von Deadlocks und Minimierung von Sperroperationen entscheidend sind.

Zusammenfassend lässt sich sagen, dass die Wahl zwischen Mutex und Lamport-Zeitstempeln stark von den spezifischen Anforderungen des Systems abhängt:

• Für kleinere Systeme und Szenarien, die starke Konsistenz und einfache Implementierbarkeit erfordern, ist Mutex vorzuziehen.
• Für größere, verteilte Systeme, die skalierbar und deadlock-frei bleiben sollen, sind Lamport-Zeitstempel besser geeignet.

d)

Teilaufgabe 4: Entwickle ein Szenario für ein verteiltes System, in dem eventuelle Konsistenz akzeptabel ist. Erkläre, welche Synchronisationstechniken und Locking-Mechanismen in diesem Szenario eingesetzt werden könnten, um die Gesamtleistung des Systems zu optimieren.

Lösung:

Teilaufgabe 4:

Ein Szenario für ein verteiltes System, in dem eventuelle Konsistenz akzeptabel ist, könnte ein global verteiltes soziales Netzwerk sein, bei dem Benutzer Beiträge erstellen, kommentieren und liken können. In einem solchen System wäre es nicht zwingend erforderlich, dass alle Knoten weltweit sofort konsistente Daten sehen, solange die Daten irgendwann konsistent werden.

Im Detail könnte das folgende Szenario betrachtet werden:

Szenario: Ein globales soziales Netzwerk

• Benutzer können weltweit Beiträge, Kommentare und Likes hinzufügen.
• Kurzfristige Inkonsistenzen (z.B. verzögerte Likes oder Kommentare) sind akzeptabel, solange diese Inkonsistenzen nach einer gewissen Zeit behoben werden.
• Das System muss hohe Verfügbarkeit und Partitionstoleranz sicherstellen, auch bei Netzwerkpartitionen und hoher Last.

Synchronisationstechniken:

• Lamport-Zeitstempel: Zur Ordnung von Ereignissen können Lamport-Zeitstempel verwendet werden. Diese Zeitstempel helfen dabei, eine logische Reihenfolge von Ereignissen zu erstellen, auch wenn die physischen Uhren der Knoten unterschiedlich sind.
• Vector Clocks: Vector Clocks können genutzt werden, um kausale Abhängigkeiten zwischen Ereignissen zu erkennen und Konflikte zu beheben.
• Gossip-Protokoll: Ein Gossip-Protokoll könnte eingesetzt werden, um Aktualisierungen zwischen den Knoten zu verbreiten. Dies verbessert die Eventual Consistency durch einen kontinuierlichen Austausch von Informationen.

Locking-Mechanismen:

• Optimistisches Sperren: Da Inkonsistenzen zulässig sind, kann optimistisches Sperren verwendet werden, um den Durchsatz zu maximieren und Lock-Contention zu vermeiden. Bei dieser Methode werden Änderungen zuerst lokal gemacht und dann zusammengeführt. Konflikte werden im nachhinein behandelt.
• Versionierung: Mit Hilfe von Versionierung können verschiedene Versionen desselben Datenelements verwaltet werden. Bei einem Schreibkonflikt kann das System entscheiden, welche Version die aktuellste ist oder die Änderungen zusammenführen.

Optimierung der Gesamtleistung:

• Reduzierung der Latenz: Durch den Einsatz von lokalen Caches und einer verteilten Architektur kann die Latenz minimiert werden.
• Lastverteilung: Load Balancers und Sharding-Techniken können verwendet werden, um die Anfragen gleichmäßig auf die Knoten zu verteilen und Hotspots zu vermeiden.
• Skalierbarkeit: Das Hinzufügen von Knoten kann die Skalierbarkeit des Systems erhöhen, indem Lasten verteilt und die Verfügbarkeit verbessert werden.

Zusammenfassend lässt sich sagen, dass in einem verteilten sozialen Netzwerk eventuelle Konsistenz akzeptabel ist und verschiedene Synchronisationstechniken wie Lamport-Zeitstempel und Gossip-Protokolle eingesetzt werden können, um die Konsistenz über die Zeit sicherzustellen. Locking-Mechanismen wie optimistisches Sperren und Versionierung erhöhen die Systemleistung und gewährleisten die Verfügbarkeit und Partitionstoleranz.

Aufgabe 4)

Betrachten Sie die Protokolle MQTT und AMQP, die häufig in ereignisgesteuerten Systemen für den Nachrichtenaustausch verwendet werden. MQTT ist ein leichtgewichtiges Protokoll für Machine-to-Machine (M2M) Kommunikation, das sich durch seine Nutzung einer Publish/Subscribe-Architektur sowie geringe Bandbreitennutzung auszeichnet. AMQP hingegen ist ein zuverlässiges, plattformunabhängiges Messaging-Protokoll, das einen Nachrichtenvermittler nutzt und Unterstützung für Queueing und Transaktionen bietet. Typische Anwendungen von MQTT finden sich im IoT-Bereich, während AMQP oft in Unternehmensanwendungen verwendet wird, die eine Garantie der Nachrichtenübertragung und -verteilung erfordern. Beide Protokolle bieten spezifische Vorteile wie effiziente Netzwerkressourcennutzung im Fall von MQTT und garantierte Nachrichtenübertragung bei AMQP.

a)

a) Erläutere den grundsätzlichen Unterschied zwischen der Publish/Subscribe-Architektur bei MQTT und dem Queueing-System bei AMQP anhand eines praktischen Beispiels aus dem IoT-Bereich.

Lösung:

• MQTT (Publish/Subscribe-Architektur):Stell Dir ein intelligentes Haus vor, in dem verschiedene Sensoren wie Temperatur-, Feuchtigkeits- und Bewegungssensoren zusammenarbeiten. Jeder Sensor veröffentlicht seine Daten an einen zentralen MQTT-Broker. Ein Thermostat könnte beispielsweise ein Abonnent (Subscriber) sein, der an den Temperaturdaten interessiert ist. Der Thermostat empfängt diese Daten vom Broker, sobald neue Daten veröffentlicht werden. Vorteilhaft hierbei ist, dass der Broker die Verteilung der Nachrichten effizient verwaltet, ohne dass die Sensoren direkt miteinander kommunizieren müssen.
• AMQP (Queueing-System):Ein praktisches Beispiel für AMQP könnte in einem Unternehmen zu finden sein, das ein IoT-System zur Überwachung und Verwaltung von Lagerräumen verwendet. In diesem Fall senden verschiedene Sensoren und Geräte ihre Statusinformationen und Warnmeldungen zu einem zentralen Nachrichtendienst, der eine Warteschlange (Queue) verwendet. Ein Lagerverwaltungssystem, das bestimmte Steuerungsaufgaben durchführt, entnimmt diese Nachrichten aus der Warteschlange und verarbeitet sie. AMQP stellt sicher, dass jede Nachricht zuverlässig übertragen und verarbeitet wird, und bietet zusätzlich Transaktionsunterstützung, um die Integrität der Daten zu gewährleisten.

b)

b) Gegeben sei ein IoT-Sensor, der Temperaturdaten an mehrere Abnehmer übermittelt. Diskutiere Vor- und Nachteile der Nutzung von MQTT im Vergleich zu AMQP in dieser Anwendung, insbesondere im Hinblick auf Netzwerkauslastung und Zuverlässigkeit.

Lösung:

• MQTT Vorteile: - Geringe Netzwerkauslastung: MQTT ist für die Nutzung von minimalen Bandbreiten optimiert, was besonders in Netzwerken mit eingeschränkter Kapazität von Vorteil ist, wie z.B. in mobilen Netzwerken oder weitreichenden IoT-Umgebungen. - Effiziente Datenübertragung: Das Protokoll durch seine Publish/Subscribe-Architektur ermöglicht eine effiziente Datenverteilung. Abnehmer (Subscribers), die an bestimmten Daten interessiert sind, erhalten nur diese spezifischen Daten; - Einfachheit der Implementierung: MQTT ist leichtgewichtig und daher einfacher und schneller zu implementieren.
• MQTT Nachteile: - Zuverlässigkeit: MQTT bietet weniger eingebaute Mechanismen zur Gewährleistung der Nachrichtenübertragung im Vergleich zu AMQP. Es gibt QoS-Level, aber sie sind nicht so robust wie die Mechanismen von AMQP. - Fehlende Transaktionsunterstützung: MQTT unterstützt keine komplexen Nachrichtenverarbeitungslogiken wie Transaktionen.
• AMQP Vorteile: - Hohe Zuverlässigkeit: AMQP bietet robuste Mechanismen zur Sicherstellung der Nachrichtenübertragung, was entscheidend ist, wenn kritische Daten verlustfrei übertragen werden müssen. - Unterstützung für Transaktionen: AMQP ermöglicht es, Nachrichten als Transaktionen zu behandeln, was die Integrität und Konsistenz der Daten gewährleistet. - Verteilte und komplexe Anwendungen: AMQP ist besser für komplexe, verteilte Anwendungen geeignet, bei denen Zuverlässigkeit und Nachrichtenverarbeitung garantiert sein müssen.
• AMQP Nachteile: - Höhere Netzwerkauslastung: Die zusätzlichen Funktionen und Zuverlässigkeitsmechanismen von AMQP führen zu einer höheren Netzwerklast im Vergleich zu MQTT. - Komplexität: Die Implementierung und Verwaltung von AMQP ist aufwändiger und erfordert mehr Ressourcen.

Fazit: Wenn die Netzwerkauslastung eine kritische Rolle spielt und die Nachrichtenübertragung nicht absolut zuverlässig sein muss, ist MQTT die bessere Wahl. Wenn jedoch Zuverlässigkeit und Datenintegrität im Vordergrund stehen und Netzwerkauslastung keine primäre Sorge ist, sollte AMQP bevorzugt werden.

c)

c) Berechne die theoretisch minimale Bandbreite in Kilobyte pro Sekunde (kB/s), die benötigt wird, um kontinuierlich Temperaturdaten von 1000 Sensoren zu übermitteln, wenn jeder Sensor einmal pro Sekunde Daten sendet und jede Nachricht 256 Byte groß ist. Beachte dabei sowohl die Protokolloverhead für MQTT und AMQP. Angenommen, der Overhead beträgt 10% der Nutzdaten.

Lösung:

Um die theoretisch minimale Bandbreite zu berechnen, die benötigt wird, um kontinuierlich Temperaturdaten von 1000 Sensoren zu übermitteln, müssen wir folgende Schritte durchführen:

• Nutzdaten berechnen: Jeder Sensor sendet 1 Nachricht pro Sekunde, die Nachrichtengröße beträgt 256 Bytes. - Total Anzahl der Nachrichten pro Sekunde: 1000 Nachrichten - Größe der Nutzdaten pro Sekunde: 1000 * 256 Bytes = 256000 Bytes (oder 256 kB)
• Protokolloverhead hinzufügen: Da der Overhead 10% der Nutzdaten beträgt, müssen wir diesen zur Gesamtdatenmenge hinzufügen. - Overhead pro Sekunde: 10% von 256.000 Bytes = 25600 Bytes (oder 25,6 kB) - Gesamtgröße inkl. Overhead: 256000 Bytes + 25600 Bytes = 281600 Bytes (oder 281,6 kB)
• Schlussfolgerung: Die notwendige Bandbreite für die Übertragung dieser Daten beträgt 281,6 kB/s.