Frage

Ich erstelle eine Chat-Anwendung in Signalr.Derzeit verfügt es über einige Funktionen zum Speichern in einer Datenbank zur dauerhaften Speicherung von Nachrichten.Ich möchte Benutzerlisten implementieren und habe diesen Artikel noch einmal gelesen:

http://www.asp.net/signalr/overview/signalr-20/hubs-api/mapping-users-to-connections#inmemory

Wie groß ist dieser Unterschied zwischen In-Memory-Speicher?Gibt es wahrscheinlich einen Unterschied von mehr als einer Sekunde zwischen beispielsweise 1.000 Benutzern und 10.000 Benutzern, die sich gegenseitig Nachrichten mit einer normalen Rate von beispielsweise 1 Nachricht pro Sekunde senden (sie hatten viel Zucker)?Und wie nützlich ist es?Hinweise auf frühere Leistungstests wären sehr willkommen.

Zweitens mache ich das vielleicht falsch, aber wenn ich eine Liste von Benutzern speichern möchte und es mehrere Chatrooms gibt, gehe ich davon aus, dass ich für jeden Chatroom ein separates Wörterbuch benötige?Und wenn ja, ist das machbar, da ich möchte, dass Benutzer auch ihre eigenen Räume erstellen können?Ich verstehe einfach nicht, wie In-Memory auf diese Weise erreicht werden kann.

Danke

War es hilfreich?

Lösung

Ich hasse es, einen einzigen Link für eine Antwort bereitzustellen, aber dieser OSS-Chatroom ist voll funktionsfähig https://jabbr.net befasst sich mit allem, worüber Sie sich Sorgen machen.

Quelle: https://github.com/jabbr/jabbr

Um zu Ihrem Hauptanliegen In-Memory vs. DB zu kommentieren:DB bietet die Möglichkeit, Daten beizubehalten oder Ihre Anwendung sogar zu skalieren, ist ABER WEITWEIT weniger leistungsfähig als In-Memory.Verstehen Sie mich jetzt nicht falsch, auch wenn es VIEL weniger leistungsfähig ist, bedeutet das nicht, dass das Senden von Nachrichten abhängig von Ihrer App Sekunden dauert ...Es geht nur um Kompromisse.

Bei der Anwendung einer DB-orientierten Architektur auf 1.000 oder 10.000 Benutzer hängt alles davon ab, wie Sie sie implementieren.Beispielsweise führt der Scale-out-Anbieter REDIS alles im Arbeitsspeicher aus, verbleibt dann aber in bestimmten Abständen auf der Festplatte.Dies ist natürlich extrem schnell, lässt aber „einen gewissen“ Datenverlust zu.

Andere Tipps

Dies steht nicht in direktem Zusammenhang mit Ihrer ursprünglichen Frage.

Ich denke, man kann sie nicht im In-Memory-Speicher speichern. Das Problem besteht darin, dass beim Recycling des Anwendungspools alle im Speicher gespeicherten Nachrichten verloren gehen.

Sie können nicht vorhersagen, wann App Pool wiederverwendet wird (insgesamt können Sie manuell einen bestimmten Zeitpunkt für die Wiederverwertung festlegen).Es kann entweder in wenigen Tagen oder in wenigen Stunden passieren.

Idealerweise möchten Sie an einem dauerhaften Ort speichern, z Datenbank.Wenn Sie sich Sorgen über die Leistung des Speicherns in der Datenbank machen, können Sie dies tun asynchron die Aufgabe zum Speichern der Datenbank.

Schauen Sie sich diesen Vergleich an:

http://ruturaj.net/redis-memcached-tokyo-tyrant-and-mysql-comparision/

Redis (im Gedächtnis) übertrifft MySQL (klassischer DB) Offensichtlich sind ihre Anwendungsfelder stark unterschiedlich, daher können wir nicht sagen, dass Redis besser ist als MySQL.Jedes Softwareprojekt ist eine eigene Welt und viele verschiedene Lösungen können angewendet werden.In manchen Situationen werden Redis und MySQL zusammen für verschiedene Teile einer Plattform verwendet (z. B.Magento-E-Commerce)

Es liegt an Ihnen zu beurteilen, ob Sie eine In-Memory-Lösung oder eine Standarddatenbank benötigen.Ich denke, dass mit MySQL problemlos ein Durchsatz von 1 Einfügung/Sekunde erreicht werden kann, aber das ist nur eine Meinung.Ich empfehle Ihnen, eine Implementierung Ihres Produkts zu schreiben, die „Redis-fähig“ ist:Beginnen Sie mit der Verwendung von MySQL, verwenden Sie es jedoch über eine Abstraktionsschicht, die sich sowohl an MySQL als auch an Redis anpasst (ich weiß nicht, ob eine solche Schicht als Open Source verfügbar ist, aber Sie können Ihre eigene veröffentlichen ...)

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top