Kritik mein Server-Design bitte

Question

Ich entwerfe einen Server in Java, die verwendet werden würde, um Anleihen zu handeln. Dieser Server fungiert als Vermittler zwischen der Client-Benutzeroberfläche und dem Analyse-Server. Der analytische Server ist das Gehirn, mein Server wird einfach mit ihm interagieren (mit tcp-Sockets) und die Antworten an den Client weiterleiten.

Der Server soll ~ 500 Clients gleichzeitig verarbeiten. Und es muss skalierbar und effizient sein, um ~ 500 Nachrichten pro Sekunde zu verarbeiten.

Der Fluss von Nachrichten zwischen dem Client UI und dem analytischen Server ist dies:

1. Client through the UI requests for price. 
2. My server accepts the message, formats it and then asynchronously 
    sends to the analytical server. 
3. When the response from the analytical server arrives, format and send 
    the response to the client UI. 
4. If the client likes the price, he/she will request to trade. 
5. Repeat steps 2 & 3. 

Es gibt einen bestehenden Rahmen, die ich Authentifizierung zur nutzen und Nachrichten zwischen meinem Server und dem Client UI zu senden. Ich habe das Messaging-Bit bereits zwischen meinem Server und dem analytischen Server codiert.

So weit wie den Rest meines Servers entwerfen, denke ich an 4 blockierende Warteschlangen. Wenn die Preisanfrage kommt, füge ich die Anfrage sofort in eine Warteschlange ein (Queue1). Ich habe dann einen Prozessor, der Nachrichten aus der Warteschlange 1 herausnimmt, formatiert und in eine andere Warteschlange stellt (Warteschlange2). Die Prozessorklasse enthält intern einen Threadpool (Executors.fixedThreadpool) und die Formatierung jeder Nachricht erfolgt in einem separaten Thread.

Ich habe dann eine Dispatcher-Klasse, die einen anderen Thread-Pool enthält. Diese Dispatcher-Klasse ist dafür verantwortlich, Nachrichten von Queue2 entgegenzunehmen und sie auf den Analytical-Server zu schreiben.

Wenn ich die Nachricht vom analytischen Server erhalte, füge ich sie in eine andere Warteschlange ein (Queue3). Ich habe einen anderen Thread-Pool, der die Nachricht aus der Warteschlange nimmt und formatiert und sie in eine andere einfügt (Queue4). Und schließlich habe ich einen anderen Thread-Pool mit Nachrichten aus Warteschlange4 und veröffentlicht auf dem Client.

Ich Grund, ich wählte 4 verschiedene Warteschlangen ist, denn wenn ich will, kann ich ein Werkzeug schreiben, um die Größe dieser Warteschlangen zu beobachten. Die Informationen über die Größe dieser Warteschlangen werden

1. Allow me to tune the size of the thread pools. 
2. Further, if needed, I can publish the messages contained in these queues 
    thus allowing me to monitor all the messages that flows through my server. 

Also was denkst du? Irgendwelche Ideen, Tipps sind herzlich willkommen.

Prost

Answer 1

Zuerst, wenn Sie sagen, dass Ihr Server ~ 500 Nachrichten pro Sekunde "behandeln" muss, was genau meinen Sie mit "handle"? Akzeptieren? Denn wenn Sie etwas anderes meinen, bin ich mir nicht sicher, wie nervös das ist, wenn der analytische Server asynchron ist.

Zweitens, ich denke, Sie haben 3 Warteschlangen zu viel :-) Sie benötigen eine Warteschlange, um als Sync-to-Async-Puffer zwischen Ihrem Server und dem analytischen Server zu fungieren. Darüber hinaus hat es wenig Sinn, etwas anderes anzuordnen (das hängt davon ab, wie genau Sie eine Antwort vom analytischen Server erhalten; wenn Sie aus irgendeinem Grund eine Abfrage durchführen, anstatt benachrichtigt zu werden, brauchen Sie die Warteschlange dort auch).

Answer 2

So klingt es wie Sie mit 500 Fäden am Ende dann, wenn es länger dauert als 1 Sekunde, um die Nachricht zu verarbeiten?

Answer 3

Welche Methoden stehen zur Verfügung, um Nachrichten vom Analyse-Server zurück an den Hauptserver zu senden (der sie dann an die Clients weiterleitet)?

• Abruf?
• Warteschlange? (was bedeuten würde, dass ein Thread auf dem Hauptserver die Warteschlange abfragen und Nachrichten an den Client senden muss?)
• Sonst noch etwas?

Answer 4

Dieses Design mit 4 Warteschlangen sieht ein wenig zu eng für mich entwickelt. Sie sollten anstelle dieser Warteschlangen ein Designmuster für die Verantwortungskette verwenden. Wenn Sie Netty mit seinen Encodern/Decodern und Handlern verwenden, würden Sie nicht alle diese Warteschlangen benötigen. Netty stellt auch einen speicherbewußten Thread-Pool-Executor zur Verfügung, der Ereignisse in einem anderen Thread verarbeiten kann, während die Speicherprüfung beibehalten wird.

Ihre Anforderung "Ich kann die Größe in den Warteschlangen überprüfen" ist verdächtig. Ein einfacher Logging-Mechanismus sollte funktionieren, um es geschickt zu machen, eine E-Mail an sich selbst zu senden, wenn die Warteschlangengrößen außer Kontrolle geraten. Dies signalisiert meist eine Situation, in der der Analyse-Server heruntergefahren ist usw. Ihre App wird sich also in einem schlechten Zustand befinden. Für die Haltbarkeit könnten Sie die eingehenden Daten in db speichern und speichern und im Falle eines Serverabsturzes wiederholen.