I understand that CommandFlags.FireAndForget
is intended for situations that you don\'t care about the response.
Does it also guarantee delivery even though
Actually, the Redis protocol does not really support "fire and forget" operations. Except for pub/sub traffic, all Redis commands are matched with a reply, and there is no way to tell the Redis server to omit the reply.
Now some clients (like StackExchange.Redis) simulates a "fire and forget" mode through an asynchronous implementation of the protocol. Actually, the "fire and forget" mode in StackExchange.Redis is very similar to the "asynchronous" mode, except the replies are simply discarded when they are received.
Is it reliable? Well, it guarantees the delivery as far as TCP/IP guarantees the delivery. The network will try hard to transmit the packets (eventually the packets will be transmitted again if some of them are lost), but this is all handled by TCP.
Now if the server is down, or decide to close the connection, the client will only be aware when it tries to read from the socket. StackExchange.Redis may happily continue to send commands on a dead connection for a while. If you have a middletier (such as Twemproxy), the situation can be even worse.
In other words, "fire and forget" traffic will generally be sent to the server, and no message will be lost on the network, but if you have server or connection issues, some traffic can be lost before the client has a chance to notice it. I would call this a best effort behavior.