JRedisFuture Stabilität

Question

Ich bin die synchrone Durchführung von JRedis, aber ich bin die Planung bis zur Umstellung auf die asynchrone Art und Weise mit dem redis Server zu kommunizieren.

Aber vorher möchte ich die Gemeinde fragen, ob die JRedisFuture Umsetzung alphazero jredis stabil ist genug für den produktiven Einsatz oder nicht?

Gibt es jemand da draußen, die es mit oder Erfahrung damit?

Danke!

Answer 1

Wenn JRedis Unterstützung erhält für Transaktionssemantik (Redis 1.3.n, JRedis master-Zweig), dann sicher, sollte es „stabil“ genug sein.

Redis Protokoll für Nicht-Transaktionsbefehle, selbst atomar, ermöglicht ein Fenster der nicht behebbaren Fehler, wenn ein zerstörerischer Befehl gesendet wurde, und auf der Lesephase der Verbindungsfehler. Der Kunde hat keine Möglichkeit zu wissen, ob Redis in der Tat die letzte Anfrage bearbeitet, aber die Reaktion wurde aufgrund von Netzwerkausfall fällt gelassen (zum Beispiel). Schon die Basis Request / Reply-Client ist anfällig für diese (und ich denke, das ist nicht auf Java beschränkt ist, per se.)

Da Redis Protokoll keine Metadaten erfordert (überhaupt) mit den DML und DDL -Art-Befehle (z kein Befehl sequent Nummer) dieses Fenster des Scheiterns geöffnet wird.

Mit Pipelining, gibt es nicht mehr eine sequentielle Zuordnung zwischen dem Befehl, der geschrieben wird, und die Antwort, die gelesen wird. (Das Rohr einen Befehl sendet, die N hinter dem einen Befehle, die Redis verursacht die Reaktion auf die Ausgabe zur gleichen Zeit gelesen werden, wenn etwas kaputt geht, gibt es eine Menge von Gerichten in der Luft.)

sagte, dass jede einzelne zukünftige Objekt in dem Rohr markiert werden als fehlerhaft und Sie werden wissen genau bei denen Antwort der Fehler aufgetreten ist.

Does, die als "instabil" qualifizieren? Meiner Meinung nach, nein. Das ist ein Problem mit Pipelining.

Auch Redis 1.3.n mit Transaktionssemantik-Adressen vollständig dieses Problem.

Außerhalb dieses Problems mit asynchroner (Pipeline), gibt es eine große Verantwortung auf Ihrer Seite sicher dafür, dass Sie nicht überlasten übermäßig den Eingang zum Anschluss. Zu einem großen Ausmaß JRedis Pipelines Sie davor schützen (da das Gewinde des Anrufers wird verwendet, damit natürlich das Netzwerk Schreib zu machen Dämpfung der Eingangslast auf die anstehende Antwortwarteschlange).

Aber Sie müssen noch Tests laufen - Sie „Produktion“ sagte, nicht wahr? )) - und die Größe der Boxen und eine Obergrenze für die Anzahl der Lade Gewinde am vorderen Ende setzen.

Ich würde auch potenziell empfehlen nicht mehr als eine JRedis Pipeline auf Multi-Core-Maschinen ausgeführt werden. In der bestehenden Implementierung (der nicht von Chunk des Schreibpuffer) gibt es Raum für Effizienz (in Zusammenhang mit der vollen Bandbreitennutzung und die Maximierung des Durchsatz), indem Sie mehrere Pipelines auf den gleichen Server gewonnen werden. Während die eine Pipeline beschäftigt schaffen Puffer zu schreiben ist, wird das andere Schreiben, etc. Aber werden diese beiden Pipelines miteinander aufgrund ihrer stören (unvermeidlich - erinnern sie sich Warteschlangen sind und eine gewisse Form der Synchronisation erfolgen muss) und periodische Cache-Annullierungs (auf jeder dequeue / enqueue im schlimmsten Fall - aber in Doug Lea vertrauen wir.) also, wenn Pipeline A durchschnittliche Latenz Hit d1 (isoliert), dann so tut Rohr B. Bedauerlicherweise zwei von ihnen auf den gleichen Kernen laufen führen in einer neues System breite Cacheungültigmachungs Periode, die die Hälfte des ursprünglichen Systems ist so doppelt so mehr Invalidierungen Cache (im Durchschnitt) auftreten. So ist es dem Sieg über sich selbst. Aber testen Sie Ihre Lastbedingungen und auf Ihrer geplanten Produktionsbereitstellungsplattform.