Ich suche eine Hochfrequenz-Skalierungslösung für SignalR. Ich frage mich, ob ich es mit Azure EventHub machen kann. Wenn ich EventHub als Backplane für SignalR-Nachrichten verwende, wird es für mich ein Engpass?
Ich habe diese Seite überprüft, aber es gibt nichts über EventHub, wie es ist ziemlich neu.
Ich kann nicht mit den genauen Einzelheiten von SignalR sprechen; Sie können jedoch EventHubs grundsätzlich für eine Rückwandplatine verwenden, müssen sich jedoch der Einschränkungen bewusst sein.
Das Backplane-Scaleout-Muster von SignalR geht davon aus, dass alle Server Zugriff auf alle Nachrichten haben und vermutlich alles verarbeiten werden. Dies bietet eine ziemlich klare Begrenzung dessen, was eine einzelne Rückwandplatine auf Standardhardware oder in der Cloud leisten kann. In einer typischen Cloud können Sie möglicherweise einen Datendurchsatz von 100 MB / s (schöne runde Zahl für 1 GB / s nic), oberes Ende der Standardhardware (und Azures HPC-Maschinen) 1000 MB / s (10 GBit / Sekunde nic) aufrechterhalten.
Die Frage ist also, ob Azure EventHubs Sie zu dieser architektonischen Begrenzung des Durchsatzes bringen können?
Die Antwort darauf ist einfach ja. 100 oder 1000 Partitionen bieten Ihnen einen ausreichenden Schreibdurchsatz und ausreichend Lesekapazität für 2 Server.
Die nächste Frage ist, wenn Sie nur 100MB / Sekunde in Ihrer Rückwandplatine pro Server lesen müssen, wie viele Server die Daten lesen können (dh wenn Sie 100MB / Sekunde von Aktienzellen senden, bei denen die Datengröße nicht zunimmt) Anzahl der Server).
Die Antwort hier ist, so viele Sie wollen, aber es gibt ein paar Tricks.
EventHubs wird skaliert, indem der Datenstrom partitioniert wird. Jede Partition hat einen maximalen Lesedurchsatz von 2 MB / s, der von allen Lesern gemeinsam genutzt wird. Sie können jedoch einfach die Anzahl der Partitionen multiplizieren, um die Aufteilung auszugleichen (das Hinzufügen von mehr als 32 erfordert das Gespräch mit Microsoft). Die Designannahme von EventHubs (wie Kafka und Kinesis) ist, dass der Verbrauch auf Maschinen aufgeteilt wird, wodurch die oben diskutierte Rückwandbegrenzung vermieden wird. Verbraucher, die zusammenarbeiten, um den Stream zu lesen, sind eine Consumer-Gruppe (Azure scheint eine benannte CG sogar für einen direkten Leser zu benötigen), in diesem Backplane-Modell gibt es keine logischen Verbrauchergruppen, also die Frage ist, wie man die Daten liest / p>
Die einfachste Lösung ist wahrscheinlich, den High-Level-Autoport-Ereignisprozessor-Host zu verwenden, wobei jeder Server seine eigene Consumer-Gruppe mit einem festen Namen ist. Mit nur einem Server in jeder Verbrauchergruppe erhält jeder Server alle Partitionen (500 für 10 Server erreichen 100 MB / Sekunde, aka 11.000 $ / Monat + 0,028 $ pro Million Ereignisse).
Dieser Ansatz hat eine wichtige Einschränkung: Sie sind auf 20 Kundengruppen pro Event-Hub beschränkt. So können Sie Event Hubs miteinander verketten oder einen Baum mit dieser Methode erstellen, um beliebige Zahlen zu erhalten.
Die andere Option besteht darin, direkte Clients zu verwenden, die eine Verbindung zu bestimmten Partitionen herstellen. Eine einzelne Partition in einer Consumer-Gruppe kann 5 Leser haben , wodurch weniger Bedarf besteht, Hubs zu verketten um einen Faktor von 5, wodurch die Kosten pro Ereignis um den Faktor 5 reduziert werden (verringert nicht die Durchsatzeinheitsanforderungen).
Zusammenfassend sollte es nicht zu einem Flaschenhals werden, bevor eine Rückwand zu einem Flaschenhals werden würde. Aber bauen Sie nicht etwas auf einer Rückwandplatine auf, wenn Sie erwarten, dass es im Datenverkehr 100 MB / Sekunde überschreitet.
Ich habe nicht über Latenz gesprochen, Sie müssen das selbst testen, aber die Chancen stehen gut, dass Sie nicht HFT in der Cloud machen und es gibt einen Grund, warum Echtzeit-Spiele typischerweise in Instanzen sind.
Tags und Links azure c# signalr azure-eventhub aspnet-websocket