Tatsächlich unterstützt das Redis-Protokoll „Fire and Forget“-Operationen nicht wirklich. Mit Ausnahme des Pub/Sub-Datenverkehrs werden alle Redis-Befehle mit einer Antwort abgeglichen, und es gibt keine Möglichkeit, den Redis-Server anzuweisen, die Antwort auszulassen.
Jetzt simulieren einige Clients (wie StackExchange.Redis) einen „Fire and Forget“-Modus durch eine asynchrone Implementierung des Protokolls. Tatsächlich ist der „fire and forget“-Modus in StackExchange.Redis dem „asynchronous“-Modus sehr ähnlich, außer dass die Antworten einfach verworfen werden, wenn sie empfangen werden.
Ist es zuverlässig? Nun, es garantiert die Zustellung, soweit TCP/IP die Zustellung garantiert. Das Netzwerk wird sich bemühen, die Pakete zu übertragen (schließlich werden die Pakete erneut übertragen, wenn einige von ihnen verloren gehen), aber dies wird alles von TCP gehandhabt.
Wenn der Server jetzt heruntergefahren ist oder sich entscheidet, die Verbindung zu schließen, wird der Client dies nur bemerken, wenn er versucht, aus dem Socket zu lesen. StackExchange.Redis kann gerne für eine Weile weiterhin Befehle über eine tote Verbindung senden. Wenn Sie eine Middletier (wie Twemproxy) haben, kann die Situation sogar noch schlimmer sein.
Mit anderen Worten:„Fire and Forget“-Datenverkehr wird im Allgemeinen an den Server gesendet, und keine Nachricht geht im Netzwerk verloren, aber wenn Sie Server- oder Verbindungsprobleme haben, kann ein Teil des Datenverkehrs verloren gehen, bevor der Client die Möglichkeit hat, dies zu bemerken es. Ich würde dies als Best-Effort-Verhalten bezeichnen.
