En fait, le protocole Redis ne prend pas vraiment en charge les opérations "fire and forget". À l'exception du trafic pub/sub, toutes les commandes Redis sont associées à une réponse, et il n'y a aucun moyen de dire au serveur Redis d'omettre la réponse.
Désormais, certains clients (comme StackExchange.Redis) simulent un mode "fire and forget" via une implémentation asynchrone du protocole. En fait, le mode "lancer et oublier" dans StackExchange.Redis est très similaire au mode "asynchrone", sauf que les réponses sont simplement ignorées lorsqu'elles sont reçues.
Est-ce fiable ? Eh bien, il garantit la livraison dans la mesure où TCP/IP garantit la livraison. Le réseau s'efforcera de transmettre les paquets (éventuellement, les paquets seront à nouveau transmis si certains d'entre eux sont perdus), mais tout cela est géré par TCP.
Maintenant, si le serveur est en panne ou décide de fermer la connexion, le client ne sera averti que lorsqu'il essaiera de lire à partir du socket. StackExchange.Redis peut heureusement continuer à envoyer des commandes sur une connexion morte pendant un certain temps. Si vous avez un intermédiaire (comme Twemproxy), la situation peut être encore pire.
En d'autres termes, le trafic "fire and forget" sera généralement envoyé au serveur, et aucun message ne sera perdu sur le réseau, mais si vous rencontrez des problèmes de serveur ou de connexion, une partie du trafic peut être perdue avant que le client n'ait la possibilité de s'en apercevoir. ce. J'appellerais cela un comportement de meilleur effort.
