Und die bekommen die Daten dann einfach per Post-Request oder so geschickt?Das Empfängersystem ist nicht unter unserer Kontrolle, daher gibts welche die können wir zuballern und andere muss man vorsichtig sein
Das wäre sinnvoll, wobei „Map“ dann ein beliebiges Etwas sein kann, das irgendwie Key-Value-Paare speichern kann da geht ja alles vom fetten SQL-Server über den schlanken Key-Value-Store bis zur nur im Arbeitsspeicher liegenden Map.Vielleicht könnte man im Herstellerservice eine Map vorhalten mit <sku,bestand> und beim einlesen mit der map abgleichen obs ne Änderung gabe, dann spart man sich das senden der unötigen Messages
Ist es schlimm, wenn im Fehlerfall dann zwei mal ein „Preis geändert auf 10“ kommt?Eine Map gefällt mir spontan schon mal, aber wenn der Hersteller Service down war, muss die Map erstmal wieder initialisiert werden.
Warum schwer? Einfach ein weitere Service, der das entsprechende Event mitbekommt, der Rest des Systems ist davon ja unabhängigJetzt kam aber noch eine Anforderung dazu Die Bestände, Preise wo sich geändert haben, sollen abgespeichert werden damit daraus Statistiken generiert werden können und man nachverfolgen kann, welche Änderungen sich wann ergeben haben. Oh man es wird nicht einfacher
Naja, du gruppierst durch die Queue/Topic. (Wobei ich satt pro Hersteller eine eher pro User eine wählen würde.Versuch grad in das Thema Topic/Queue einzusteigen. Kann man die Messages irgendwie gruppieren?
Wenn ich 3 Hersteller Queries habe und jeweils 5 Nutzer, dann habe ich da im schlimmsten Fall 10.000 x 5 Messages. Da kann man ja kaum was debuggen. Zb welcher User evtl hängen geblieben ist oder so
Jeder Herstellerservice speichert einfach die Artikel-Rohdaten, nach außen gibt er dann einfach nur noch Änderungen bzw Löschungen. Also deine Variante mit Map, nur dass das ganze persistent sein muss.Hab da noch was :/ Es muss zwingend mit jedem "Rundlauf" geprüft werden ob ein Ersatzteil überhaupt noch in der CSV/TXT vorhanden ist. Manche Hersteller nehmen einfach Artikel aus dem Sortiment ohne zu informieren. Aktuell haben wir es so:
Das wäre auch die Variante, die ich beim lesen der Anforderungen bevorzugen würde. Den irgendeiner muss ja den Abgleich machen. Und das sieht - bei der Datenmenge - nicht so aus, als würde man das zentral machen wollen.Jeder Herstellerservice speichert einfach die Artikel-Rohdaten, nach außen gibt er dann einfach nur noch Änderungen bzw Löschungen. Also deine Variante mit Map, nur dass das ganze persistent sein muss.
Naja, du gruppierst durch die Queue/Topic. (Wobei ich satt pro Hersteller eine eher pro User eine wählen würde.
So wie ich in verstanden habe, werden die Daten eines Herstellers spezifisch für einen konkreten Nutzer abgefragt, Artikel 1 kann also für Nutzer 1 Preis 5 haben, für Nutzer 2 aber Preis 6:Wenn mehrere User den gleichen Hersteller abonnieren werden duplizierte Daten verschickt.
D.h. Artikel 1-10 von Hersteller A kommt in fünf Topics (für User 1-5), Artikel 1-10 von Hersteller B kommen in fünf Topics für User 1,2,7,8,10,...
Sonst würden Artikel 1-10 von Hersteller A in ein Topic kommen und User 1-5 lesen diesen Topic, Hersteller B kommt in ein Topic und User 1,2,7,8 und 10 lesen diese Topics.
Jupp genau, pro Kunde wird beim Hersteller angefragt, da jeder andere Preise haben könnte usw.
Bastle sowas nicht selber, sondern nehm ne passende Datenbank dafürWie wäre es, wenn ich die Rohdaten je als object auf die platte speichere und das beim Import abgleiche Mit equals. Wenn der Bestand des neuen Objekts dann anders ist, sollte equals doch false geben und ich weiss, was sich geändert hat und sende das object an den Broker und speichere die neue Version auf die SSD.
gibt zwar viele files aber ist simpel
ich nutze Lombock mit @Data das erstellt ja immer die aktuellste hash und equals methode, sollte eigentlich klappen. Hab noch nie objekte verglichen 😅
Jupp genau, pro Kunde wird beim Hersteller angefragt, da jeder andere Preise haben könnte usw.
Jupp genau, pro Kunde wird beim Hersteller angefragt, da jeder andere Preise haben könnte usw.
eine richtige DB fällt mE aus, wenn ich den Service auf einen anderen Server ziehen muss, ist es relativ aufwändig da die DB aufzusetzen. Mit meiner Serialisierungsvariante wäre das schneller erledigt.Bastle sowas nicht selber, sondern nehm ne passende Datenbank dafür
DB hat man mit passendem Tooling mit einer einzigen Aktion aufgesetzt wenn das Umziehen einer DB Deutlich mehr Aufwand als das umziehen von zig Dateien ist, macht man irgendwas falsch.eine richtige DB fällt mE aus, wenn ich den Service auf einen anderen Server ziehen muss, ist es relativ aufwändig da die DB aufzusetzen. Mit meiner Serialisierungsvariante wäre das schneller erledigt.
Der Service würde einfach die Struktur im Dateisystem bei nem Import auf dem neuen Server wieder anlegen und fertig
Eine Mischung aus beidem, auf Consumer-Seite wird üblicherweise ein Thread-Pool genutzt, wenn grad kein Thread frei ist, wird auch keine neue Message verarbeitet.Was ich mich noch frage ist, wie die Queries abgearbeitet werden. Der Listener merkt das eine Message in den Queue eingestellt wurde und holt sie ab. Wenn nun 100.000 Messages rein gehen, wie reagiert der Listener? Macht der alle nacheinander oder wie ich es unter asynchron verstehe, parallel? Der macht doch dann aber nicht 100.000 Threads auf?! Wie kann ich mir das vorstellen?
Ich frage deshalb weil es vorkommen kann, dass 100.000 Messages eingestellt werden mit dem Hinweis auf Betandsänderung. Dann würden 100.000 UPDATE Queries auf die DB gehen. Das wäre bisschen viel schätz ich.
Ok danke. Ist der von Haus aus da oder muss ich einen erstellen 🤓 laut Google gibt es die Möglichkeit einen zu erstellen, das werd ich wohl machen um die Anzahl threads unter Kontrolle zu habenEine Mischung aus beidem, auf Consumer-Seite wird üblicherweise ein Thread-Pool genutzt, wenn grad kein Thread frei ist, wird auch keine neue Message verarbeitet.
Du nutzt Spring, oder? Von Haus aus ist immer einer da, ein eigener ist aber sinnvoller.Ok danke. Ist der von Haus aus da oder muss ich einen erstellen 🤓 laut Google gibt es die Möglichkeit einen zu erstellen, das werd ich wohl machen um die Anzahl threads unter Kontrolle zu haben
Hatten wir das nicht vor kurzem???? 😁😁😁 https://www.java-forum.org/thema/verstaendnisfrage-dto-spring-boot.188551/#post-1224383 Thompsen doch für den Anfang einen guten Einstieg, oder was fehlt dir?genau spring boot. Hmm find da iwie nix gescheites zu. Ist das n Taskexecutor und der sendet das in seiner Methode oder?
Das Kapitel über JMS seperat ja, auf JMS geht er aber ab der Lektion 90 (von über 500) ein. Und wie ich in dem anderen Thread schon geschrieben habe ist der Titel: "Vom Anfänger zum Guru" leicht übertrieben. Aber für den ersten Einstieg bis Fortgeschrittenen ist der Kurs schon sehr gut.Ja, JMS kommt vor, relativ weit hinten. (Mit "Building a Spring Boot Web-App" hat das allerdings nichts zu tun )
Er hatte aber geschrieben, er findet nichts zu Spring Boot.
taskExecutor.execute(() -> {
jmsTemplate.convertAndSend(JmsConfig.IMPORT_QUEUE, productImportDto);
});
spring.activemq.user=nico
spring.activemq.password=nico
spring.activemq.pool.enabled=true
spring.activemq.pool.max-connections=1000
spring.activemq.broker-url=tcp://localhost:61616
Ist denn nur der Preis unterschiedlich, oder noch mehr? Man könnte ja eine Tabelle mit Artikelstammdaten haben und weitere Tabellen mit pro Kunde variablen Daten. Ungefähr folgende Tabellen:Das dumme daran ist dann natürlich, dass die Daten 100 fach vorkommen würden. (Wäre in mapdb auch ) Also Artikel 12345 wäre für 10 User, 10 mal in der Tabell. Evtl 10 x identisch, evtl auch 10 mal mit je verschiedenem Preis.
Welche Daten können denn vom Kunden abhängen, nur der Preis oder auch anderes?Das dumme daran ist dann natürlich, dass die Daten 100 fach vorkommen würden. (Wäre in mapdb auch ) Also Artikel 12345 wäre für 10 User, 10 mal in der Tabell. Evtl 10 x identisch, evtl auch 10 mal mit je verschiedenem Preis.
Nur weil du einen Schritt weit gehst, musst du ja nicht gleich den Marathon laufenWenn ich das so mache, könnte ich auch gleich die Daten in die jeweilige tenante DB schreiben, was aber wiederrum bedeuten würde ich müsste die Logiken (Preis berechnen, Stati setzen usw) in den Hersteller Service einbauen. Wenn ich dann was ändere muss ich das bei jedem Hersteller.
Das wäre wieder die „selber basteln“ Variante, stattdessen einfach die Datenbank nehmen dürfte sinnvoller sein (in Hinblick auf ACID etc), es muss ja keine Relationale Datenbank sein.Ich könnte auch einfach wie folgt vorgehen:
Erster Import legt ne Map an Map<sku,product> und speichert die lokal als Datei.
Dann dürften die Daten direkt schon in 4. (BC? 5.?) Normalform vorliegen.Die Daten können verschieden sein Bilderlinks können fehlen, Preise anders, Beschreibungen können abweichen.
400k Zeilen dürften kein Problem sein.Wenn wir den aktuellen Hersteller nehmen mit 40k Datensätzen, wären wir bei 100 Kunden bei 400k Einträgen in der Tabelle. Mit solchen Daten hab ich noch keine Erfahrung gemacht. Ist das viel? Keine Ahnung
Datenbank und Service laufen auf unterschiedlichen Systemen und müssen übers Netzwerk kommunizieren?Jo das läuft. Lokale DB 40k Teile in 30 Sekunden mit save all und batch.
Allerdings gehts auf dem Liverserver mal wieder nicht so schnell. Da ist doch garantiert wieder irgenwas falsch konfiguriert :/
Titel | Forum | Antworten | Datum | |
---|---|---|---|---|
Strukturplanug Klappe die 2. Microservices zu ModulMonolith | Application Tier | 24 |