Sie werden wahrscheinlich unglückliche Ergebnisse mit einer Kombination aus Pipeline, Transaktionen (MULTI/EXEC) und Cluster erleben. In Redis Cluster sprechen Sie mit mehreren Servern. Dies ist wichtig, da sowohl Pipelining als auch MULTI/EXEC Single-Node-orientierte Befehle sind.
Beim Pipelining werden im Wesentlichen eine Reihe von Befehlen in die Warteschlange gestellt und als einzelner Netzwerkaufruf an den Server gesendet. Wenn Ihre Befehle zu verschiedenen Cluster-Knoten gehen müssen, funktioniert das nicht, da Sie nicht einen einzelnen Netzwerk-Send verwenden können, um ihn an mehrere Knoten zu senden.
In ähnlicher Weise existiert MULTI nur innerhalb des Knotens, an den es gesendet wurde, nicht clusterweit. Wenn Ihre Befehle in den Multi/Exec-Zugriffsschlüsseln auf verschiedenen Knoten stehen, haben Sie daher keine zuverlässigen Transaktionen.
Wie das manifestiert, ist unbekannt, weil es von der Client-Bibliothek und von irgendwelchen Überprüfungen abhängt, die es durchführt, wie es eine Umleitung während eines Transaktionsblocks handhabt.
Wenn Sie jedoch unbedingt Pipelined Multi/Exec benötigen, müssen Sie entweder sicherstellen, dass alle Schlüssel auf einem Knoten sind, indem Sie die "hashtag" -Methode von Redis verwenden; Verwenden Sie clientseitigen Code, um zu überprüfen, wo alle Schlüssel sind, einen Fehler zu erzeugen, wenn nicht auf dem gleichen Knoten, in der Hoffnung, dass ein Schlüssel zwischen der Überprüfung und der Ausführung des Befehls nicht verschoben wurde; oder nicht Cluster verwenden. In den ersten beiden Fällen sollten Sie WATCH verwenden, um die zu verwendenden Schlüssel anzugeben. So haben Sie die Möglichkeit, einen Steckplatzwechsel zu erkennen und Zustände unter verschiedenen Knoten zu erkennen.
Was ist falsch an der Verwendung der 'Watch' Methode? Wenn Ihnen die API nicht gefällt, ist 'redigo' ein weiteres beliebtes Paket. – JimB