Hallo liebe Gemeinde,
ich schreibe zur Zeit eine Studienarbeit und muss dazu ein bestehendes Microservice-System erweitern.
Das Microservice-System ist mittel Java Spring umgesetzt. In einem Service werden spezielle Nachrichten an Embedded Devices versendet. An welche Geräte konkret gesendet wird, entscheidet der Benutzer (eine einfache Liste an Geräten). Im System soll es ab jetzt dabei eine Vorgabe geben, sodass nicht alle Nachrichten gleichzeitig, sondern nur bestimmte Geräte in einer bestimmten Reihenfolge benachrichtigt werden (um eine Auslastung der Infrastruktur zu verhindern). Die Liste der abzuarbeitenden Geräte liegt in einer MongoDB.
Wird eine Nachricht gesendet, kommt eine Antwort "irgendwann" zurück, und wird vom System an den Service durchgeleitet. Bei einer zukünfitgen Skalierung des Systems kann es geschehen, dass diese Antwort von einer andere Instanz empfangen wird, als von derer, die die ursprüngliche Nachricht versendet hat.
Da nun nicht alle Nachrichten auf einmal gesendet werden dürfen, muss nach der intialien Auswahl auch regelmäßig nachgeprüft werden, ob wieder Nachrichten verschickt werden dürfen. Meine Idee ist diese: Kommt eine Antwort an, wird geprüft, welche Geräte eine Nachricht erhalten werden. Somit ist die Auslastung maximal.
Das generelle Problem, welches ich dabei habe: Kommen zwei Antworten an zwei Instanzen "gleichzeitig" an, würden beide ggf. das gleiche Gerät zweimal benachrichtigen (nicht erlaubt) oder zu viele Geräte benachrichtigen (würde ggf. zur Überlastung führen). Ich dachte nun also daran, dass sobald eine Antwort eintrifft, eine Transaktion zu starten (d.h. eine komplette Methode dabei auszuführen). Dort wird der Algorithmus abgearbeitet, und bei den Geräten, die benachrichtigt werden dürfen, ein SCHEDULED-flag zu setzen. Kommt fast-parallel dazu eine andere Anwort im System an, wird der Prozess durch die laufende Transaktion des anderen Prozesses blockiert. Sobald er arbeiten darf, sieht er, dass manche Geräte schon auf SCHEDULED stehen und überspringt diese: Es werden keine doppelten Nachrichten versendet, alles gut.
Das eigentliche Problem: Bei einer großen Anzahl an Geräten, könnte es sein, dass viele Antworten (auf einmal) kommen. Dann würden auf einmal z B. 100 Prozesse entstehen, die warten, bis sie weitermachen dürfen. Im worst-case würde sich die Anzahl immer weiter aufstauen, und eine unnötig große Anzahl von Prozessen erschaffen werden. Wären alle Nachrichten versendet, stünden dann trotzdem noch hunderte Prozesse und würden komplett durchlaufen, auch wenn eigentlich kein Bedarf mehr besteht, da die Liste schon abgearbeitet wurde. Im kleinen mag das vielleicht gehen, aber bei zehn- oder sogar hunderttausenden Geräten ist das sicher kein sinnvoller Ansatz.
Die Lösung, einfach abbzubrechen, falls schon ein anderer Prozess läuft, ist auch nicht verlässlich: Kommt die Antwort des vorletzten Gerätes rein, und es läuft ein Prozess, wird einfach abgebrochen. Da der schon laufende Prozess aber noch denkt, dass das vorletzte Gerät nicht fertig ist, wird das letzte Gerät von ihm nicht benachrichtigt; dann ist der Prozess fertig, und weil keine Antwort mehr kommt, wird das letzte Gerät niemals benachrichtigt.
Sicher könnte ich mir etwas mit verschiedenen weitere Status-Flags zusammenfrickeln - ich bin aber auf der Suche nach einer "richtigen" Lösung. Leider hatte ich bisher noch keine Vorlesung zum Concurrent Programming.
Hat jemand Ideen, Vorschläge oder Kritik? Ich suche keine fertige Lösung, sondern a) eine Bewertung meiner generellen Idee zur Lösung des Benachrichtigungshandling und b) eine Richtungsweisung um meine Probleme zu lösen (soweit sie nach a) noch relevant sind)
Liebe Grüße
ich schreibe zur Zeit eine Studienarbeit und muss dazu ein bestehendes Microservice-System erweitern.
Das Microservice-System ist mittel Java Spring umgesetzt. In einem Service werden spezielle Nachrichten an Embedded Devices versendet. An welche Geräte konkret gesendet wird, entscheidet der Benutzer (eine einfache Liste an Geräten). Im System soll es ab jetzt dabei eine Vorgabe geben, sodass nicht alle Nachrichten gleichzeitig, sondern nur bestimmte Geräte in einer bestimmten Reihenfolge benachrichtigt werden (um eine Auslastung der Infrastruktur zu verhindern). Die Liste der abzuarbeitenden Geräte liegt in einer MongoDB.
Wird eine Nachricht gesendet, kommt eine Antwort "irgendwann" zurück, und wird vom System an den Service durchgeleitet. Bei einer zukünfitgen Skalierung des Systems kann es geschehen, dass diese Antwort von einer andere Instanz empfangen wird, als von derer, die die ursprüngliche Nachricht versendet hat.
Da nun nicht alle Nachrichten auf einmal gesendet werden dürfen, muss nach der intialien Auswahl auch regelmäßig nachgeprüft werden, ob wieder Nachrichten verschickt werden dürfen. Meine Idee ist diese: Kommt eine Antwort an, wird geprüft, welche Geräte eine Nachricht erhalten werden. Somit ist die Auslastung maximal.
Das generelle Problem, welches ich dabei habe: Kommen zwei Antworten an zwei Instanzen "gleichzeitig" an, würden beide ggf. das gleiche Gerät zweimal benachrichtigen (nicht erlaubt) oder zu viele Geräte benachrichtigen (würde ggf. zur Überlastung führen). Ich dachte nun also daran, dass sobald eine Antwort eintrifft, eine Transaktion zu starten (d.h. eine komplette Methode dabei auszuführen). Dort wird der Algorithmus abgearbeitet, und bei den Geräten, die benachrichtigt werden dürfen, ein SCHEDULED-flag zu setzen. Kommt fast-parallel dazu eine andere Anwort im System an, wird der Prozess durch die laufende Transaktion des anderen Prozesses blockiert. Sobald er arbeiten darf, sieht er, dass manche Geräte schon auf SCHEDULED stehen und überspringt diese: Es werden keine doppelten Nachrichten versendet, alles gut.
Das eigentliche Problem: Bei einer großen Anzahl an Geräten, könnte es sein, dass viele Antworten (auf einmal) kommen. Dann würden auf einmal z B. 100 Prozesse entstehen, die warten, bis sie weitermachen dürfen. Im worst-case würde sich die Anzahl immer weiter aufstauen, und eine unnötig große Anzahl von Prozessen erschaffen werden. Wären alle Nachrichten versendet, stünden dann trotzdem noch hunderte Prozesse und würden komplett durchlaufen, auch wenn eigentlich kein Bedarf mehr besteht, da die Liste schon abgearbeitet wurde. Im kleinen mag das vielleicht gehen, aber bei zehn- oder sogar hunderttausenden Geräten ist das sicher kein sinnvoller Ansatz.
Die Lösung, einfach abbzubrechen, falls schon ein anderer Prozess läuft, ist auch nicht verlässlich: Kommt die Antwort des vorletzten Gerätes rein, und es läuft ein Prozess, wird einfach abgebrochen. Da der schon laufende Prozess aber noch denkt, dass das vorletzte Gerät nicht fertig ist, wird das letzte Gerät von ihm nicht benachrichtigt; dann ist der Prozess fertig, und weil keine Antwort mehr kommt, wird das letzte Gerät niemals benachrichtigt.
Sicher könnte ich mir etwas mit verschiedenen weitere Status-Flags zusammenfrickeln - ich bin aber auf der Suche nach einer "richtigen" Lösung. Leider hatte ich bisher noch keine Vorlesung zum Concurrent Programming.
Hat jemand Ideen, Vorschläge oder Kritik? Ich suche keine fertige Lösung, sondern a) eine Bewertung meiner generellen Idee zur Lösung des Benachrichtigungshandling und b) eine Richtungsweisung um meine Probleme zu lösen (soweit sie nach a) noch relevant sind)
Liebe Grüße