Ich habe eine Webseite, auf der eine große Datenmenge vom Server angezeigt wird. Die Kommunikation erfolgt über Ajax.

Jedes Mal, wenn der Benutzer mit diesen Daten interagiert und sie ändert (sagen wir, Benutzer A benennt etwas um), weist er den Server an, die Aktion auszuführen, und der Server gibt die neuen geänderten Daten zurück.

Wenn Benutzer B gleichzeitig auf die Seite zugreift und ein neues Datenobjekt erstellt, teilt er dies dem Server erneut über Ajax mit, und der Server kehrt mit dem neuen Objekt für den Benutzer zurück.

Auf der Seite von A haben wir die Daten mit einem umbenannten Objekt. Und auf B's ​​Seite haben wir die Daten mit einem neuen Objekt. Auf dem Server haben die Daten sowohl ein umbenanntes als auch ein neues Objekt.

Welche Möglichkeiten habe ich, um die Seite mit dem Server synchron zu halten, wenn mehrere Benutzer sie gleichzeitig verwenden?

Optionen wie das Sperren der gesamten Seite oder das Speichern des gesamten Status für den Benutzer bei jeder Änderung werden eher vermieden.

Wenn dies hilfreich ist, ruft die Webseite in diesem speziellen Beispiel eine statische Webmethode auf, die eine gespeicherte Prozedur in der Datenbank ausführt. Die gespeicherte Prozedur gibt alle geänderten Daten zurück und nicht mehr. Die statische Webmethode leitet dann die Rückgabe der gespeicherten Prozedur an den Client weiter.

Bounty Edit:

Wie entwerfen Sie eine Mehrbenutzer-Webanwendung, die Ajax für die Kommunikation mit dem Server verwendet, jedoch Probleme mit der Parallelität vermeidet?

Dh gleichzeitiger Zugriff auf Funktionen und Daten in einer Datenbank ohne das Risiko von Daten oder Statusbeschädigungen

Überblick:

• Intro
• Serverarchitektur
• Client-Architektur
• Fall aktualisieren
• Fall festschreiben
• Konfliktfall
• Leistung und Skalierbarkeit

Hallo Raynos,

Ich werde hier kein bestimmtes Produkt diskutieren. Was andere erwähnt haben, ist ein gutes Toolset, das Sie sich bereits ansehen sollten (fügen Sie möglicherweise node.js zu dieser Liste hinzu).

Aus architektonischer Sicht scheinen Sie das gleiche Problem zu haben, das in der Versionskontrollsoftware auftritt. Ein Benutzer checkt eine Änderung an einem Objekt ein, ein anderer Benutzer möchte dasselbe Objekt auf andere Weise ändern => Konflikt. Sie müssen Benutzeränderungen an Objekten integrieren und gleichzeitig in der Lage sein, Aktualisierungen zeitnah und effizient bereitzustellen und Konflikte wie die oben genannten zu erkennen und zu lösen.

Wenn ich in deinen Schuhen stecke, würde ich so etwas entwickeln:

1. Serverseitig:

• Bestimmen Sie eine vernünftige Ebene, auf der Sie definieren würden, was ich als "atomare Artefakte" bezeichnen würde (die Seite? Objekte auf der Seite? Werte in Objekten?). Dies hängt von Ihren Webservern, Ihrer Datenbank- und Caching-Hardware, der Anzahl der Benutzer, der Anzahl der Objekte usw. ab. Dies ist keine einfache Entscheidung.

• Für jedes atomare Artefakt gilt:

  • eine anwendungsweite eindeutige ID
  • eine inkrementierende Versions-ID
  • ein Sperrmechanismus für den Schreibzugriff (Mutex vielleicht)
  • eine kleine Historie oder ein "Changelog" in einem Ringpuffer (Shared Memory funktioniert gut für diese). Ein einzelnes Schlüssel-Wert-Paar ist möglicherweise ebenfalls in Ordnung, jedoch weniger erweiterbar. Siehe http://en.wikipedia.org/wiki/Circular_buffer

• Ein Server oder eine Pseudo-Server-Komponente, die in der Lage ist, relevante Änderungsprotokolle effizient an einen verbundenen Benutzer zu senden. Observer-Pattern ist dein Freund dafür.

2. Client-Seite:

• Ein Javascript-Client, der eine langjährige HTTP-Verbindung zu dem oben genannten Server herstellen kann oder Lightweight Polling verwendet.

• Eine Javascript-Artefakt-Updater-Komponente, die den Inhalt der Site aktualisiert, wenn der verbundene Javascript-Client über Änderungen im Verlauf der beobachteten Artefakte informiert. (Auch hier könnte ein Beobachtermuster eine gute Wahl sein)

• Eine Javascript-Artefakt-Committer-Komponente, die möglicherweise die Änderung eines atomaren Artefakts anfordert und versucht, eine Mutex-Sperre zu erhalten. Durch Vergleichen der bekannten clientseitigen Artefakt-Versions-ID und der aktuellen serverseitigen Artefakt-Versions-ID wird festgestellt, ob der Status des Artefakts wenige Sekunden zuvor von einem anderen Benutzer geändert wurde (Latanz des Javascript-Clients und Festschreibungsprozessfaktoren).

• Ein Javascript-Konfliktlöser, der einem Menschen ermöglicht, welche Änderung die richtige Entscheidung ist. Möglicherweise möchten Sie dem Benutzer nicht einfach mitteilen, dass jemand schneller war als Sie. Ich habe Ihre Änderung gelöscht. Gehen Sie weinen. Viele Optionen aus eher technischen Unterschieden oder benutzerfreundlicheren Lösungen scheinen möglich zu sein.

Also wie würde es rollen ...

Fall 1: Art des Sequenzdiagramms zur Aktualisierung:

• Browser rendert Seite
• Javascript "sieht" Artefakte, die jeweils mindestens ein Wertefeld, eine eindeutige und eine Versions-ID haben
• Der Javascript-Client wird gestartet und fordert Sie auf, den Verlauf der gefundenen Artefakte ab den gefundenen Versionen zu "beobachten" (ältere Änderungen sind nicht interessant).
• Der Serverprozess notiert die Anforderung und überprüft und / oder sendet kontinuierlich den Verlauf
• Verlaufseinträge können einfache Benachrichtigungen enthalten: "Artefakt x hat sich geändert, Client-Pls fordern Daten an", sodass der Client unabhängig abfragen kann, oder vollständige Datensätze "Artefakt x wurde in den Wert foo geändert".
• Der Javascript-Artefakt-Updater unternimmt alles, um neue Werte abzurufen, sobald bekannt ist, dass sie aktualisiert wurden. Es führt neue Ajax-Anforderungen aus oder wird vom Javascript-Client gespeist.
• Der Seiten-DOM-Inhalt wird aktualisiert, der Benutzer wird optional benachrichtigt. Das Beobachten der Geschichte geht weiter.

Fall 2: Jetzt zum Festschreiben:

• Artefakt-Committer kennt den gewünschten neuen Wert aus Benutzereingaben und sendet eine Änderungsanforderung an den Server
• serverseitiger Mutex wird erfasst
• Server erhält "Hey, ich kenne den Status von Artefakt x aus Version 123, lass mich ihn auf den Wert foo pls setzen."
• Wenn die Serverside-Version von Artefakt x gleich (kann nicht kleiner sein) als 123 ist, wird der neue Wert akzeptiert und eine neue Versions-ID von 124 generiert.
• Die neuen Statusinformationen "auf Version 124 aktualisiert" und optional der neue Wert foo werden am Anfang des Ringpuffers des Artefakts x (Änderungsprotokoll / Verlauf) gesetzt.
• serverseitiger Mutex wird freigegeben
• Der anfordernde Artefakt-Committer freut sich über eine Commit-Bestätigung zusammen mit der neuen ID.
• In der Zwischenzeit ruft die serverseitige Serverkomponente die Ringpuffer ab und sendet sie an verbundene Clients. Alle Clients, die den Puffer von Artefakt x beobachten, erhalten die neuen Statusinformationen und den neuen Wert innerhalb ihrer üblichen Latenz (siehe Fall 1).

Fall 3: für Konflikte:

• Der Artefakt-Committer kennt den gewünschten neuen Wert aus Benutzereingaben und sendet eine Änderungsanforderung an den Server
• In der Zwischenzeit hat ein anderer Benutzer das gleiche Artefakt erfolgreich aktualisiert (siehe Fall 2). Aufgrund verschiedener Latenzen ist dies unserem anderen Benutzer jedoch noch nicht bekannt.
• So wird ein serverseitiger Mutex erfasst (oder gewartet, bis der "schnellere" Benutzer seine Änderung übernommen hat).
• Server erhält "Hey, ich kenne den Status von Artefakt x aus Version 123, lass mich ihn auf den Wert foo setzen."
• Auf der Serverseite ist die Version von Artefakt x jetzt bereits 124. Der anfragende Kunde kann den Wert, den er überschreiben würde, nicht kennen.
• Offensichtlich muss der Server die Änderungsanforderung ablehnen (ohne Berücksichtigung der gottintervenierenden Überschreibprioritäten), den Mutex freigeben und ist so freundlich, die neue Versions-ID und den neuen Wert direkt an den Client zurückzusenden.
• Angesichts einer abgelehnten Festschreibungsanforderung und eines Werts, den der Benutzer, der eine Änderung anfordert, noch nicht kannte, bezieht sich der Javascript-Artefakt-Committer auf den Konfliktlöser, der das Problem anzeigt und dem Benutzer erklärt.
• Dem Benutzer, dem vom intelligenten Konfliktlöser JS einige Optionen angeboten werden, wird ein weiterer Versuch gestattet, den Wert zu ändern.
• Sobald der Benutzer einen Wert ausgewählt hat, den er für richtig hält, beginnt der Prozess von Fall 2 (oder von Fall 3, wenn jemand anderes wieder schneller war).

Einige Worte zu Leistung und Skalierbarkeit

HTTP Polling vs. HTTP "Pushing"

• Durch das Abrufen werden Anforderungen erstellt, eine pro Sekunde und fünf pro Sekunde, unabhängig davon, was Sie als akzeptable Latenz betrachten. Dies kann für Ihre Infrastruktur ziemlich grausam sein, wenn Sie Ihre (Apache?) Und (PHP?) Nicht gut genug konfigurieren, um "leichte" Starter zu sein. Es ist wünschenswert, die Abfrageanforderung auf der Serverseite so zu optimieren, dass sie weitaus kürzer als die Länge des Abfrageintervalls ausgeführt wird. Wenn Sie diese Laufzeit in zwei Hälften teilen, können Sie möglicherweise die gesamte Systemlast um bis zu 50% senken.
• Wenn Sie über HTTP pushen (vorausgesetzt, Webworker sind zu weit entfernt, um sie zu unterstützen), muss für jeden Benutzer immer ein Apache / Lighthttpd-Prozess verfügbar sein . Der für jeden dieser Prozesse reservierte residente Speicher und der Gesamtspeicher Ihres Systems sind eine ganz bestimmte Skalierungsgrenze, auf die Sie stoßen werden. Es ist erforderlich, den Speicherbedarf der Verbindung zu verringern und den Umfang der kontinuierlichen CPU- und E / A-Arbeit zu begrenzen (Sie möchten viel Ruhe- / Leerlaufzeit).

Backend-Skalierung

• Vergessen Sie Datenbank und Dateisystem, Sie benötigen eine Art Shared-Memory-basiertes Backend für die häufige Abfrage (wenn der Client nicht direkt abfragt, wird jeder laufende Serverprozess)
• Wenn Sie sich für Memcache entscheiden, können Sie besser skalieren, aber es ist immer noch teuer
• Der Mutex für Commits muss global funktionieren, auch wenn Sie mehrere Frontend-Server zum Lastenausgleich benötigen.

Frontend-Skalierung

• Unabhängig davon, ob Sie "Pushs" abrufen oder empfangen, versuchen Sie, Informationen für alle beobachteten Artefakte in einem Schritt abzurufen.

"kreative" Optimierungen

• Wenn Clients Abfragen durchführen und viele Benutzer dazu neigen, dieselben Artefakte zu sehen, können Sie versuchen, den Verlauf dieser Artefakte als statische Datei zu veröffentlichen, sodass Apache sie zwischenspeichern und sie dennoch auf der Serverseite aktualisieren kann, wenn sich Artefakte ändern. Dies nimmt PHP / Memcache aus dem Spiel, einige für Anfragen. Lighthttpd ist sehr effizient bei der Bereitstellung statischer Dateien.
• Verwenden Sie ein Netzwerk zur Bereitstellung von Inhalten wie cotendo.com, um den Artefaktverlauf dorthin zu verschieben. Die Push-Latenz wird größer sein, aber die Skalierbarkeit ist ein Traum
• Schreiben Sie einen echten Server (ohne HTTP), mit dem Benutzer über Java oder Flash (?) eine Verbindung herstellen. Sie müssen sich damit befassen, viele Benutzer in einem Server-Thread zu bedienen. Durch offene Steckdosen radeln, die erforderliche Arbeit erledigen (oder delegieren). Kann über Forking-Prozesse oder das Starten weiterer Server skaliert werden. Mutexe müssen jedoch weltweit einzigartig bleiben.
• Gruppieren Sie je nach Lastszenario Ihre Frontend- und Backend-Server nach Artefakt-ID-Bereichen. Dies ermöglicht eine bessere Nutzung des persistenten Speichers (keine Datenbank enthält alle Daten) und ermöglicht die Skalierung des Mutexing. Ihr Javascript muss jedoch Verbindungen zu mehreren Servern gleichzeitig aufrechterhalten.

Nun, ich hoffe, dies kann ein Anfang für Ihre eigenen Ideen sein. Ich bin sicher, es gibt noch viel mehr Möglichkeiten. Ich freue mich über jede Kritik oder Verbesserung dieses Beitrags. Das Wiki ist aktiviert.

Christoph Strasen

Ich weiß, dass dies eine alte Frage ist, aber ich dachte, ich würde mich einfach einmischen.

OT (Operational Transforms) scheinen gut zu Ihrer Anforderung für die gleichzeitige und konsistente Bearbeitung durch mehrere Benutzer zu passen. Diese Technik wird in Google Text & Tabellen verwendet (und wurde auch in Google Wave verwendet):

Es gibt eine JS-basierte Bibliothek für die Verwendung von Operational Transforms - ShareJS ( http://sharejs.org/ ), die von einem Mitglied des Google Wave-Teams geschrieben wurde.

Und wenn Sie möchten, gibt es ein vollständiges MVC-Webframework - DerbyJS ( http://derbyjs.com/ ), das auf ShareJS basiert und alles für Sie erledigt.

Es verwendet BrowserChannel für die Kommunikation zwischen dem Server und den Clients (und ich glaube, dass die Unterstützung von WebSockets in Arbeit sein sollte - es war zuvor über Socket.IO verfügbar, wurde jedoch aufgrund der Probleme des Entwicklers mit Socket.io entfernt). Anfängerdokumente sind a im Moment allerdings etwas spärlich.

Ich würde in Betracht ziehen, für jeden Datensatz einen zeitbasierten modifizierten Stempel hinzuzufügen. Wenn Sie also DB-Tabellen aktualisieren, würden Sie den geänderten Zeitstempel entsprechend ändern. Mit AJAX können Sie den geänderten Zeitstempel des Clients mit dem Zeitstempel der Datenquelle vergleichen. Wenn der Benutzer jemals zurückbleibt, aktualisieren Sie die Anzeige. Ähnlich wie diese Site eine Frage regelmäßig überprüft, um festzustellen, ob jemand andere sie beantwortet hat, während Sie eine Antwort eingeben.

Sie müssen Push-Techniken (auch als Comet oder Reverse Ajax bezeichnet) verwenden, um Änderungen an den Benutzer weiterzugeben, sobald sie an der Datenbank vorgenommen werden. Die derzeit beste verfügbare Technik hierfür scheint Ajax Long Polling zu sein, sie wird jedoch nicht von jedem Browser unterstützt, sodass Sie Fallbacks benötigen. Glücklicherweise gibt es bereits Lösungen, die dies für Sie erledigen. Darunter sind: orbited.org und das bereits erwähnte socket.io.

In Zukunft wird es einen einfacheren Weg geben, der als WebSockets bezeichnet wird. Es ist jedoch noch nicht sicher, wann dieser Standard zur Hauptsendezeit bereit sein wird, da Sicherheitsbedenken hinsichtlich des aktuellen Status des Standards bestehen.

Es sollten keine Parallelitätsprobleme in der Datenbank mit neuen Objekten auftreten. Wenn ein Benutzer ein Objekt bearbeitet, muss der Server über eine Logik verfügen, die prüft, ob das Objekt in der Zwischenzeit bearbeitet oder gelöscht wurde. Wenn das Objekt gelöscht wurde, ist die Lösung wieder einfach: Verwerfen Sie einfach die Bearbeitung.

Das schwierigste Problem tritt jedoch auf, wenn mehrere Benutzer gleichzeitig dasselbe Objekt bearbeiten. Wenn Benutzer 1 und 2 gleichzeitig mit der Bearbeitung eines Objekts beginnen, nehmen beide ihre Änderungen an denselben Daten vor. Angenommen, die von Benutzer 1 vorgenommenen Änderungen werden zuerst an den Server gesendet, während Benutzer 2 die Daten noch bearbeitet. Sie haben dann zwei Möglichkeiten: Sie können versuchen, die Änderungen von Benutzer 1 mit den Daten von Benutzer 2 zusammenzuführen, oder Sie können Benutzer 2 mitteilen, dass seine Daten veraltet sind, und ihm eine Fehlermeldung anzeigen, sobald seine Daten an den Server gesendet werden. Letzteres ist hier nicht sehr benutzerfreundlich, aber Ersteres ist sehr schwer zu implementieren.

Eine der wenigen Implementierungen, die dies zum ersten Mal wirklich richtig machten , war EtherPad , das von Google übernommen wurde. Ich glaube, sie haben dann einige der EtherPad-Technologien in Google Text & Tabellen und Google Wave verwendet, aber das kann ich nicht mit Sicherheit sagen. Google hat auch EtherPad geöffnet. Je nachdem, was Sie tun möchten, ist dies möglicherweise einen Blick wert.

Es ist wirklich nicht einfach, diese Dinge gleichzeitig zu bearbeiten, da es aufgrund der Latenz nicht möglich ist, atomare Operationen im Web durchzuführen. Vielleicht hilft Ihnen dieser Artikel , mehr über das Thema zu erfahren.

Der Versuch, all dies selbst zu schreiben, ist eine große Aufgabe, und es ist sehr schwierig, es richtig zu machen. Eine Möglichkeit besteht darin, ein Framework zu verwenden, mit dem Clients in Echtzeit mit der Datenbank und untereinander synchronisiert werden können.

Ich habe festgestellt, dass das Meteor-Framework dies gut macht ( http://docs.meteor.com/#reactivity ).

"Meteor unterstützt das Konzept der reaktiven Programmierung. Dies bedeutet, dass Sie Ihren Code in einem einfachen imperativen Stil schreiben können. Das Ergebnis wird automatisch neu berechnet, wenn sich Daten ändern, von denen Ihr Code abhängt."

"Dieses einfache Muster (reaktive Berechnung + reaktive Datenquelle) hat eine breite Anwendbarkeit. Der Programmierer kann keine Abmelde- / Abmeldeaufrufe schreiben und sicherstellen, dass sie zum richtigen Zeitpunkt aufgerufen werden, wodurch ganze Klassen von Datenverbreitungscode eliminiert werden, die sonst Ihre Daten verstopfen würden Anwendung mit fehleranfälliger Logik. "

Ich kann nicht glauben, dass niemand Meteor erwähnt hat . Es ist sicher ein neues und unausgereiftes Framework (und unterstützt offiziell nur eine Datenbank), aber es erfordert die ganze Arbeit und das Denken einer Mehrbenutzer-App, wie sie auf dem Poster beschrieben wird. Tatsächlich können Sie KEINE Live-Aktualisierungs-App für mehrere Benutzer erstellen. Hier ist eine kurze Zusammenfassung:

• Alles befindet sich in node.js (JavaScript oder CoffeeScript), sodass Sie Dinge wie Validierungen zwischen Client und Server austauschen können.
• Es verwendet Websockets, kann jedoch für ältere Browser zurückgreifen
• Es konzentriert sich auf sofortige Aktualisierungen des lokalen Objekts (dh die Benutzeroberfläche fühlt sich bissig an), wobei Änderungen im Hintergrund an den Server gesendet werden. Nur atomare Updates dürfen das Mischen von Updates vereinfachen. Auf dem Server abgelehnte Updates werden zurückgesetzt.
• Als Bonus übernimmt es das Neuladen von Live-Code für Sie und behält den Benutzerstatus bei, selbst wenn sich die App radikal ändert.

Meteor ist so einfach, dass ich vorschlagen würde, dass Sie es sich zumindest ansehen, um Ideen zu stehlen.

Diese Wikipedia-Seiten können dazu beitragen, das Erlernen von Parallelität und Concurrent Computing für das Entwerfen einer Ajax- Webanwendung , die EDA- Nachrichten ( State State Event ) in einem Messaging-Muster abruft oder gepusht wird , zu erweitern . Grundsätzlich werden Nachrichten an Kanalteilnehmer repliziert, die auf Änderungsereignisse und Synchronisationsanforderungen reagieren.

• https://en.wikipedia.org/wiki/Category:Concurrency_control
• https://en.wikipedia.org/wiki/Distributed_concurrency_control
• https://en.wikipedia.org/wiki/CAP_theorem
• https://en.wikipedia.org/wiki/Operational_transformation
• https://en.wikipedia.org/wiki/Fallacies_of_Distributed_Computing

Es gibt viele Formen gleichzeitiger webbasierter Software für die Zusammenarbeit .

Es gibt eine Reihe von HTTP-API-Clientbibliotheken für etherpad-lite , einen kollaborativen Echtzeiteditor .

django-realtime-playground implementiert eine Echtzeit-Chat-App in Django mit verschiedenen Echtzeit-Technologien wie Socket.io .

Sowohl AppEngine als auch AppScale implementieren die AppEngine Channel API . Dies unterscheidet sich von der Google Realtime API , die durch googledrive / realtime-playground demonstriert wird .

Serverseitige Push- Techniken sind hier der richtige Weg. Komet ist (oder war?) Ein Modewort.

Welche Richtung Sie einschlagen, hängt stark von Ihrem Server-Stack ab und davon, wie flexibel Sie sind. Wenn Sie können, würde ich einen Blick auf socket.io werfen , das eine browserübergreifende Implementierung von Websockets bietet, die eine sehr optimierte Möglichkeit für die bidirektionale Kommunikation mit dem Server bietet und es dem Server ermöglicht, Aktualisierungen an die Clients zu senden.

Sehen Sie sich insbesondere diese Demonstration des Autors der Bibliothek an, die fast genau die von Ihnen beschriebene Situation zeigt.