Dot-Net
Stackexchange.Redis 的“一勞永逸”能保證傳遞嗎？
我了解這
CommandFlags.FireAndForget適用於您不關心響應的情況。即使響應對正在執行的應用程序並不重要，它是否也能保證傳遞？
實際上，Redis 協議並不真正支持“一勞永逸”的操作。除了 pub/sub 流量，所有 Redis 命令都匹配一個回复，沒有辦法告訴 Redis 伺服器省略回复。
現在一些客戶端（如 StackExchange.Redis）通過協議的非同步實現來模擬“即發即棄”模式。實際上，StackExchange.Redis 中的“即發即棄”模式與“非同步”模式非常相似，只是在收到回复時將其簡單地丟棄。
它可靠嗎？好吧，它保證了傳遞，因為 TCP/IP 保證了傳遞。網路會努力傳輸數據包（如果失去了一些數據包，最終會重新傳輸數據包），但這一切都由 TCP 處理。
現在，如果伺服器關閉，或者決定關閉連接，客戶端只有在嘗試從套接字讀取時才會知道。StackExchange.Redis 可能會愉快地繼續在死連接上發送命令一段時間。如果您有中間層（例如 Twemproxy），情況可能會更糟。
換句話說，“一勞永逸”的流量一般會被發送到伺服器，並且不會在網路上失去任何消息，但是如果您有伺服器或連接問題，則可能會在客戶端有機會注意到之前失去一些流量它。我將其稱為盡力而為的行為。