So habe ich leider keine wirkliche Ahnung über die bereitgestellten Zahlen aus dem Knoten JS-Treiber, aber ich weiß etwas über die Konsistenz-Ebenen, die ich vermute, dass Sie im Hintergrund verwenden, vorausgesetzt, dass Sie verwenden diesen Treiber: http://datastax.github.io/nodejs-driver/.
Nur eine einfache Sache: Die Knoten schreiben nicht direkt an Sie zurück, aber Ihre Abfrage wird an einen Knoten gesendet, den Koordinator dieser Abfrage, der die Abfrage in Ihrem Cluster entsprechend Ihren Konsistenzspezifikationen verteilt (zumindest wenn es sich um eine einfache Abfrage handelt, gilt im Falle von Batch-Abfragen eine komplexere Verteilungslogik. Der Koordinator meldet sich dann zurück, wenn die Abfrage ausgeführt wird.
Ob Ihre Anforderungen an alle erfüllt werden, hängt von dem Replikationsfaktor Du gewählt hast. Das Problem ist, dass Cassandra nur so viele von ihnen kennt. Die Optionen für das Schreiben sind: alles (was zunächst aussieht, was du willst), Quorum (das ist auch eine Option), eins und alle. Nehmen wir an, Sie wählen alle, weil Sie in alle Replikate schreiben möchten. Das ist völlig in Ordnung, aber wenn einer der Knoten ausfällt, kommt es zu Schreibfehlern, weil eines der Replikate nicht aktualisiert werden konnte. Wenn Sie den Replikationsfaktor 3 tatsächlich verwenden, können Sie auf das Quorum zurückgreifen, was in diesem Fall 2 Knoten ist. Was passiert, wenn ein anderer Knoten ausfällt? Ich weiß, sehr unwahrscheinlich, aber ich habe es in der Produktion gesehen, also passiert es von Zeit zu Zeit. Soll der einzelne letzte Knoten in diesem Fall aktualisiert werden? Dann müssen Sie auf Konsistenzniveau 1 zurückgreifen. Alles in Ordnung.
Aber was, wenn Sie den Replikationsfaktor wählen 5 sein? Nun, es gibt keine Möglichkeit zu sagen: Ich will 4 Knoten. Sie können nur ein Quorum im Falle eines Ausfalls von einem Knoten haben, und das wäre 3, nicht 4. Und der nächste Fallback wäre 1 und nicht 2.
Die letzte Frage ist: Wenn Sie einen Knoten verlieren und Sie tun einen Fallbak im schreibenden Teil, was passiert, wenn Ihr Knoten zurückkommt (unter der Annahme, dass es verloren gegangene Aktualisierungen gibt, weil einige der angedeuteten Übergaben bereits verworfen wurden)? Der lesende Teil Ihrer Anwendung kann immer veraltete Daten lesen, da Sie immer nur von einem einzigen Knoten lesen. Es scheint mir, als ob du das im Schreibteil kompensieren willst. Meine persönliche Idee wäre es, das Quorum beim Lesen und Schreiben zu verwenden. Auf diese Weise wird garantiert, dass Sie aktuelle Daten lesen und ein einzelner Knoten untergehen kann (mit dem Replikationsfaktor 5 sind es sogar 2 Knoten). Denken Sie auch daran, dass cassandra beim Schreiben auf einen Knoten immer versucht, im Hintergrund auf die Replikate zu schreiben, so dass es versucht, Ihre Daten auf dem neuesten Stand zu halten. Das Risiko, veraltete Daten sogar mit einem Konsistenzlevel von eins zu lesen, kann akzeptabel sein, wenn Sie wirklich die Geschwindigkeit brauchen.