Zuerst müssen Sie definieren, was INSTANT für Sie bedeutet. Für einige bedeutet es innerhalb einer Sekunde 90% der Zeit. Für andere wären sie glücklich, im Durchschnitt eine Lücke von 10-20 Sekunden zu haben. Und noch wichtiger: Sie müssen die Auswirkungen Ihrer Anforderungen verstehen. Mit anderen Worten, lohnt es sich, für Ihr Geschäft eine Wartezeit von fast Null zu haben? Je entspannter Ihre Anforderungen sind, desto günstiger wird es gebaut und desto einfacher wird es zu warten.
Sie sollten wissen, dass eine zeitnahe Benachrichtigung sehr teuer sein kann, wenn es um das Berechnen und Sperren von Ressourcen geht. Je mehr Sie aktualisieren, desto mehr Web-Roundtrips werden benötigt (auch wenn sie in diesem Fall minimal sind). Daten, die auf den zweiten Stand gebracht werden, können auch für die Datenbank kostspielig sein, weil Sie möglicherweise eine große Menge an Anfragen erstellen, was wiederum die ansonsten guten Anfragen beeinträchtigen könnte. Wenn Ihre Website beispielsweise mit 1000 angemeldeten Benutzern ausgeführt wird, benötigen Sie möglicherweise 1000 Datenbankanforderungen pro Sekunde (unter der Annahme, dass dies Ihre Definition von INSTANT ist), was wiederum zu einer Einschränkungsbedingung in SQL Azure führen kann, wenn sie nicht ordnungsgemäß erstellt wird.
Ein Ansatz, den ich in der Vergangenheit für eine ähnliche Anforderung verwendet habe (obwohl die Genauigkeit nicht auf die Sekunde, mehr wie auf die Minute) war, alle Datensätze aus einer Tabelle im lokalen Cache der lokalen Website zu laden. Ein Hintergrundthread sperrte und aktualisierte die Daten im Speicher für alle Datensätze in einer Aufnahme. Dadurch konnten wir den Datenbankverkehr um den Faktor tausend reduzieren, da die Daten auf dem Bildschirm aus dem lokalen Cache stammten und eine einzelne Datenbankverbindung benötigt wurde, um den Cache zu aktualisieren (pro Webserver). Da wir mehrere Webserver hatten und die Daten auf allen Webservern innerhalb einer Sekunde identisch sein mussten, haben wir die Anforderungen aller Webserver synchronisiert, um den Cache jede Minute zu aktualisieren. Dies zusammen zu bringen dauerte viele Stunden, aber es ermöglichte uns, ein System zu entwickeln, das hoch skalierbar war.
Die obige Technik funktioniert möglicherweise nicht für Ihre Anforderungen, aber mein Punkt ist, je höher der Bedarf an frischen Daten ist, desto mehr Design/Engineering-Arbeit müssen Sie sicherstellen, dass Ihr System nicht zu sehr von der Frischeanforderung betroffen ist .
Hoffe, das hilft.
vielen Dank für das Teilen dieses Wissens. Ich weiß, dass das ziemlich teuer sein wird; aber lassen Sie uns sagen, dass das Geschäftsbeispiel eher eine hypothetische Situation war. Stellen Sie sich vor, dass diese ein Muss als Voraussetzung sein müssen. Mit INSTANT meine ich, dass sobald eine Änderung in die Datenbank eingefügt wird, der betreffende Benutzer sofort benachrichtigt wird. Ich habe gehört, über Abfragen und Push-SQL-Cache-Abhängigkeiten, (siehe Teil 2) – test
, aber aus dem, was wir gesucht haben; Diese können nicht in SQL Azure-Datenbanken implementiert werden. also suchen wir nach einem anderen Mechanismus; Dieselbe Art von Mechanismus wie die PUSH-Benachrichtigung für mobile Apps, bei der nach dem Einfügen einer Benachrichtigung sofort eine Nachricht an das Telefon gesendet wird. Jetzt möchte ich das im Web anwenden. Vielen Dank für Ihre Zeit und Geduld! – test