Rozumiem, że ogień i zapomnienie są przeznaczone do sytuacji, w których nie interesuje cię odpowiedź. Czy gwarantuje również dostawę, nawet jeśli odpowiedź nie jest ważna dla uruchomionej aplikacji?Stackexchange.redis robi ogień i zapomina o dostarczeniu gwarancji?
W rzeczywistości protokół Redis nie obsługuje operacji "pożar i zapomnij". Z wyjątkiem ruchu pub/sub, wszystkie polecenia Redis są dopasowane do odpowiedzi i nie ma sposobu, aby powiedzieć serwerowi Redis, aby pominąć odpowiedź.
Teraz niektórzy klienci (np. StackExchange.Redis) symulują tryb "ogień i zapomnij" poprzez asynchroniczną implementację protokołu. W rzeczywistości tryb "ogień i zapomnij" w StackExchange.Redis jest bardzo podobny do trybu "asynchronicznego", z tym wyjątkiem, że odpowiedzi są po prostu odrzucane, gdy są odbierane.
Czy to jest niezawodne? Cóż, gwarantuje dostawę, o ile TCP/IP gwarantuje dostawę. Sieć będzie się starała przesłać pakiety (ostatecznie pakiety zostaną przesłane ponownie, jeśli niektóre z nich zostaną utracone), ale wszystko to jest obsługiwane przez TCP.
Teraz, jeśli serwer jest wyłączony lub zdecydować o zamknięciu połączenia, klient będzie wiedział tylko, kiedy próbuje odczytać z gniazda. StackExchange.Redis może z przyjemnością kontynuować wysyłanie komend przez niedziałające połączenie przez pewien czas. Jeśli posiadasz middletier (taki jak Twemproxy), sytuacja może być jeszcze gorsza.
Innymi słowy, ruch "strzelaj i zapomnij" będzie generalnie wysyłany na serwer, a ż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 szansę na zauważenie tego. Nazwałbym to zachowaniem typu "best effort".
Dziękuję. Moje pytanie było w dużej mierze nadal oferuje ponowną próbę albo przez bibliotekę albo bazowy TCP i na podstawie twojej odpowiedzi wydaje się, że tak. – DTown