如何處理Redis客戶端的read（）超時？

Question

假設我的客戶端向redis服務器發送'INCR'命令，但響應數據包丟失，所以我的客戶端的read（）將超時，但客戶端無法確定服務器是否執行了INCR操作。

接下來要做什麼？重新發送INCR或繼續下一個命令？如果客戶端重新發送INCR，但是如果redis之前在服務器端執行了INCR，該密鑰將增加兩次，這不是我們想要的。

Answer 1

這不是Redis特有的問題：它也適用於任何其他數據存儲（包括事務性存儲）。這個問題沒有解決辦法：你只能希望儘量減少這個問題。

例如，有些人傾向於認爲Redis應該是一個軟實時數據存儲的超時值非常積極。 Redis速度很快，但您還需要考慮網絡和系統本身。網絡相關問題可能會產生較高的延遲。如果系統開始交換，它將嚴重影響Redis響應時間。

我傾向於認爲在任何Unix/Linux系統上放置超過2秒的超時是無稽之談，如果涉及到網絡，我會更舒適10秒。人們的價值很低，因爲他們想避免他們的申請被阻止：這是一個錯誤。他們應該將應用程序設計爲異步並設置合理的超時，而不是設置非常低的超時並保持應用程序同步。

超時後，客戶端不應該繼續使用下一個命令。它應該關閉連接，並嘗試打開一個新的連接。如果答覆（或查詢）丟失，則客戶端和服務器不可能重新同步。關閉連接更安全。

您應該在重新連接後再次嘗試發出INCR嗎？這真的取決於你。但是，如果剛剛觸發了讀取超時，則重新連接很可能會超時。 Redis是單線程的，當一個連接速度很慢時，它對於所有連接同時緩慢。