Wenn ich eine Webanwendung in einer Farm ausführe, die einen konsistenten Datenspeicher verwendet, der letztendlich konsistent ist (in meinem Fall CouchDB), sollte ich sicherstellen, dass ein bestimmter Benutzer immer an die Datenspeicherinstanz weitergeleitet wird?
Mir scheint, dass der alternative Ansatz, bei dem jede Webanforderung einen beliebigen Datenspeicher verwenden kann, eine erhebliche Komplexität bei der Behandlung von Konsistenzproblemen (Wiederholungen, Überprüfungen usw.) mit sich bringt. Auf der anderen Seite, wenn ein Benutzer in einer bestimmten Sitzung immer auf den gleichen Couch-Knoten gerichtet ist, werden sich meine Konsistenzprobleme nicht hauptsächlich um "gemeinsame" Benutzerdaten drehen und somit stark vereinfacht werden?
Ich bin auch neugierig auf Strategien zur Benutzerführung, aber vielleicht behalte ich das für eine andere Frage (Kommentare sind willkommen).
Nach dem CAP-Theorem können verteilte Systeme entweder vollständig konsistent sein (alle Knoten sehen dieselben Daten gleichzeitig) Zeit) oder Verfügbarkeit (jede Anfrage erhält eine Antwort). Während einer Partition oder eines Datenspeicherinstanzfehlers müssen Sie einen gegen den anderen tauschen.
Soll sichergestellt werden, dass ein bestimmter Benutzer immer an die Datenspeicherinstanz weitergeleitet wird?
Im Idealfall sollten Sie nicht! Was machen Sie, wenn die angegebene Instanz fehlschlägt? Ein Hauptmerkmal eines verteilten Datenspeichers soll trotz Netzwerk- oder Instanzfehlern verfügbar sein.
Wenn ein Benutzer in einer bestimmten Sitzung immer zu demselben Couch-Knoten geleitet wird, werden sich meine Konsistenzprobleme nicht hauptsächlich um "gemeinsame" Benutzerdaten drehen und somit stark vereinfacht werden?
Sie haben Recht, die Architektur wäre auf diese Weise viel einfacher, aber was würden Sie tun, wenn diese Instanz versagt? In verteilten Systemen wurde viel Entwicklungsaufwand investiert, damit mehrere Instanzen auf eine Abfrage antworten können. Ich bin nicht sicher über CouchDB, aber Cassandra erlaubt Ihnen, Ihr Konsistenzmodell zu wählen, Sie müssen die Verfügbarkeit für einen höheren Grad an Konsistenz abwägen. Der Client ist so konfiguriert, dass Server standardmäßig Round-Robin angefordert werden, wodurch die Last verteilt wird.
Ich würde Ihnen empfehlen, das Dynamopapier zu lesen. Die Autoren beschreiben viele technische Details hinter einer verteilten Datenbank.
Tags und Links distributed-computing web nosql eventual-consistency couchdb