Nachrichten für mehr als 10.000 Rechner im Netzwerk - Welche Technik verwenden?

[TheMiller]

Es kommt auf Plattform an, würde ich sagen.

Generell würde ich diese Aufgabe von einem MessageBroker / MessageQuere erledigen lassen. Nutzt ihr alle ausschließlich Windows, dann der Einfachheit halber Microsoft Message Queue Server. Der ist beim Windows-Server dabei, muss nur aktiviert werden.

Nutzt ihr verschiedene Betriebssysteme oder sogar Mobile-Clients, dann über eine Webseite mit Websockets. Dort läuft dann ein Websocket-Router oder Server zB Crossbar.io oder Node.js etc.pp. Mit Crossbar kannst du den Socket in jeder Sprache schreiben (naja, fast jeder) und dennoch Clients aller Art bedienen. Die Architektur dahinter ist allerdings sehr umfangreich - ich habe das gerade selbst umgesetzt.

Also, Windows = MSMQ
PHP = RatchetPHP, Thruway, Crossbar.io
JS = Node.js

AUf der Serverseite fragt eine Verbindung nach neuen Daten, alle Clients registrieren sich in der Queue und werden bei neuen Daten benachrichtigt, bzw. die Daten werden gleich mitgeschickt.

Ich hoffe, ich konnte auf die Schnelle ein wenig helfen.

[Valle]

Klar ist schonmal, dass jede Minute die Datnebank zu pollen, definitiv nicht die beste Möglichkeit ist.

Technisch am besten dafür geeignet wäre im Prinzip eine Multicast Nachricht. Jeder der teilnehmenden Rechner schreibt sich in die entsprechende Multicast Gruppe ein und der Server sendet eine Multicast Nachricht an diese Gruppe, sobald ein bestimmtes Event eingetreten ist. Die richtige Hardware vorausgesetzt bekommt so jeder der 10.000 PCs gleichzeitig seine Nachricht und die benötigte Bandbreite könnte geringer gar nicht sein.

Leider ist das nicht immer eine mögliche Option. Billige Switches spielen da nicht mit, der Konfigurationsaufwand ist nicht zu unterschätzen und über das Internet funktioniert diese Technik nicht. :-/

Auf jeden Fall würde ich zur Lastreduzierung vom Polling wegkommen und stattdessen ein zentrales Prinzip einführen. Die erwähnten WebSockets sind in der Tat eine Option, allerdings solltest du die Technologie verwenden, mit der du am besten vertraut bist. Wenn deine Anwendung mit Web nichts zutun hat und du auch mit node.js und Konsorten nicht vertraut bist, sehe ich wenig Sinn dahinter, den gesamte Overhead dieser Technologie mitzunehmen.

Stattdessen würde ich dann eher herkömmlichen TCP-Verbindung zurückgreifen. Du musst bei der Implementierung darauf achten, dass 10.000 Verbindungen ziemlich viele sind. Das bedeutet für dich, dass du bei der Implementierung schauen müsstest, dass du nicht 10k Threads oder gar 10k Prozesse startest. Stattdessen würde wenige Threads zur Abarbeitung aller Verbindungen ja genügen.

[himitsu]

Wenn er selber was mit TCP macht, warum dann nicht besser ein Netz, anstatt einem Stern?

Entweder mehrere Server (PCs+Programm) oder die Clients bauen untereinander Verbindungen auf.
Diese 10.000 Rechner werden ja nicht alle im selben (lokalen) Netz hängen, also da eher über die Welt verstreute Server und mmer mit dem "nächsten" verbinden, oder in den verschiedenen lokalen Netzen sprechen sich die Clients ab, wobei sich dann einer/mehrere auch als "Server" bereit stellen, über den die Anderen mit dem Server rden, bzw. von denen sie die Multicastnachrichten bekommen.

Quasi wie bei vielen FileSharingDiensten ala Torrent.

[jobo]

Als Ergänzung zur Problematik:
Wenn eine schlanke Massenbenachrichtigung per Push realisiert ist, musst Du auch mit der Reaktion klarkommen.
Wenn vormals hunderte oder 2-tausende Rechner mit dem minütlichen Pollen wahrscheinlich eine rauschartige, hohe Grundlast auf dem Server produziert haben, könnte es nun mit pünktlichem Push an 10000 Systeme und anschließender DB Anfrage zu einer schlagartigen Überlast führen. Dabei kommt es auch darauf an, wie zielgenau bzw. ereignisspezifisch die Nachrichten verschickt werden, also an wieviele Clients /Gruppen.
"An alle: Es gibt neue Daten" ist weniger hilfreich als "An Etage 2, Nordtrakt: Neuer Drucker verfügbar"

[TheMiller]

Deswegen würde ich eine MessageQueue empfehlen, bei der sich die Clients registrieren und bei einem Event gleich die Nachrichten übermittelt bekommen. So sind die Daten gleich verfügbar. Oder man sendet in die Nachricht einen timestamp mit, wann sich der Client X mit dem Server verbinden und die Daten laden soll. (Die ersten 500 sofort, die nächsten 500 in sofort+x Sekunden, etc.pp).

Als MessageQueue kann ja der MS-Server (MSMQ) benutzt werden. Schnelle, saubere, skalierbare Lösung.

[TERWI]

Quizfrage wäre noch vielleicht:
Sitzen diese 2000 (-1000) alle im gleichen Adress-Bereich ?

Polling von jedem Rechner wäre wohl die eher dümmste Idee ...
(... was ein unsinniger Traffic am Server ....)

Jeweils ein Multicast bei neuen Info's an alle mit speziellen Daten WEN WAS betrifft.
Die "Lauscher" sollten logo schon auf entsprechende Daten hören / diese auswerten.

Falls es mehrere Empfänger gleichzeitig betrifft, könnten die dann ja explizit beim Server noch mal nachfragen (hier dann im Polling), ob z.B. die Info schon abgearbeitet wurde oder noch relevant ist.

Nach dem Motto: Ich bin frei, gib her, brauch sich keiner weiter kümmern.

Typische CallCenter-Anwendung ?!

[Mavarik]

Pollen ist sicherlich die schlechteste Variante...

UDP Broadcast sicherlich die schlankeste...

Dann eher eine Restservice als das jeder Client seine eigene Datenbankverbindung aufbaut...

Mavarik