W rzeczywistości protokół Redis tak naprawdę nie obsługuje operacji „uruchom i zapomnij”. Z wyjątkiem ruchu pub/sub, wszystkie polecenia Redis są dopasowywane do odpowiedzi i nie ma sposobu, aby powiedzieć serwerowi Redis, aby pominął odpowiedź.
Teraz niektórzy klienci (takie jak StackExchange.Redis) symulują tryb „uruchom i zapomnij” poprzez asynchroniczną implementację protokołu. W rzeczywistości tryb „uruchom i zapomnij” w StackExchange.Redis jest bardzo podobny do trybu „asynchronicznego”, z wyjątkiem tego, że odpowiedzi są po prostu odrzucane po ich otrzymaniu.
Czy to jest wiarygodne? Cóż, gwarantuje dostawę, o ile TCP/IP gwarantuje dostawę. Sieć będzie usilnie próbowała przesłać pakiety (w końcu pakiety zostaną przesłane ponownie, jeśli część z nich zostanie utracona), ale wszystko to jest obsługiwane przez TCP.
Teraz, jeśli serwer nie działa lub zdecyduje się zamknąć połączenie, klient będzie świadomy tylko wtedy, gdy spróbuje odczytać z gniazda. StackExchange.Redis może przez jakiś czas szczęśliwie kontynuować wysyłanie poleceń w niedziałającym połączeniu. Jeśli masz pośrednika (takiego jak Twemproxy), sytuacja może być jeszcze gorsza.
Innymi słowy, ruch typu „odpal i zapomnij” będzie zazwyczaj wysyłany do serwera i żadna wiadomość nie zostanie utracona w sieci, ale jeśli masz problemy z serwerem lub połączeniem, część ruchu może zostać utracona, zanim klient będzie miał szansę zauważyć to. Nazwałbym to zachowaniem typu „najlepszy wysiłek”.
